Makes sense. I think it's common to have to use these one off scripts when dealing with Jenkins and daily build products and so on.
Another project I'm working on has a hack/ directory for stuff like this that can be easily commited into, for sharing these sorts of one off tasks. Maybe we should have one in bigtop and then you can dump these Jenkins related workarounds in hack/? > On Dec 26, 2015, at 12:09 AM, Konstantin Boudnik <[email protected]> wrote: > > Moving a bit of the topics of pure polishing of rough edges, I wanted to bring > up the idea of automatically producing the package repos of the nightly > builds. With a few lines of shell we can do it as demonstrated in > > https://github.com/c0s/dumb-ass-scripts/blob/master/gen-apt.sh > and > https://github.com/c0s/dumb-ass-scripts/blob/master/gen-yum.sh > > Considering that we are dealing here with a matrix of OSes in this case, it > won't be perhaps ideal to roll this functionality into the main build. Keeping > it as an aux helper seems like a better idea. > There's of course disk-consumption issue, but we might be able to solve it. > > Thoughts? > Cos > >> On Wed, Dec 23, 2015 at 12:34PM, Konstantin Boudnik wrote: >> Guys, >> >> I've been trying to replicate our CI elsewhere and here's a couple of >> observations and proposed fixes that might do such things easier in the >> future. >> >> 1. Running build as root inside of the docker container. >> >> This seems like a real issue, especially considering that we have always >> advocated to stay away from such practice. Unfortunately, adding >> -u jenkins:jenkins >> to docker run snags on a couple of points >> >> 2. Shared Gradle directory shouldn't belong to root, or at least should be >> writable for everyone. >> >> This is covered in BIGTOP-2171 (appreciate the review) and has caused user >> confusions like BIGTOP-2184 >> >> 3. One perhaps last issue here is the discrepancy between the user ids, where >> jenkins on centos and ubuntu have different UID (BIGTOP-2187) >> >> I think with these three in place, we should be able to start using >> un-privileged user for the builds and also for the cluster testing. >> >> Thoughts? >> Cos > >
