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.
On Mon, May 20, 2013 at 9:22 PM, Christopher Covington cov@codeaurora.orgwrote:
Hi Nicolas,
On 05/17/2013 09:20 AM, Nicolas Dechesne wrote:
On Wed, Apr 3, 2013 at 2:24 PM, Christopher Covington <
cov@codeaurora.org
mailto:cov@codeaurora.org> wrote:
>> I notice you've created a number of shell scripts to managechecking out
>> multiple git repositories, specific revisions of git repositoriesfor a
>> release, etc. Repo [1] does this stuff pretty well that you mightwant to
>> consider as an eventual alternative. > > I was considering repo few times but jenkins-setup scripts areused not
> only to fetch/update/freeze git repositories but mostly to handlebuild
> jobs (at CI or any other machine). I'm glad to hear that you've looked into it. There's certainly a lotmore to
automation than revision control, although Repo does seem to playwell with
others in my experience. Anyhow, I just figured if there was anunexplored
possibility to make things easier for developers and users, I'd tryto
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%3Ba=blob%3Bf=defa...
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%3Ba=shortlog%3Bh=...
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