On 21 May 2013 07:51, Jonathan Aquilina <eagles051...@gmail.com> wrote: > Not trying to hijack the thread here but something like tinderboxes would be > rather handy in terms of ensuring builds dont break > http://en.wikipedia.org/wiki/Tinderbox_%28software%29 > > libreoffice uses them that way if something does break an email is sent out > to the person who submitting the patch that is causing the breakage.
We already use Jenkins and it can do the same. > On Mon, May 20, 2013 at 9:22 PM, Christopher Covington <c...@codeaurora.org> > wrote: >> >> Hi Nicolas, >> >> On 05/17/2013 09:20 AM, Nicolas Dechesne wrote: >> > >> > On Wed, Apr 3, 2013 at 2:24 PM, Christopher Covington >> > <c...@codeaurora.org >> > <mailto:c...@codeaurora.org>> wrote: >> > >> > >> I notice you've created a number of shell scripts to manage >> > checking out >> > >> multiple git repositories, specific revisions of git repositories >> > for a >> > >> release, etc. Repo [1] does this stuff pretty well that you might >> > want to >> > >> consider as an eventual alternative. >> > > >> > > I was considering repo few times but jenkins-setup scripts are >> > used not >> > > only to fetch/update/freeze git repositories but mostly to handle >> > build >> > > jobs (at CI or any other machine). >> > >> > I'm glad to hear that you've looked into it. There's certainly a lot >> > more to >> > automation than revision control, although Repo does seem to play >> > well with >> > others in my experience. Anyhow, I just figured if there was an >> > unexplored >> > possibility to make things easier for developers and users, I'd try >> > to >> > mention it. >> > >> > >> > hi. >> > >> > even before that discussion started i was using 'repo' to manage my own >> > (currently private) OE based distro, and I thought I would share my own >> > conclusions too.. so i am currently using repo with a OE 'manifest' that >> > describe the set of all 'layers' (trees) which i need to build my >> > distro. I am >> > not using gerrit at all, I am just using repo as a tool to manager >> > multiple >> > 'git trees' in a somehow synchronous manner. >> > >> > and as surprised as i was... i have to say that I like this setup very >> > much. >> > The main advantages i can see are: >> > - ability to checkout the entire 'distro' at once, as well as update >> > all tree >> > at once: repo sync >> > - ability to easily track and switch 1 or more stable versions, as well >> > as >> > master: repo init -b dylan && repo sync >> > - we could potentially use the 'smartsync' feature of repo to provide >> > an >> > 'always' working environment for our downstream users >> > - ability to create 'static' manifest with the commit of each sub >> > project to >> > easily regenerate 'releases' (repo manifest -r) >> > >> > and the *most* interesting feature by far to me, is 'repo grep' that is >> > equivalent to 'git grep' but in all *projects*. For OE work 'git grep' >> > is a >> > very useful command, so ability to grep in all layers at once is a >> > killer feature. >> > >> > since a picture is worth a thousand words... and since I cannot show my >> > current distro trees for, i have made a sample manifest for review. >> > >> > https://git.linaro.org/gitweb?p=people/ndec/oemanifest.git >> > <https://git.linaro.org/gitweb?p=people/ndec/oemanifest.git;a=summary> >> > >> > This is a simple manifest that pulls oe-core, meta-oe, bitbake, >> > meta-linaro >> > and meta-beagleboard, see: >> > >> > >> > https://git.linaro.org/gitweb?p=people/ndec/oemanifest.git;a=blob;f=default.xml;h=8ff267206ad36b5ded032aa15d313fa19af6e0a5;hb=refs/heads/master >> > >> > the workflow is the following: >> > - for someone who needs to setup the build env: >> > repo init -u git://git.linaro.org/people/ndec/oemanifest.git >> > <http://git.linaro.org/people/ndec/oemanifest.git> >> > repo sync >> > >> > - to switch from master to dylan: >> > repo init -b dylan && repo sync >> > >> > - to grep the entire set of layers: >> > repo grep SRC_URI >> > >> > - and 'release manifests' can be checked out in the tree as well, see: >> > >> > https://git.linaro.org/gitweb?p=people/ndec/oemanifest.git;a=shortlog;h=refs/heads/release >> >> I like this use of pinned revisions on a branch, and I wonder if it might >> be >> useful to do this for last-known-good revisions too. Assuming a project is >> to >> the point where LKGR info is worth the hassle of implementing something, >> if >> automation could just run `repo manifest -r` and commit and push the >> output to >> an "lkgr" branch of the manifest.git repository, that might make the >> hassle a >> bit less than setting up an XML-RPC manifest-server to do the same job. >> >> > Initially i was hoping to get a similar setup with git submodule instead >> > of >> > repo, but submodule won't let us track a 'branch' to 'updating' all >> > trees >> > isn't as simple, and also i had some troubles because 'bitbake' is in >> > oe-core/.gitignore, and that would prevent me from adding the bitbake >> > submodule... anyways, i think 'repo' >> > >> > feel free to respond if you have any feedback. but basically it looks >> > like we >> > might use a similar setup for one of our next projects here. >> >> It looks to me like a good setup. I hope to hear more about it in the >> future. >> >> Regards, >> Christopher >> >> -- >> Employee of Qualcomm Innovation Center, Inc. >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >> hosted by the Linux Foundation. _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
