Re: Package testing with Salsa CI for new packages
On Friday, 18 August 2023 19:54:55 CEST Carles Pina i Estany wrote:
>
> Ha! I wasn't aware of the aptly option
> (https://salsa.debian.org/salsa-ci-team/pipeline/#using-automatically-built-> apt-repository and SALSA_CI_DISABLE_APTLY=0).
> I think that I might have re-invented the wheel in a tiny part of
> Debusine CI/CD.
It is certainly a way of propagating packages to those that might need them.
However, the instructions indicating how a package might access these
dependencies appear to be deficient.
It does not appear to be sufficient to merely specify the dependency package
repositories and mark them as trusted. Doing that will just cause the
repositories to be regarded as ignored and the GPG keys signalled as
unrecognised.
So, the GPG keys need to be obtained. This is a hassle because something like
wget is needed to do that, and then apt has to be persuaded not to fail in an
opaque way. So the modified recipe is something like this:
before_script:
- apt-get update
- NON_INTERACTIVE=1 apt-get install -y wget
- echo "deb https://salsa.debian.org/moin-team/emeraldtree/-/jobs/4575438/
artifacts/raw/aptly unstable main" | tee /etc/apt/sources.list.d/pkga.list
...
- wget -q -O /etc/apt/trusted.gpg.d/emeraldtree.asc https://
salsa.debian.org/moin-team/emeraldtree/-/jobs/4575438/artifacts/raw/aptly/
public-key.asc
...
- apt-get update
This seems to make the various jobs happy, but the one that I was most
concerned with remains unhappy! I don't actually need the dependencies for
anything other than autopkgtest, but that job employs its own environment
where the above recipe has no effect.
So, what I now need to do is to find out how I can make the new packages
available to autopkgtest specifically.
> I will point out at some things that might safe some time to you
> (great) or not (ignore! :-) ):
>
> debusine's .gitlab-ci.yml:
> https://salsa.debian.org/freexian-team/debusine/-/blob/devel/.gitlab-ci.yml
This is definitely useful for examples of the CI definition syntax and how
hidden jobs can be used to provide additional script fragments.
[...]
> The job autopkgtest, via debci command, runs autopkgtest:
> https://salsa.debian.org/freexian-team/debusine/-/jobs/4574458#L65
The difficult thing appears to be the configuration of this testing
environment. One approach might involve overriding the existing job
definitions to incorporate the injection of new packages.
[...]
> It's possible for sure. Other people in this list might come up with a
> different idea. I don't have almost any experience with Debian
> packaging, but I have some experience on the salsa CI. So I might be
> giving you solutions that might be sub-optimal! :-)
I think that you are giving me some good ideas at least. I do feel that I am
encountering problems that must have been encountered many times before, but I
could imagine that people do not use these tools in this way or have different
expectations of what they are able to accomplish.
As for Debian's tooling, I consider it rather chaotic. When I previously did
packaging, things like pbuilder were still in use, being slowly pushed aside
by sbuild and probably other things that are now forgotten or obsolete. There
always seems to be new things coming along, new mixtures of technologies, and
the potential for more confusion and uncertainty.
Paul
Reply to: