There was recently a discussion on the Fedora Rel-Eng list as the
result of a Project Planning workflow. As this was discussed
further in irc it was decided that this is likely a conversation that
should be had across more Fedora groups to see if there's a solution
that we would all like to utilize. If we can all agree on a workflow
and utility we'll hopefully remove the potential for duplicating
efforts or requesting multiple solutions to the same problem be hosted
by the Infrastructure team. In an attempt to not cross-post I am
duplicating this post on the rel-eng, qa, infrastructure, docs,
buildsys, and env-and-stacks mailing lists. I would like to request
that if there are any discussions around this, please rely to the
rel-eng list so we can consolidate the discussion.
All interested parties please fill out the following WhenIsGood so
that we can find a meeting time to discuss this.
 - https://lists.fedoraproject.org/pipermail/rel-eng/2015-April/019806.html
Hi. The attached patch implements a mergeScratch() method. This
enables importing the rpms built by a scratch build and associating them
with an existing build, if that build was built from the same SCM URL
and has the same NVR.
The use-case for the method is arch enablement. The general approach
- setup a new build tag that builds only for the new arch
- this would use either imported rpms or an external repo of rpms
that had been built/bootstrapped manually
- run a scratch build in the new build tag, from the same SCM URL as
an existing build
- call mergeScratch(scratch_task_id)
- rpms built for the new arch are added to the existing build
This allows arch coverage to be added incrementally to existing builds
in a non-disruptive way. When all builds in the -build tag have rpms
for the new arch, the arch can be enabled in the main tags and all new
builds will generate rpms for the new arch. This simplifies the
bootstrap process for a new arch, and avoids mass-rebuilds that would
result in no change in the existing arch rpms.
This could be accomplished with the existing rpm import functionality,
but mergeScratch() retains the build logs and the buildroot metadata
(associated with the scratch build task) so merged rpms have better
tracking and auditability.
Questions and comments welcome.
This should make it easier to track the state of a specific task and any
child tasks it creates. While this may be considered a change to the
public API, it is an additive change and I can't imagine any current
use-cases it would affect.