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