[Debian-salsa-ci] merging branch2repo into pipeline?

[Philip Hands]

Hi again,

The idea of removing extract-source reminded me that I ought to try to
get as much as possible of branch2repo into pipeline, as optional
components, or some such, because that seems likely to allow others to
take advantage of the features while reducing my maintenance load and
the fragility that comes of things changing in pipeline affecting
branch2repo somehow.

I should probably point at an example of what branch2repo does, so that
people know what I've been up to:

  https://salsa.debian.org/philh/grub-installer/-/pipelines/694009

where you see a fairly normal salsa-CI pipeline.

The differences are that:

1) It has different defaults for which jobs to run (to suit udebs better)
   which I guess should remain in branch2repo, or perhaps in some
   pipeline_udeb variant?

2) It runs aptly by default (possibly also pulling build results from
   other jobs).

3) It also has a child job for building D-I, which it does by unpacking
   D-I's repo in a subdirectory, and then triggering a child pipeline on
   that (which is a trick I stole from pipeline's own tests IIRC).

   It would be nice to generalise that bit, so that others could build
   similar pipelines to trigger other things by setting some variables
   appropriately.

If you click right '>' (D-I / Child), you'll see what looks like a
slightly odd pipeline, building a mini-ISO (which it does with reference
back to the initial pipeline's aptly repo, so will include changes from
that build, and possibly from the builds of the included artifacts from
other repos).

It then has a multi-project trigger to 'openqa-link'. Clicking through
to openqa-link shows external jobs that are links to the jobs that are
run on openqa.debian.net in order to test the mini-ISO that includes the
changes produced by the version(s) in the initial aptly job.

BTW The openQA view of that is here:
https://openqa.debian.net/tests/overview?groupid=13&version=salsa_testing&distri=debian&build=-salsa-694014%3Aphilh%2Fgrub-installer%3Aforce-removable

Some of this is rather D-I specific, but I think the ability to marshal
multiple sets of build artifacts into a single aptly repo, and then use
it in the same pipeline for testing that assemblage is probably more
widely applicable.

Likewise the ability to trigger a child pipeline within the context of
the initial one seems like a generally useful thing to do.

If we managed to fit those things into the pipeline, then most of
branch2repo would probably disappear, which would be nice :-)

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-salsa-ci/attachments/20240702/0e241b36/attachment.sig>