Re: Package testing with Salsa CI for new packages
On Sunday, 20 August 2023 14:06:37 CEST Carles Pina i Estany wrote:
>
> Interesting approach, but if you could use the variables and ship the
> shell script it might reduce some duplication between jobs (if possible,
> I haven't look into too much detail in your case) and more importantly
> you might be able to use the standard "autopkgtest" or "piuparts"
> (instead of redefining them).
I have continued along such a path.
> Just last week I created a new autopkgtest (I have it running on
> bookworm and bullseye). It's done this way:
> ------
> autopkgtest-bullseye:
> extends: .test-autopkgtest
> variables:
> RELEASE: "bullseye-backports"
> SALSA_CI_AUTOPKGTEST_ARGS:
> '--setup-commands=ci/pin-django-from-backports.sh
> --skip-test=debusine-doc-linkcheck' ------
>
> Or, for more context:
> https://salsa.debian.org/freexian-team/debusine/-/blob/add-bullseye-support/
> .gitlab-ci.yml#L84 It ends up having "autopkgtest" and
> "autopkgtest-bullseye". But using the variable SALSA_CI_DISABLE_AUTOPKGTEST
> I could disable the one without my extends.
Previously, I had merely redefined the autopkgtest and piuparts jobs,
replacing them with ones that use the customised code:
autopkgtest:
extends: .test-autopkgtest-revised
piuparts:
extends: .test-piuparts-revised
I had assumed that such redefinition was possible. When people decide to
introduce a new language, as GitLab appear to have done, they should realise
that they need to match the considerable levels of documentation that existing
languages may have. Fortunately, my assumptions were correct.
Following your lead, I have since found that the following works:
autopkgtest:
extends: .test-autopkgtest
variables:
SALSA_CI_AUTOPKGTEST_ARGS: '--setup-commands=debian/salsa/add-
repositories.sh'
piuparts:
extends: .test-piuparts
variables:
SALSA_CI_PIUPARTS_PRE_INSTALL_SCRIPT: 'debian/salsa/add-repositories.sh'
You can see that by defining the variables to customise the tools, I am able
to work with the existing job definitions. This simplifies the CI description
file considerably:
https://salsa.debian.org/moin-team/moin/-/blob/debian/master/debian/salsa-ci.yml
The script is pretty straightforward, too:
https://salsa.debian.org/moin-team/moin/-/blob/debian/master/debian/salsa/add-repositories.sh
It is so mundane that I could imagine it being replaced by standard
functionality very easily.
[Job numbers]
> If it's in the same pipeline: you don't need the numbers to get the
> artifacts (the .deb files from build).
The .deb files are produced by the pipelines associated with other package
repositories. Thus, Aptly is used to make the .deb files available to the Moin
package's pipeline. I imagine that I could build the dependencies in the same
pipeline, however. Apparently, GitLab's non-free editions support "multi-
project" pipelines, but I suspect that Aptly has been introduced to get around
the lack of such functionality in the free edition.
> For the aptly generated artifact: I will investigate this tomorrow (to
> fetch it and try to use) (I want to replace some code that I did with
> the aptly repo, if possible).
Good luck with that task! :-)
As a result of this discussion and a lot of effort, I have managed to get
autopkgtest and piuparts to see and to use the package dependencies needed by
the Moin package. This allowed me to tackle the test suite that had caused me
to look at all of this in the beginning. And now, it seems that I can get all
the reasonable tests to pass:
https://salsa.debian.org/moin-team/moin/-/pipelines/567871
Once again, many thanks for all the guidance!
Paul
Reply to: