[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