|
|
|
|
|
1. For security sensitive releases:
|
|
|
|
|
|
* Make sure all customers and Turris team are ready for public disclosure.
|
|
|
* Coordinate unembargo date with [OSS distros mailing list](http://oss-security.openwall.org/wiki/mailing-lists/distros) and obtain CVE # from the list.
|
|
|
|
|
|
1. Create a branch name starting with `release`
|
|
|
|
|
|
- Reason: There are special release-only CI checks that are executed for branch names starting with [`release`](https://gitlab.nic.cz/knot/knot-resolver/-/blob/57fd2fd453850e9c774023b22335378953af9edf/.gitlab-ci.yml#L183)
|
|
|
|
|
|
1. Prepare a release commit
|
|
|
- Bump the version number in [`meson.build`](https://gitlab.nic.cz/knot/knot-resolver/-/blob/57fd2fd453850e9c774023b22335378953af9edf/meson.build#L7)
|
|
|
- Update version and date in [`NEWS`](https://gitlab.nic.cz/knot/knot-resolver/-/blob/57fd2fd453850e9c774023b22335378953af9edf/NEWS)
|
|
|
- Mention all changes relevant to users in `NEWS` (hint: `git log --first-parent v5.4.4..`)
|
|
|
- Update the upgrading guide if needed [`doc/upgrading.rst`](https://gitlab.nic.cz/knot/knot-resolver/-/blob/57fd2fd453850e9c774023b22335378953af9edf/doc/upgrading.rst#L31)
|
|
|
|
|
|
1. Commit and push the changes to trigger CI and make sure it is passing
|
|
|
- Some tests may be unstable (deckard/pytests...), try re-running
|
|
|
- Some test failures may be safe to ignore (respdiff) - ask @vcunat
|
|
|
|
|
|
1. Run package builds and tests in `knot-resolver-testing` via [CI/CD->Schedules](https://gitlab.labs.nic.cz/knot/knot-resolver/pipeline_schedules)
|
|
|
- Edit the `[OBS/knot-resolver-testing] 🐜distrotests` job and select the release branch.
|
|
|
- Run the schedule.
|
|
|
- This may take a long time due to OBS (up to a few hours)
|
|
|
- Ideally, you can prepare the commit a day in advance and run this overnight
|
|
|
- Not recommended: Alternately, you can check the packaging results from master the night before _if there have been no changes that could affect packaging_.
|
|
|
|
|
|
1. Merge `release*` branch.
|
|
|
|
|
|
1. Create a tag a PGP signed tag.
|
|
|
- `git tag -as vX.Y.Z`
|
|
|
- content `Knot Resolver X.Y.Z`
|
|
|
|
|
|
1. Push the tag `git push origin vX.Y.Z`.
|
|
|
- This creates a tag pipeline (find it in [CI/CD->Pipelines](https://gitlab.nic.cz/knot/knot-resolver/-/pipelines))
|
|
|
|
|
|
1. Add release notes to the GitLab tag.
|
|
|
- Find the newly created tag in [Repository->Tags](https://gitlab.labs.nic.cz/knot/knot-resolver/tags)
|
|
|
- Copy the content of `NEWS` into the description.
|
|
|
|
|
|
1. Archive and download the release tarball.
|
|
|
- Find the `archive` job in the tag pipeline and mark the artifacts to `Keep` - This prevents the artifacts from being automatically deleted.
|
|
|
- Download the release tarball `knot-resolver-x.y.z.tar.xz` generated by the `archive` job
|
|
|
|
|
|
1. Create tarball signature and checksum.
|
|
|
- Generate signature using your PGP signing key: `gpg --detach-sign --armor --digest-algo SHA512 knot-resolver-x.y.z.tar.xz`
|
|
|
- Generate checksum file: `sha256sum knot-resolver-x.y.z.tar.xz > knot-resolver-x.y.z.tar.xz.sha256`
|
|
|
|
|
|
1. Upload the tarball, signature and checksum to [secure.nic.cz](https://secure.nic.cz/files/knot-resolver/)
|
|
|
- Option A: Add a davfs entry to `/etc/fstab` and use the `mount` command to mount the file system. `https://public.nic.cz/files /mnt/secure davfs uid=tkrizek,rw,noauto,user 0 0`
|
|
|
- Option B: (May not work any more) `curl -u name.surname -n --basic -T {,https://public.nic.cz/files/knot-resolver/}knot-resolver-x.y.z.tar.xz`
|
|
|
- `mount /mnt/secure`
|
|
|
- `cp knot-resolver-X.Y.Z.tar.xz* /mnt/secure/knot-resolver`
|
|
|
|
|
|
1. ReadTheDocs documentation should regenerate automatically: check http://readthedocs.org/projects/knot-resolver/builds/
|
|
|
- If the tag isn't there, trigger the [webhook](https://gitlab.nic.cz/knot/knot-resolver/-/hooks) manually - Select `Test -> Tag push events` on the readthedocs hook
|
|
|
- *TODO: This mechanism may be superseded by the next step with GitLab CI*
|
|
|
|
|
|
1. Documentation should generate automatically as a CI job
|
|
|
- To put it on the main <https://knot.pages.nic.cz/knot-resolver> page, run the manual `docs:public` job.
|
|
|
|
|
|
1. Build docker image and push it to docker hub.
|
|
|
- In the git dir, make sure you have a clean repo and the proper tag checked out:
|
|
|
- **WARNING** The following two commands delete any uncommited or untracked files!
|
|
|
- `git reset --hard vX.Y.Z`
|
|
|
- `git clean -dfx`
|
|
|
- `git status` should be clean
|
|
|
- `git submodule update --init --recursive`
|
|
|
- run docker daemon if not running, `systemctl start docker`
|
|
|
- `docker build --pull --no-cache -t cznic/knot-resolver:vX.Y.Z .`
|
|
|
- `docker tag cznic/knot-resolver:vX.Y.Z cznic/knot-resolver:latest`
|
|
|
- `docker login`
|
|
|
- `docker push cznic/knot-resolver:vX.Y.Z`
|
|
|
- `docker push cznic/knot-resolver:latest`
|
|
|
|
|
|
1. Trigger package build in OBS: Press the release button for `obs:release` manual job in the tag pipeline. It should succeed, and also run packaging tests on the released package. If the release fails and you need to manually submit the package to OBS:
|
|
|
|
|
|
- **LEGACY INSTRUCTIONS (no longer needed, except unexpected emergencies)**
|
|
|
- Set up the [`osc`](https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.osc.html) OBS CLI tool
|
|
|
- Make sure you've checked out the released version: `git checkout vx.y.z`
|
|
|
- Make sure the release tarball `knot-resolver-x.y.z.tar.xz` is in `build_dist/meson-dist/`
|
|
|
- Prepare distro files (with symbols): `./scripts/make-distrofiles.sh`
|
|
|
- Upload new files to [knot-resolver-latest](https://build.opensuse.org/project/show/home:CZ-NIC:knot-resolver-latest): `./scripts/build-in-obs.sh knot-resolver-latest`
|
|
|
- Check the builds have completed successfully (builds should be done in ~10mins and published within ~2 hours).
|
|
|
- In case of issues, use the #packaging or #opensuse-buildservice internal slack channels for help (or contact @jruzicka directly).
|
|
|
|
|
|
1. Trigger the `obs:odvr` job as well to deploy the version to the [knot-resolver-odvr](https://build.opensuse.org/project/show/home:CZ-NIC:knot-resolver-odvr) repository used by [ODVR](https://www.nic.cz/odvr/).
|
|
|
|
|
|
1. Update the [Knot Resolver website](https://gitlab.labs.nic.cz/websites/knot-resolver.cz):
|
|
|
- Update the `content/pages/en/download.rst` page with links to newest tarball, signature and checksum
|
|
|
- Create a news entry in `content/news/en/` and place the NEWS content there along with simple metadata header.
|
|
|
- See https://gitlab.nic.cz/websites/knot-resolver.cz/-/merge_requests/104 for example
|
|
|
- Preview the web locally (see instructions in [README](https://gitlab.nic.cz/websites/knot-resolver.cz/-/blob/master/README.md), beware that the website might not be compatible with Python 3?)
|
|
|
- Verify all links point to the latest released version and news has been updated on the home page and its content is ok.
|
|
|
- Merge the MR which will run a CI job on the master branch leading to automatic deployment into production web - https://knot-resolver.cz .
|
|
|
|
|
|
1. Send a release announcement e-mail.
|
|
|
- You may use an [existing template](https://lists.nic.cz/hyperkitty/list/knot-resolver-announce@lists.nic.cz/thread/AKLOFJNOPQYJWRJW5AVCLH7HJ6ROVB2V/) or choose your own format.
|
|
|
- Double-check you've updated all the links with the latest release.
|
|
|
- Send the release email with subject `Knot Resolver vX.Y.Z` to both `knot-resolver-announce@lists.nic.cz` and `knot-resolver-users@lists.nic.cz`. Ideally, sign the e-mail with PGP.
|
|
|
- For PR-interesting releases (typically minor releases, but not patch releases), contact [Vilém](mailto:vilem.sladek@nic.cz) and [Bára](mailto:barbora.hlubkova@nic.cz) and provide them a couple of paragraphs with the summary of interesting changes suitable for PR (like root.cz).
|
|
|
|
|
|
1. Announce the release on [Twitter](https://twitter.com/KnotDNS).
|
|
|
- Include a link to the release announcement e-mail in public archive.
|
|
|
- Example message: https://twitter.com/KnotDNS/status/1478730949248618502
|
|
|
|
|
|
1. Notify the packager (@jruzicka) to prepare releases.
|
|
|
- Especially Fedora and EPEL packages should be provided in a timely manner, since these are our official release channels.
|
|
|
- Debian and Ubuntu official release channels are OBS, so downstream updates can be slower.
|
|
|
|
|
|
1. Wait until the builds in [knot-resolver-odvr](https://build.opensuse.org/project/show/home:CZ-NIC:knot-resolver-odvr) are marked as `succeeded` (in green, with a green truck icon).
|
|
|
|
|
|
1. If there are any updates relevant to ODVR configuration file, add them in [kresd.conf.j2](https://gitlab.nic.cz/knot/knot-resolver-odvr/-/blob/master/roles/knot-resolver/templates/kresd.conf.j2).
|
|
|
- Make a commit, and create a MR for the change.
|
|
|
|
|
|
1. Test the new version (and config file, if applicable) by running the [deploy.yaml](https://gitlab.nic.cz/knot/knot-resolver-odvr/-/blob/master/deploy.yaml) ansible playbook.
|
|
|
- This deploys the version from ODVR repository to the test runners that are very similar to the production environment.
|
|
|
- If the playbook finishes successfully, it is safe to notify admins to deploy the new version.
|
|
|
|
|
|
1. Merge any changes and notify [Kryštof](<mailto:krystof.sadek@nic.cz>) about the new version. Include link to a MR if there have been any changes. |
|
|
Moved into internal docs |