Re: Package testing with Salsa CI for new packages
On Friday, 18 August 2023 09:51:29 CEST Carles Pina i Estany wrote:
>
> I'm not a Debian developer but I have some experience on Salsa CI, so I
> thought that I might be able to help... but then I was confused by a
> specific part of the message:
>
> On 17 Aug 2023 at 17:10:08, Paul Boddie wrote:
>
> [...]
>
> > For another package I have been working on, the Salsa CI facility has
> > proven to be usable, configured using files in debian/test, particularly
> > as it allows test-related dependencies to be specified independently.
> > However, this other package has no dependencies that are currently
> > unpackaged in Debian. Meanwhile, the testing of this new Moin package
> > depends on brand new packages somehow being made available.
>
> If this dependencies are available on the "build" step: could they be
> made available on the autopkgtest? I didn't quite understand why this is
> not possible. I've found the autopkgtest quite flexible (since the tests
> are scripts that could prepare some environment)
The package has dependencies on installation but these dependencies are not
strictly necessary when building. However, if I wanted to run the test suite
when building, I would indeed need to pull in these dependencies as build
dependencies so that the software being tested can run without import errors.
Since some of these dependencies are new packages, I had been specifying them
using the --extra-package option of gbp buildpackage in order to satisfy such
build dependencies, but these were really "test dependencies". I have since
decided that I would rather distinguish between build and test dependencies,
as previously noted.
I have to add that the other package I refer to has a test suite that takes a
long time to run, so that is another reason why I chose Salsa CI for that
package instead of letting autopkgtest do its work:
https://salsa.debian.org/pboddie/shedskin
When I get the courage to do so, I will probably submit an intention-to-
package for that package.
[...]
> For me, the packages on the build job are made available via a Salsa
> artifact automatically (and easy to download as a .zip of the *.deb). I
> think that this happens on all the "build" jobs on Salsa CI. They can be
> downloaded as a .zip file
> (e.g. https://salsa.debian.org/freexian-team/debusine/-/jobs/4564890,
> right hand side "Job artifacts" and click "Download"). Would that be
> enough?
I think the problem is that when running the test suite, the Moin package
would need to obtain the test dependencies specified in debian/test/control.
These include various new packages that cannot be obtained from the usual
Debian archives, and so some kind of equivalent to gbp's --extra-package would
be needed in the Salsa CI environment.
One can imagine having a common storage area holding these newly introduced
packages that the CI scripts could access in preference to the usual archives.
In fact, this would be something that might also affect existing packages.
Consider the situation where fixes to a dependency are required to fix
functionality in a particular package. One would have to wait for the fixed
dependency to become integrated into the unstable archive before the principal
package's tests would start to work again.
> I also created a repo and hosted it on a Salsa CI page for internal
> testing but this is a bit of a workaround. This is in a new job but just
> download the artifacts (via a Salsa CI dependency) and run
> dpkg-scanpackages and copy the files to the right place).
This sounds like something related to what might be required. In effect, you
seem to be doing what I am doing when I actually install my built packages in
a chroot. I run apt-ftparchive (which runs dpkg-scanpackages) to generate
Packages, Sources and Release files that tells apt about the new packages when
added as another package source.
In the Salsa CI environment, I would need to have the built packages (found in
the artefacts for each package's build job) copied somewhere that can then be
found by the Moin package's pipeline jobs and the scripts creating a special
repository of new packages.
Thanks for replying to my enquiry!
Regards,
Paul
Reply to: