[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: