[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [scl.org] [CentOS-devel] CBS build tags and git branches names for SCL



On 02/24/2015 08:47 AM, Honza Horak wrote:
On 02/23/2015 08:39 PM, Thomas Oulevey wrote:
 > CBS build tags in format like:
 >    sclo6-mariadb100-build
 >    sclo7-mariadb100-build

We need to keep the disttag in the name as agreed from the beginning for
all SIGs:
sclo6-el6-mariadb100-build
sclo7-el7-mariadb100-build

OK, understood.

(scol7-el7_1-mariadb-build maybe ; However I don't remember if the SIG
agreed to have 1 disttag only per distribution policy even for rhscl
rebuild; which is the way to go if you ask me :).

The disttag can be some other string not containing major; e.g: .infra.

I need a way to parse it consistently and existing scripts have been
written this way.

There is one piece I'm struggling with (and I'm not sure if that's the
same thing you call special disttag for rhscl rebuild). It is how to
deal with conflicting NVRs in koji (supposing CBS koji also doesn't
allow two build tasks resulting into the same NVR).

When we build some SRPM first in sclo project and then import the same
SRPM to rpms project (so we're able to build it from SCM, sign it and
release), then koji build will fail, because we already have the same
NVR built from SRPM, right?

I'm thinking if we can solve this by disttag, so e.g. every build from
SRPM would get something like ".el6.test" and only SCM builds would get
".el6". As far as I understand koji, that would require another build
target, right?

Maybe there is some nicer way to handle this or you may convince me we
don't need to solve this at all and just handle it with release bumps.
(just thinking loudly now)

I'm also still thinking about destination tags for sclo SIG -- currently there are those two proposed for every elX version: scloX-testing and scloX-release..

And the process (as I understand it) requires rpms first to be tagged into scloX-testing and after it tag those built from SCM into scloX-release.

I'm not sure if the middle step with scloX-testing is required for rpms coming from 'rpms' git project actually, since those should already be tested from 'sclo' git project.

So, can we actually simplify the process and tag into scloX-release right after building from 'rpms' git project?

If not, then I'd propose to have some different tag for not-yet-released rpms from the stable repos (e.g. scloX-candidate)

Then it would work like this:
rpms built from 'sclo' git repos will be tagged into scloX-testing
rpms built from 'rpms' git repos will be tagged first into scloX-candidate and then into sclX-release on releasing

Thoughts?

Honza


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]