[CentOS-devel] CBS build tags and git branches names for SCL

[Honza Horak]

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