Dennis Debian Build Pipeline toolbox
Table of Contents
1. A random collection of interesting tidbits
1.1. Installation of a build node
The orginal intent was to have a somewhat beefy system to
run dpkg-buildpackage for custom packages not found in Debian.
But the idea grew that we could also run rpmbuild by using
containers so we don't have another machine for RPM building.
- old worker node (out of support; >5 years old
- Reinstalled with standard Debian 12 (bookworm)
- set up local users with sudo rights (just the admin team)
- set up gitlab-runner user
1.2. Setting up the build system
For Debian packaging, there is a common set of base packages.
The Debian Wiki is a good source of information.
Other useful info found here: https://www.debian.org/doc/devel-manuals
Installed rpm (which was ported to Debian). Unfortunately mock
is no longer available in Debian (takers?)
Additional packages: quilt, dh-make, git-buildpackage
1.2.1. Set up sbuild
With helper script sbuild-debian-developer-setup for each user.
Sbuild builds packages 'Debian style' inside a minimalistic chroot (analogue to mockbuild for RPMs).
1.2.2. Setting up a local repo with reprepro
This can be used to build packages that build-depend on other packages build locally.
To automatically process the 'incoming' directory:
apt install inoticoming
/usr/bin/inoticoming --logfile /srv/repo/logs/i.log /srv/repo/incoming/bookworm/ \
--stderr-to-log --stdout-to-log --suffix '.changes' --chdir /srv/repo \
reprepro -b /srv/repo --waitforlock 100 processincoming bookworm {} \;
To make this repo visible inside the sbuild chroot, in
/etc/schroot/sbuild/fstab where the mounts are specified we add
/srv/repo /srv/repo none ro,bind 0 0
which 'bind mounts' the reprepro repository.
(see https://wiki.debian.org/sbuild#Customizations_of_sbuild_chroots)
1.3. The Gitlab CI pipeline
Very early work, just a bsic proof-of-concept at the moment.
stages: # List of stages for jobs, and their order of execution
- sbuild
- test
- release
build-job: # This job runs in the build stage, which runs first.
stage: sbuild
script:
- echo "Starting buildpackage"
- gbp buildpackage --git-tarball-dir=/srv/builder/original-tarballs/ --git-builder=sbuild --git-ignore-branch --git-ignore-new
- echo "Compile complete."
unit-test-job: # This job runs in the test stage.
stage: test # It only starts when the job in the build stage completes successfully.
script:
- echo "In the future we will run piuparts."
release-package: # This job runs in the deploy stage.
stage: release # It only runs when *both* jobs in the test stage complete successfully.
environment: production
script:
- dput local-bookworm `debc --list-changes`
As a kludge, needed to place the original tarball on the runner system in /srv/builder/original-tarballs.
(Normally uscan should be used to retrieve original releases from upstream, but for
Torque that is probably a little unreliable.)
1.4. Packaging styles
The torque procedure is an example where the packaging is maintained separately in git.
If your software is home-grown it may have a debian/ packaging directory included
and building goes a little different.
stages: # List of stages for jobs, and their order of execution
- sbuild
- test
- release
build-job: # This job runs in the build stage, which runs first.
stage: sbuild
script:
- echo "Starting buildpackage"
- sbuild
- echo "Compile complete."
unit-test-job: # This job runs in the test stage.
stage: test # It only starts when the job in the build stage completes successfully.
script:
- echo "In the future we will run piuparts."
release-package: # This job runs in the deploy stage.
stage: release # It only runs when *both* jobs in the test stage complete successfully.
environment: production
script:
- dput local-bookworm `debc --list-changes`
1.5. Future
mockbuilds inside podman! Containers inside containers!