Gitlab Runner 10.1 release checklist
GitLab Runner Release manager: @nolith
Release blog post MR: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/7386
Runner entries need to be added to blog post until: 2017-10-12
Technical description of the release, with commands examples, can be found at: https://gitlab.com/gitlab-org/gitlab-runner/blob/master/docs/release_process/how_to_release_runner.md
Before 7th
-
chose a release manager -
link release blog post's MR -
set deadline for add entries to release blog post Please check what deadline is set for `General Contributions` section in the release blog post Merge Request. It should be 6th working day before the 22nd. In that case we can set our deadline for 7th working day before 22nd, however if the deadline from the MR is earlier, then use the eraliest one.
-
Update the X.Y.
andX-Y-
to a specific release version -
Add the release label to the issue -
Add the %10.1 milestone to the issue
First working day after 7th - v10.1.0-rc.1 release
-
check if Pipeline for master
is passing:-
add all required fixes to make master
Pipeline passing
-
-
add v10.1.0-rc.1 CHANGELOG entries -
tag and push v10.1.0-rc.1 -
create and push 10-1-stable
branch -
checkout to master
, updateVERSION
file to10.1.0
and pushmaster
-
deploy v10.1.0-rc.1 (https://gitlab.com/gitlab-com/runbooks/blob/master/howto/update-gitlab-runner-on-managers.md)
New features window is closed - things not merged into master
up to
this day, will be released with next release.
7 working days before 22th (2017-10-12)
-
add entries to release blog post -
add release entry:
Add description to the
SECONDARY FEATURES
list using following template:- name: GitLab Runner 10.1 available_in: [ce, ees, eep] documentation_link: 'https://docs.gitlab.com/runner' documentation_text: "Read through the documentation on GitLab Runner" description: | We're also releasing GitLab Runner 10.1 today! GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab. ##### Most interesting changes: * __Title__ ([merge request](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/__ID__)) List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v10.1.0/CHANGELOG.md).
-
At 20th - next RC release
At this day we should release an RC version, if there was no RC recently - especially if the only RC version was the RC1 released near 7th day of month.
-
check if Pipeline for 10-1-stable
is passing:-
add all required fixes to make 10-1-stable
Pipeline passing
-
-
add v10.1.0-rc.Z CHANGELOG entries -
tag v10.1.0-rc.Z -
deploy v10.1.0-rc.Z (https://gitlab.com/gitlab-com/runbooks/blob/master/howto/update-gitlab-runner-on-managers.md)
At 22th - the release day
-
Before 12:00 UTC -
add last entries to changelog -
merge all RC.x CHANGELOG entries into release entry -
tag stable version
-
-
Before 15:00 UTC -
deploy stable version to all production Runners
-
RC release template
There should be at least one RC version between RC.1 and stable release. If there are any important changes merged into stable branch (like bug/security fixes) the RC should be prepared and deployed as soon as possible. For a less important changes (documentation, simple fixes of typos etc.) the RC can wait a little.
When deciding to release a new RC version, please update the checklist using the following template:
## At _day here_ - **v10.1.0-rc.Z** release
- [ ] check if Pipeline for `10-1-stable` is passing: [![pipeline status](https://gitlab.com/gitlab-org/gitlab-runner/badges/10-1-stable/pipeline.svg)](https://gitlab.com/gitlab-org/gitlab-runner/commits/10-1-stable)
- [ ] add all required fixes to make `10-1-stable` Pipeline passing
- [ ] add **v10.1.0-rc.Z** CHANGELOG entries
- [ ] tag **v10.1.0-rc.Z**
- [ ] deploy **v10.1.0-rc.Z** (https://gitlab.com/gitlab-com/runbooks/blob/master/howto/update-gitlab-runner-on-managers.md)