Skip to content

Add variables SALSA_CI_SETUP_SCRIPT, SALSA_CI_PIUPARTS_PRE_INSTALL, SALSA_CI_PIUPARTS_POST_INSTALL

Carles Pina i Estany requested to merge setup-scripts into master

Introduce new variables: SALSA_CI_SETUP_SCRIPT, SALSA_CI_PIUPARTS_PRE_INSTALL, SALSA_CI_PIUPARTS_POST_INSTALL

They are used in different places:

  • SALSA_CI_SETUP_SCRIPT: at the build job, autopkgtest and reprotest
  • SALSA_CI_PIUPARTS_PRE_INSTALL_SCRIPT/POST_INSTALL_SCRIPT: at piuparts before/after installation

Why adding them? As it is now debusine's debian/rules it does:

override_dh_auto_test:
        dh_auto_test -- --system=custom --test-args="make coverage"

"make coverage" executes the unit tests and they need Postgresql and Redis running.

override_dh_auto_test is called in the build, reprotest and autopkgtest[1] jobs. The SALSA_CI_SETUP_SCRIPT variable points to a script to apt-get Postgresql and Redis in order for the unit tests to work as expected and setup the pinning for python3-django package (needed only for the autopkgtest).

[1]: autopkgtest (actually invoked via debci) could use the *.deb via artifacts from the build step. At the moment salsa-ci.yml uses the *.changes and rebuilds it (I can double check this in case that I missed something). Long story short: for autopkgtest I could have made use of --setup-commands=apt-get install python3-django/bullseye-backports and --add-apt-source (via debci_autopkgtest_args environment variable) but I used a --setup-commands=script_specified_by_the_user to keep it aligned with other jobs.

Piuparts only needs to install python3-django from bullseye-backports. The script in SALSA_CI_PIUPARTS_PRE_INSTALL_SCRIPT sets the apt.d preferences file for this. SALSA_CI_PIUPARTS_POST_INSTALL_SCRIPT is not used but added it for completeness.

The main question for me for since it's the first time diving into the salsa-ci-team/pipeline:

  • Do these changes make sense (in high level) and should I make a MR into https://salsa.debian.org/salsa-ci-team/pipeline/ ?
  • Should, instead, avoid calling "make coverage" in "override_dh_auto_test"? This would remove the need of installing postgresql/redis at the build time. The tests would still happen via autopkgtest (in theory, if everything is good there)

Merge request reports