- 1. Preparations
- 2. Version
- 3. Changelog
- 4. Git Tag
- 5. Package Builds
- 6. Build Server
- 7. Release Tests
- 8. GitHub Release
- 9. Chocolatey
- 10. Post Release
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 = [email protected]
name = Michael Friedrich
signingkey = D14A1F16
Check issues at https://github.com/Icinga/icinga2
For minor versions you need to manually backports any and all commits from the master branch which should be part of this release.
Update the .mailmap and AUTHORS files:
git checkout master
git log --use-mailmap | grep '^Author:' | cut -f2- -d' ' | sort | uniq > AUTHORS
Update the version:
sed -i "s/Version: .*/Version: $VERSION/g" VERSION
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 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
mkdir $HOME/dev/icinga/packaging
cd $HOME/dev/icinga/packaging
git clone [email protected]:icinga/rpm-icinga2.git && cd rpm-icinga2
git clone [email protected]:packaging/deb-icinga2.git && cd deb-icinga2
git clone [email protected]:icinga/raspbian-icinga2.git && cd raspbian-icinga2
git clone [email protected]:icinga/windows-icinga2.git && cd windows-icinga2
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)
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"
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 <[email protected]> 2.11.0-1
- Update to 2.11.0
Update file debian/changelog
and add at the beginning:
icinga2 (2.11.0-1) icinga; urgency=medium
* Release 2.11.0
-- Michael Friedrich <[email protected]> Thu, 19 Sep 2019 10:50:31 +0200
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.
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.
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!
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
- 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.
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
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
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.
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/
Only required for major releases.
Navigate to puppet-customer/icinga.git
and do the following steps:
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.
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
SSH into the webserver or ask @bobapple.
cd /usr/local/icinga-docs-tools && ./build-docs.rb -c /var/www/docs/config/icinga2-latest.yml
- 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
- Add new minor version on GitHub.