[opensuse-buildservice] best practices advice
I was hoping to get some advice about how to arrange things in a local build service. Let's say we have a series of developers. Sometimes they work on stuff that's really only interesting to them, othertimes (more often) they are working on projects which will eventually make it into production. Let's also say that you want to allow a two- or three- tiered environment, where individual developers will have their own projects, where there will be a shared development environment (like staging), and then production. What I'd like to know is how people set things up so that developers can say something like "OK, production manager, package FOO version BAR is ready to go" and have that person (the production manager) place package FOO (version BAR) into the production environment. Ditto for all appropriate dependencies, etc... Basically, how do you set things up so that there can be several internally consistent environments (projects), such that a person that manages the production environment get acquire packages without lots of hoop jumping. At first blush, it seems that linking or aggregating would work, but it seems as though if the source package changes then it gets rebuilt everywhere it is linked. That is not desirable in this case. Obviously, one could just do something like a "copy" but is there a better way? Can links work with a specific (build service) version? How are others cracking this particular nut? -- Jon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 2009-07-10 08:47:58 -0500, Jon Nelson wrote:
I was hoping to get some advice about how to arrange things in a local build service.
Let's say we have a series of developers. Sometimes they work on stuff that's really only interesting to them, othertimes (more often) they are working on projects which will eventually make it into production.
Let's also say that you want to allow a two- or three- tiered environment, where individual developers will have their own projects, where there will be a shared development environment (like staging), and then production.
What I'd like to know is how people set things up so that developers can say something like "OK, production manager, package FOO version BAR is ready to go" and have that person (the production manager) place package FOO (version BAR) into the production environment. Ditto for all appropriate dependencies, etc...
Basically, how do you set things up so that there can be several internally consistent environments (projects), such that a person that manages the production environment get acquire packages without lots of hoop jumping.
At first blush, it seems that linking or aggregating would work, but it seems as though if the source package changes then it gets rebuilt everywhere it is linked. That is not desirable in this case. Obviously, one could just do something like a "copy" but is there a better way? Can links work with a specific (build service) version?
How are others cracking this particular nut?
http://en.opensuse.org/Build_Service/Collaboration thats how we handle it at suse. when ever a developer thinks the package is ready for the next stage, they do a submitreq to that project. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
So, this is how we solved this for our internal OBS instance. I wrote this app called svndownstream that calls into osc and works from a Subversion workarea. Developers check out the code they want to work from from Subversion, so if it's a mod developed by one user they'd checkout trunk and just work in their workarea, if a group needs to develop something longer they'd branch trunk into a feature branch, branches/FOO. So svndownstream reads a property (svndownstream:configuration) in the Subversion workarea that has which OBS project/package pair is the source/devel project for the this Subversion source. Then, svndownstream asks the server for all packages that link to this source (an extension we made to the OBS server) and returns this as output from 'svndownstream ls'. The developer can then use those values for svndownstream build, checkout, or update, which are all wrappers around the osc equivalent, but check that the Subversion source corresponds to the OBS workarea. 'svndownstream ls' shows things like the platform release project (equiv of openSUSE:Factory, openSUSE:11.1, SLES:11, etc) that use that source. We separate different release branches of source by naming the source/devel project PACKAGE:BRANCH and then having the package in it. This means most devel projects have only one package in them, but for packages that share source, such as the kernel, there are multiple ones (kernel-source, kernel-syms, kernel-FLAVOR, etc). Having separate source project, that do no actual platform release builds mean we can list developers as Maintainers of PACKAGE:BRANCH, but restrict them from messing with PLATFORM:RELEASE project. If a developer is making a change that may affect something downstream in the dependency graph (e.g. they are changing the kernel, and so kmp packages are affected) we have a subcommand called 'svndownstream dependents'. 'svndownstream dependents build' will calculate a dependency graph for the entire OBS package set and then figure out which packages depend (e.g. would be rebuilt) if you changed the source in the Subversion workarea. All packages that are dependents are branched into home:USER:branches:BRANCH and the Build Repositories are rewritten such that all packages under home:USER:branches:BRANCH use each other for their build repositories whenever possible, so home:USer:branches:BRANCH:PLATFORM:RELEASE would list PLATFORM:RELEASE as a Build Repository path (as normal osc branching does), but it would also have home:USER:branches:BRANCH:kernel:RELEASE in it so that the branch platform uses the kernel with the developers changes. Right now the dependency graph calculation needs work as it's being recalculated for each call as I couldn't figure out a way to extract the dependency graph from bs_sched. (Seriously, that is some of the hardest perl code to follow, too many acronym variable names and fun with special variables.) Jon Nelson wrote:
I was hoping to get some advice about how to arrange things in a local build service.
Let's say we have a series of developers. Sometimes they work on stuff that's really only interesting to them, othertimes (more often) they are working on projects which will eventually make it into production.
Let's also say that you want to allow a two- or three- tiered environment, where individual developers will have their own projects, where there will be a shared development environment (like staging), and then production.
What I'd like to know is how people set things up so that developers can say something like "OK, production manager, package FOO version BAR is ready to go" and have that person (the production manager) place package FOO (version BAR) into the production environment. Ditto for all appropriate dependencies, etc...
Basically, how do you set things up so that there can be several internally consistent environments (projects), such that a person that manages the production environment get acquire packages without lots of hoop jumping.
At first blush, it seems that linking or aggregating would work, but it seems as though if the source package changes then it gets rebuilt everywhere it is linked. That is not desirable in this case. Obviously, one could just do something like a "copy" but is there a better way? Can links work with a specific (build service) version?
How are others cracking this particular nut?
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (3)
-
Jon Nelson -
Luke Imhoff -
Marcus Rueckert