On 04/02/2013 03:21 PM, Marcin Juszkiewicz wrote:

W dniu 02.04.2013 18:09, Christopher Covington pisze:

...

Hi Marcin,

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.

Regards, Christopher

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 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%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

On 21 May 2013 07:51, Jonathan Aquilina eagles051387@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 cov@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 <cov@codeaurora.org mailto:cov@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%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.