9.3 KiB
Release Workflow
Table of Content
- 1. Preparations
- 2. Version
- 3. Changelog
- 4. Git Tag
- 5. Package Builds
- 6. Build Server
- 7. Release Tests
- 8. GitHub Release
- 9. Chocolatey
- 10. Docker
- 11. Post Release
Preparations
Specify the release version.
VERSION=2.11.0
Add your signing key to your Git configuration file, if not already there.
vim $HOME/.gitconfig
[user]
email = michael.friedrich@icinga.com
name = Michael Friedrich
signingkey = D14A1F16
Issues
Check issues at https://github.com/Icinga/icinga2
Backport Commits
For minor versions you need to manually backports any and all commits from the master branch which should be part of this release.
Authors
Update the .mailmap and AUTHORS files:
git checkout master
git log --use-mailmap | grep '^Author:' | cut -f2- -d' ' | sort -f | uniq > AUTHORS
Version
Update the version:
sed -i "s/Version: .*/Version: $VERSION/g" VERSION
Changelog
Choose the most important issues and summarize them in multiple groups/paragraphs. Provide links to the mentioned issues/PRs. At the start include a link to the milestone's closed issues.
Git Tag
git commit -v -a -m "Release version $VERSION"
Create a signed tag (tags/v) on the master
branch (for major
releases) or the support
branch (for minor releases).
git tag -s -m "Version $VERSION" v$VERSION
Push the tag:
git push --tags
For major releases: Create a new support
branch:
git checkout master
git push
git checkout -b support/2.12
git push -u origin support/2.12
Package Builds
mkdir $HOME/dev/icinga/packaging
cd $HOME/dev/icinga/packaging
RPM Packages
git clone git@git.icinga.com:icinga/rpm-icinga2.git && cd rpm-icinga2
DEB Packages
git clone git@git.icinga.com:packaging/deb-icinga2.git && cd deb-icinga2
Raspbian Packages
git clone git@git.icinga.com:icinga/raspbian-icinga2.git && cd raspbian-icinga2
Windows Packages
git clone git@git.icinga.com:icinga/windows-icinga2.git && cd windows-icinga2
Branch Workflow
Checkout master
and create a new branch.
- For releases use x.x[.x] as branch name (e.g. 2.11 or 2.11.1)
- For releases with revision use x.x.x-n (e.g. 2.11.0-2)
Switch Build Type
Edit file .gitlab-ci.yml
and comment variable ICINGA_BUILD_TYPE
out.
variables:
...
#ICINGA_BUILD_TYPE: snapshot
...
Commit the change.
git commit -av -m "Switch build type for $VERSION-1"
RPM Release Preparations
Set the Version
, revision
and %changelog
inside the spec file:
sed -i "s/Version:.*/Version: $VERSION/g" icinga2.spec
vim icinga2.spec
%changelog
* Thu Sep 19 2019 Michael Friedrich <michael.friedrich@icinga.com> 2.11.0-1
- Update to 2.11.0
DEB and Raspbian Release Preparations
Update file debian/changelog
and add at the beginning:
icinga2 (2.11.0-1) icinga; urgency=medium
* Release 2.11.0
-- Michael Friedrich <michael.friedrich@icinga.com> Thu, 19 Sep 2019 10:50:31 +0200
Release Commit
Commit the changes and push the branch.
git commit -av -m "Release $VERSION-1"
git push origin 2.11
GitLab will now build snapshot packages based on the tag v2.11.0
of Icinga 2.
Package Tests
In order to test the created packages you can download a job's artifacts:
Visit git.icinga.com
and navigate to the respective pipeline under CI / CD -> Pipelines
.
There click on the job you want to download packages from.
The job's output appears. On the right-hand sidebar you can browse its artifacts.
Once there, navigate to build/RPMS/noarch
where you'll find the packages.
Release Packages
To build release packages and upload them to packages.icinga.com tag the release commit and push it.
RPM/DEB/Raspbian:
git tag -s $VERSION-1 -m "Release v$VERSION-1"
git push origin $VERSION-1
Windows:
git tag -s $VERSION -m "Release v$VERSION"
git push origin $VERSION
Now cherry pick the release commit to master
so that the changes are transferred back to it.
Attention: Only the release commit. NOT the one switching the build type!
Build Infrastructure
https://git.icinga.com/packaging/rpm-icinga2/pipelines https://git.icinga.com/packaging/deb-icinga2/pipelines https://git.icinga.com/packaging/windows-icinga2/pipelines https://git.icinga.com/packaging/raspbian-icinga2/pipelines
- Verify package build changes for this version.
- Test the snapshot packages for all distributions beforehand.
Once the release repository tags are pushed, release builds are triggered and automatically published to packages.icinga.com
Release Tests
- Test DB IDO with MySQL and PostgreSQL.
- Provision the vagrant boxes and test the release packages.
- Test the setup wizard inside a Windows VM.
- Start a new docker container and install/run icinga2.
CentOS
docker run -ti centos:7 bash
yum -y install https://packages.icinga.com/epel/icinga-rpm-release-7-latest.noarch.rpm
yum -y install epel-release
yum -y install icinga2
icinga2 daemon -C
Ubuntu
docker run -ti ubuntu:bionic bash
apt-get update
apt-get -y install apt-transport-https wget gnupg
wget -O - https://packages.icinga.com/icinga.key | apt-key add -
. /etc/os-release; if [ ! -z ${UBUNTU_CODENAME+x} ]; then DIST="${UBUNTU_CODENAME}"; else DIST="$(lsb_release -c| awk '{print $2}')"; fi; \
echo "deb https://packages.icinga.com/ubuntu icinga-${DIST} main" > \
/etc/apt/sources.list.d/${DIST}-icinga.list
echo "deb-src https://packages.icinga.com/ubuntu icinga-${DIST} main" >> \
/etc/apt/sources.list.d/${DIST}-icinga.list
apt-get update
apt-get -y install icinga2
icinga2 daemon -C
GitHub Release
Create a new release for the newly created Git tag: https://github.com/Icinga/icinga2/releases
Hint: Choose tags, pick one to edit and make this a release. You can also create a draft release.
The release body should contain a short changelog, with links into the roadmap, changelog and blogpost.
Chocolatey
Navigate to the git repository on your Windows box which already has chocolatey installed. Pull/checkout the release.
Create the nupkg package (or use the one generated on https://packages.icinga.com/windows):
cpack
Fetch the API key from https://chocolatey.org/account and use the choco push
command line.
choco apikey --key xxx --source https://push.chocolatey.org/
choco push Icinga2-v2.11.0.nupkg --source https://push.chocolatey.org/
Docker
Only for final versions (not for RCs).
Once the release has been published on GitHub, wait for its GitHub actions to complete.
VERSION=2.12.1
TAGS=(2.12)
#TAGS=(2.12 2 latest)
docker pull icinga/icinga2:$VERSION
for t in "${TAGS[@]}"; do
docker tag icinga/icinga2:$VERSION icinga/icinga2:$t
done
for t in "${TAGS[@]}"; do
docker push icinga/icinga2:$t
done
Post Release
Online Documentation
Only required for major releases.
Navigate to puppet-customer/icinga.git
and do the following steps:
Testing
git checkout testing && git pull
vim files/var/www/docs/config/icinga2-latest.yml
git commit -av -m "icinga-web: Update docs for Icinga 2"
git push
SSH into the webserver and do a manual Puppet dry run with the testing environment.
puppet agent -t --environment testing --noop
Once succeeded, continue with production deployment.
Production
git checkout master && git pull
git merge testing
git push
SSH into the webserver and do a manual Puppet run from the production environment (default).
puppet agent -t
Manual Generation
SSH into the webserver or ask @bobapple.
cd /usr/local/icinga-docs-tools && ./build-docs.rb -c /var/www/docs/config/icinga2-latest.yml
Announcement
- Create a new blog post on icinga.com/blog including a featured image
- Create a release topic on community.icinga.com
- Release email to net-tech & team
Project Management
- Add new minor version on GitHub.