From 1ee11f7c9e72719f62981167a24fe7239774fa69 Mon Sep 17 00:00:00 2001 From: Patrick Ziegler Date: Mon, 9 May 2022 17:00:14 +0200 Subject: [PATCH] Adapt release workflow to produce signed releases (#2720) --- README.md | 7 ++++++ doc/dev/release-workflow.rst | 41 +++++++++++++++++++++++++++--------- 2 files changed, 38 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 60de502a..376b133e 100644 --- a/README.md +++ b/README.md @@ -41,6 +41,7 @@ for their desktop environment, without the need of having a black belt in shell * [Sponsors](#sponsors) * [Backers](#backers) * [License](#license) +* [Signatures](#signatures) ## Introduction @@ -236,3 +237,9 @@ Polybar accepts donations through [open collective](https://opencollective.com/p ## License Polybar is licensed under the MIT license. [See LICENSE for more information](https://github.com/polybar/polybar/blob/master/LICENSE). + +## Signatures + +Release archives and tags are signed by a maintainer using GPG. Currently +everything is signed by [Patrick Ziegler](https://www.patrickziegler.ch/gpg) +with fingerprint `1D5791352D51A228D4DDDBA4521E5E03AEBCA1A7` diff --git a/doc/dev/release-workflow.rst b/doc/dev/release-workflow.rst index b051c262..f6ba8d52 100644 --- a/doc/dev/release-workflow.rst +++ b/doc/dev/release-workflow.rst @@ -114,9 +114,16 @@ as follows: * A draft PR is opened for the release branch. This PR MUST NOT be merged in GitHub's interface, it is only here for review, merging happens at the commandline. -* A `draft release`_ is created in GitHub's release publishing tools -* After approval, the GitHub release publishing tool is used to publish the - release and tag the tip of the release branch (the release commit). +* After approval, a signed git tag is created locally at the tip of the release + branch and pushed: + +.. code-block:: shell + + git tag -s X.Y.Z + git push --tags + +* A `draft release`_ targetting the new tag is created in GitHub's release + publishing tools and published. * After the tag is created, the release branch is manually merged into ``master``. Here it is vitally important that the history of the release branch does not @@ -193,8 +200,8 @@ Draft Release On `GitHub `_ a new release should be drafted. -The release targets the tip of the release branch (the release commit), the -name of the release and the tag is simply the release number. +The release targets the git tag that was just pushed, the name of the release +and the tag is simply the release number. The content of the release message should contain the changelog copied from ``CHANGELOG.md`` under the heading ``## Changelog``. @@ -205,6 +212,7 @@ The generated list of PRs can be removed. After-Release Checklist ~~~~~~~~~~~~~~~~~~~~~~~ +* Verify the release archive (see `Verify Release`_) * Make sure all the new functionality is documented on the wiki * Mark deprecated features appropriately (see `Deprecations`_) * Remove all unreleased notes from the wiki (not for patch releases) @@ -212,11 +220,6 @@ After-Release Checklist `_. Mention any dependency changes and any changes to the build workflow. Also mention any new files are created by the installation. -* Confirm that the release archive was added to the release. - We have a GitHub action workflow called 'Release Workflow' that on every - release automatically creates a release archive, uploads it to the release, - and adds a 'Download' section to the release body. - If this fails for some reason, it should be triggered manually. * Create a PR that updates the AUR ``PKGBUILD`` file for the ``polybar-git`` package (push after the release archive is uploaded). * Close the `GitHub Milestone `_ @@ -226,6 +229,24 @@ After-Release Checklist previous versions for the same minor release (e.g. for 3.5.4, deactivate all other 3.5.X versions). +Verify Release +~~~~~~~~~~~~~~ + +Confirm that the release archive was added to the release. +We have a GitHub action workflow called 'Release Workflow' that on every +release automatically creates a release archive, uploads it to the release, +and adds a 'Download' section to the release body. +If this fails for some reason, it should be triggered manually. + +Afterwards, download the archive, verify its hash, and sign it: + +.. code-block:: shell + + gpg --armor --detach-sign polybar-X.Y.Z.tar.gz + +Finally, upload the generated ``polybar-X.Y.Z.tar.gz.asc`` to the GitHub +release. + Deprecations ~~~~~~~~~~~~