[scl.org] Changes to the SCL SIG workflow

Honza Horak hhorak at redhat.com
Tue Mar 10 17:13:49 UTC 2015


Since the first draft of workflow was proposed at [3], there have been 
few issues found and discussed, so it seems to be worth to change it a bit.

One thing is that we should ship RHSCL collections in a *separate 
repository*, so even people using supported RHSCL (repository provided 
by RH) can use the other non-RH collections easily. Those non-RH SCLs 
may extend RHSCL collections and we get something like EPEL for RHSCL.

Another thing is that the workflow as proposed initially did suffer from 
duplicate NVR issue, i.e. when we would build one package from SRPM, we 
wouldn't be able to build the same NVR again from SCM... Thus, it seems 
easier to build from SCM even for the testing RPMs -- those RPMs just 
get tagged into 'scloX-testing' first, then the same RPMs get tagged 
'scloX-release'.

However, the above simplified workflow may be valid for non-RHSCL 
collections only, since for RHSCL rebuilt collections we want to rebuild 
RPMs automatically as soon as they are shipped by RH. We also don't plan 
to do any changes there, it will be pure rebuild, so we end up with 100% 
compatible rebuilds. Those builds also will be done from SCM and tagged 
into -testing and later to -release tags (repositories; is something 
like scloX-rhscl-testing and scloX-rhscl-release feasible or do we have 
any better name?).

The problem comes when we consider the upstream development for RHSCL 
packages -- for example we first build aaa-1.2-3 package for testing 
purposes and then the same NVR is shipped in RHSCL; so it gets rebuilt 
automatically in centos, but it may fail, because we could get to 
duplicate NVR issue again.

A solution here is to use a *different disttag* (and thus also a 
different build target) for upstream (future) RHSCL packages (as 
mentioned above, for non-RH collections this is not necessary, those 
will be built only once everytime). Thus, the testing (upstream/future) 
package will be aaa-1.2-3.el6.test while the final rebuild will be 
aaa-1.2-3.el6. No duplicate NVR.

So, to sum it up, the RHSCL workflow need to be a bit different from the 
non-RH workflow and the workflow for RHSCL is actually different for 
released packages and for upstream (future) packages. The following are 
the three workflows described above:


Workflow schema for non-RH collections:
=======================================

     git.c.o       CBS         scl.org [1]
-----------------------------------------
   develop in
  sclo project
       |
       |
       |
  import srpm
   into rpms
    project
           \
            \
             \
              build package
                 from scm
                    |
                    |
                    |
                 tag into
               scloX-testing
                            \
                             \
                              \
                             available in
                             scloX-testing
                                 repo
                              /
                             /
                            /
                 tag into
               scloX-release
              sign & release
                            \
                             \
                              \
                             available in
                             scloX-stable
                                repo



Workflow schema for future RH collections (upstream development):
=================================================================

     git.c.o       CBS [2]      scl.org [1]      RH internal
-----------------------------------------------------------
   develop in
  sclo project
       |
       |
       |
  import srpm
   into rpms
    project
           \
            \
             \
             build testing package
                  from srpm
                      |
                      |
                      |
                 tagged into
                 scloX-testing
                            \
                             \
                              \
                              available in
                              scloX-testing
                                   repo    \
                                            \
                                             \
                                             import into RH
                                              internal git
                                                    |
                                                    |
                                                    |
                                            release in RHSCL


Workflow schema for *released* RH collections:
==============================================

     git.c.o       CBS            CI
-----------------------------------------
  import released
   srpm from RHSCL
  into rpms project
           \
            \
             \
            build testing package
                 from scm
                    |
                    |
                    |
               tagged into
            scloX-rhscl-testing
                           \
                            \
                             \
                             check sanity
                             /
                            /
                           /
                 tag into
            scloX-rhscl-release
              sign & release
                           \
                            \
                             \
                             available in
                          scloX-rhscl-stable
                                repo

[1] http://softwarecollections.org/
[2] http://cbs.centos.org/
[3] https://www.redhat.com/archives/sclorg/2015-February/msg00023.html




More information about the SCLorg mailing list