This page aims to document our release process. It documents the release cycle, but also the steps required to make a release.
The release cycle
In general, each major Aegir release comprises a simultaneous release of all the modules that are part of the project. We generally go through several testing releases (alphas, betas & RCs) before doing the first stable release on a branch.
First an alpha is released to test new functionalities and to accomplish the goals decided in the project roadmap for that major version. Example: 3.0-alpha1
When we have covered most of the functionalities outlined in the roadmap, we push out beta releases until no more critical issues show up. This is generally considered a soft feature freeze. Example: 3.0-beta1
Then we go into full feature freeze and release a first release candidate (RC). Then a stable release branch is created, and the development branch is kept opened for development for the next stable release. This is generally considered a soft API freeze. Release candidates are made as long as critical bugs are found. Example: 3.0-rc1.
Once the development branch has no known critical bugs, the stable release is announced. From there on only critical fixes (security, critical performance and critical bugfixes) are committed to the stable branch, and stable releases are published (without alpha/beta/RC) directly on the stable branch. The stable branch is in full API freeze. New features are generally committed to the development branch.
Steps for a release
1. Make sure our tests are all green
Look into GitLab CI and Travis to see if all tasks have been performed without errors since the last commit. If there is an error, fix it before the release.
2. Verify drupal-org.make
In the hostmaster project we maintain our own drupal-org.make file. Verify that drupal-org.make specifies up-to-date versions. Check that e.g. the ctools version specified is not out-dated.
We build complete release notes for every release. Those are made up of a summary of the release, an outline of key changes, of known issues, install and upgrade instructions and a full list of bugfixes and new features.
As we have a number of Drupal.org projects to cover we try to centralize our release notes combined with the documentation. Published under the release notes section.
On Drupal.org we add a link to the version specific release notes page on the release nodes for all projects we cover.
This is done for the different git projects. Changing the first line to add 'to $name'.
The script release_notes.sh can be used to automate this step.
The developers then proceed to format/edit the list of fixes as well as list other significant information/changes for this release. These notes end up becoming the Release Notes for the release.
Add it as a new file under release-notes, and add a line to mkdocs.yml. And update the default page for the 'Release notes' section.
4. Running the release.sh script
Each time we make a new release, we run a script called release.sh in provision. This script does all the 'hard' work in that it doesn't forget all the very many places to edit version numbers etc of relevant documentation and other scripts. This includes updating upgrade.sh.txt.
It's best to start in a freshy cloned provision checkout. An extra remote to GitLab is needed for the packaging by GitLab CI.
$ ./scripts/release.sh 3.130 3.120Aegir release script====================This script should only be used by the core dev team when doing anofficial release. If you are not one of those people, you probablyshouldn't be running this.This script is going to modify the configs and documentation torelease 7.x-3.7.The following operations will be done: 0. prompt you for a debian/changelog entry 1. change the makefile to download tarball 2. change the upgrade.sh.txt version 3. change the .gitlab-ci.yml to build a release package 4. display the resulting diff 5. commit those changes to git 6. lay down the tag 7. revert the commit 8. clone fresh copies of hosting/hostmaster and eldir to lay down the tag 9. (optionally) push those changes10. clone fresh copies of golden contrib to lay down the tag11. (optionally) push those changesThe operation can be aborted before step 8. Don't forget that aslong as changes are not pushed upstream, this can all be reverted (seegit-reset(1) and git-revert(1) ).
Notice how we just provide the Aegir release number (3.11) to the release script, not the Drupal branch (7.x), which is hardcoded in the script to remove potential confusion.
Optionally, blog posts on koumbit.org, mig5.net, and elsewhere may go into further detail about significant changes, screencasts etc.
12. Debian repository management
The repo is managed with a tool called reprepro.
Gitlab scp's to /var/www/repos/incoming/ on the repo server. It has an ssh key stored as a secret variable.
On the repo server incrond waits for new files and trigers reprepro using /usr/local/bin/reprepro_process_incomming for them.
Setting up a GitLab runner
GitLab.com offers the use of shares runner VM's to use for CI, but we need a priviledged one to be able to use sudo and sub docker images.
As a project we maintain one runner for this, but if you want to experiment more in a feature branch of your own fork then it's best to setup a new one.
Documentation on setting one up is on https://docs.gitlab.com/runner/install/
The minimal memory requirement seems to be 1GB. And up to 10GB of disk storage.
Example config file /etc/gitlab-runner/config.toml:
When you have your own GitLab CI runner you can inspect the container while it's running the tests.
Adding an extra sleep 20m as a last task in the .gitlab-ci.yml script section would keep it alive a bit longer. The default timeout is 3600 seconds.
Use docker ps to get the container ID, and docker exec -ti [containerID] bash to get a shell inside the container.