On Fri, Jan 28, 2011, Michael Hudson-Doyle wrote: > What do you mean by stuff? Configs? Generically useful scripts? > Although I'm not really sure how much of the latter there will be.
Both I see storing configs more as some kind of backup / safety net in the ideal case. Most of the logic should be in separate scripts; for instance, I moved my u-boot jobs from various trees to use a common build-u-boot shell wrapper which does the right thing. Similarly I have build-qemu, build-linux, build-cross-gdb etc. I'm also sharing some utility services; for instance I have a script which runs commands in a schroot, then destroys it. > > * share our stuff, perhaps in common repos across hudson instances (see > > below) > > * have everybody follow best practices of keeping as much as possible > > under a VCS > > * help move/factor hudson instances (e.g. factor two instances in one, > > move from home server or cloud to Linaro/Canonical IS datacenter) > > I don't know how much having the config in bzr is going to make merging > two instances easier... I guess a bit. The main thing I'd like to share are hudson scripts, like the chroot thing above, or a script to download the latest linaro snapshot or hwpack. > > I see two ways to approach this problem: > > * each team owns a hudson instance, and stores its config and scripts > > in the team's namespace; this doesn't encourage factoring instances > > together though > > * we create a virtual team of people caring for hudson stuff, e.g. > > ~linaro-hudson-hackers, and we put branches below that > > TBH, one team per hudson is probably about right. My instincts about > how much will be reasonably shareable between instances might be wrong > though. I realize I'm also trying to have people who care about hudson be in the same virtual team as to have our hudson instances relatively on par, and not maintained in completely different ways. Having the configs accessible to folks maintaining other hudson instances in Linaro allows them to see how other instances are handled and copy the good ideas or suggest improvements (albeit TBH the XML format is not nice to read). > > Two things which might slow us down if we want to proceed: > > * Hudson might get renamed due to the situation with Oracle > > I don't think this is a good thing to block on. We should deal with it > when it happens, not make guesses about what and when things might > change IMHO. agreed > I have a related question, which is what do you have in your .bzrignore > for your branches that contain hudson configs? I just have this > currently: > slave-*.log > ./jobs/*/builds > which avoids checking in the output of the builds. Is there anything > else that should be excluded? I'm storing /srv/hudson.dooz.org in bzr, which contains the hudson home under /home, scripts under /bin and the bzr repo for itself under /bzr. I have a slightly longer list of things in my .bzrignore (attached) -- Loïc Minier
/*.war /bzr/** /ccache/** /home/.owner /home/jobs/**/builds/ /home/jobs/**/lastSuccessful /home/jobs/**/lastStable /home/jobs/**/nextBuildNumber /home/jobs/*/scm-polling.log /home/jobs/*/workspace/ /home/plugins/ /home/updates/ /home/users/ /home/war/ /home/Connection Activity monitoring to slaves.log /home/Fingerprint cleanup.log /home/Workspace clean-up.log /home/queue.xml.bak /home/secret.key
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
