Commit 1baca5de authored by ale's avatar ale
Browse files

Explain the multi-release build logic in README

parent f33eacf7
......@@ -15,9 +15,15 @@ to be included in other projects' *.gitlab-ci.yml* files.
For package upload, the following environment variables should be set:
* `REPOSITORY_SSH_PRIVATE_KEY` is the private SSH key to use for authentication
* `REPOSITORY_NAME` is the urepo repository name
* `REPOSITORY_URI` is the repository target hostname (or user@hostname)
By default, the CI scripts are set up to upload packages to different
repositories based on the Debian release they've been built for
(repositories float/*codename*), but it is possible to override the
repository name autodetection with another environment variable:
* `REPOSITORY_NAME` is the urepo repository name
# Usage
In order to maintain centralized control over the package build
......@@ -31,28 +37,58 @@ file like the following:
include: ""
It is then possible to add additional stages (like testing, for instance):
The default template already includes the *test* (empty, no jobs
defined here by default), *build* and *release* stages, so you can
directly add jobs to them:
include: ""
- test
- build_pkgsrc
- build_pkg
- upload_pkg
stage: test
script: tox -e py27
script: tox -e py3
if you override the *stages* list, remember to add the build-deb stages
in order: *build_pkgsrc*, *build_pkg*, *upload_pkg*.
# Customizations
The *stretch* base images will pull Go packages from *stretch-backports*,
to help building our Go packages that require some recent features.
# Release policy
We have a few knobs to tweak in order to facilitate the process of
following the current Debian stable release when it changes. These
* The ability to build packages for different releases at once, and
upload them to different repositories. At any given moment, we
shouldn't need more than two (either *stable* and *nextstable*, or
*oldstable* and *stable*).
* The ability to decide which release build should cause pipelines to
fail, i.e., which releases are "important" and which aren't. Using
this we can do gentle phased roll-ins of new releases (or phase-outs
of old ones).
We can identify a few stages we can adopt to follow the Debian stable
release upgrade process:
* In the "normal" stage, we're not particularly interested yet in
targeting the next stable release, so *ci-common.yml* will only
include a build on the stable release.
* When the next testing release starts to stabilize, we add it to
*ci-common.yml* in optional (no pipeline failure) mode, to see which
packages will need work without interrupting their release workflows.
* When we start experimenting with the new "next" stable release, we
remove the optional bit on those builds, and fix the packages that
are broken in the new release. Once that is done, we are ready to
upgrade the servers once the next Debian release becomes *stable*.
* After all servers are upgraded, we can start to drop the old
build. Depending on whether there are other users of the packages or
not, we can set the optional bit on the old builds and keep them
around for a while, before returning to stage 1.
# Alternative scripts
Most packages should include *ci-common.yml*, but there are other
scripts for packages that have specific, custom requirements:
* *ci-backports.yml*, identical to *ci-common.yml* but includes
backports. Mostly used by Go packages to overcome issues with the
Buster Go version being too old.
* *ci-buster.yml*, only builds packages for Debian Buster
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment