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

[scl.org] Changes to the SCL SIG workflow



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


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