ci: build the release .deb like a Debian buildd, as reusable pipeline workflow#9
Open
j4n wants to merge 3 commits into
Open
ci: build the release .deb like a Debian buildd, as reusable pipeline workflow#9j4n wants to merge 3 commits into
j4n wants to merge 3 commits into
Conversation
… workflow Match package build workflow to upstream Debian process: - Resolve build-deps from debian/control (apt-get build-dep) instead of a explicit package list. - Build as an unprivileged user - Use git-buildpackage and add support for tagless forks - Run dovecot unit tests, separately after build by preserving the build artifacts and re-applying the patches. - Guard deadlocked tests with an inactivity watchdog and retry to be resilient to Github runner enviroment-caused flaky tests. - Add `Skip-flaky-cpu-limit-tests.patch` to avoid busy-loop tests that take forever on Github CI - Add reproducibility testing with reprotest and publish .buildinfo - Add autopkgtest integration tests in Incus system containers - Consolidate building and testing into 'deb pipeline' workflow in `pipeline.yml` that runs a separate workflow chain per bookworm/trixie x amd64/arm64 combination in `build-staging-deb.yml`; release publishing is subsequently handled by `release.yml`. - Add README-chatmail.md with CI details and upstream references - Bump debian/changelog to 1:2.3.21+dfsg1-3+chatmail1 and add a new version increment
The upload step in the reusable pipeline had three problems:
1. `rsync -rILvh --mkpath $GITHUB_WORKSPACE/build-area/ ...` uploaded
the entire build tree (1.1 GiB); restrict to the three binaries we
actually need downstream (dovecot-core, dovecot-imapd, dovecot-lmtpd)
plus the source (.dsc, .tar.*) and upload metadata (.changes,
.buildinfo) coherent with the github release.
2. Wrap rsync upload in a retry loop to address a race condition on
rrsync's per-directory lock that gets hit when two arches of the same
distro try to upload simultaneously:
/usr/bin/rrsync error: Another instance of rrsync is already
accessing this directory.
3. rrsyncs chroot means we need to send a relative path
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Match package build workflow to upstream Debian process:
Skip-flaky-cpu-limit-tests.patchto avoid busy-loop tests that take forever on Github CIpipeline.ymlthat runs a separate workflow chain per bookworm/trixie x amd64/arm64 combination inbuild-staging-deb.yml; release publishing is subsequently handled byrelease.yml.