[Debian-salsa-ci] Publishing multiple packages with aptly in Salsa CI

[Paul Boddie]

On Friday, 15 September 2023 16:33:25 CEST Philip Hands wrote:
>
> For another angle, see:
> 
>   https://salsa.debian.org/philh/user-setup/-/pipelines/576662
> 
> In which I have a `harvest-repos` job that grabs artifacts from `build`
> jobs in other pipelines, and an `aptly-plus` job that's got an added
> `needs: harvest-repos` that can combine the artifacts from its build and
> harvest-repos jobs and lump them all together.
>
> In the resulting aptly repo you can see that it includes both the
> local package (user-setup) under the 'u' directory, and 'grub-installer'
> under the 'g' directory:
>  
> https://salsa.debian.org/philh/user-setup/-/jobs/4671054/artifacts/browse/
aptly/pool/main/

Yes, that was the desired effect: have packages corresponding to several 
source packages being made available in the pool and thus the created package 
repository.

> That's done with:
> 
>   https://salsa.debian.org/installer-team/branch2repo/
> 
> Quite a lot of that is already part of the standard salsa-CI pipeline,
> and my aim is that branch2repo will pretty-much disapear, with its
> components being optional bits of the standard pipeline, and maybe a few
> variable settings.

Indeed. As noted before, my modifications were effectively (1) to keep the 
source repository around to get access to my scripts, (2) to be able to add 
package repositories to the apt configuration, (3) to download packages so 
that aptly can process them.

(1) is just preferable to writing scripts in the horrible YAML syntax and then 
doing fragment inclusion, which I found can lead to opaque error messages. 
Being able to obtain a set of scripts would be quite helpful generally as the 
environment can vary substantially from one kind of job to another.

(2) is something that could be part of the standard job definitions, 
particularly since other jobs like autopkgtest need to know about additional 
repositories in certain cases, brand new packages being one of them.

(3) is just a small enhancement for this specific scenario.

I thought that someone must have done this before, even if the standard 
pipeline didn't support it. I imagine that some coordination would be 
desirable to prevent fragmentation and people like me introducing our own ways 
of addressing this particular need.

Paul