Skip to content

Automatically create release tags via GitHub actions #5649

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

Automatically create release tags via GitHub actions #5649

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f87692e
Automatically create release tags via GitHub actions
tautschnig Dec 10, 2020
5ad6803
Keep automated release tagging in dry-run mode
tautschnig Dec 16, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 35 additions & 0 deletions .github/workflows/create-release-tag.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
name: Create release tag
on:
push:
branches: [ develop ]

jobs:
create-tag:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
fetch-depth: '0'
- name: Compute new tag
uses: anothrNick/[email protected]
id: dry_run
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
DEFAULT_BUMP: none
RELEASE_BRANCHES: develop
VERBOSE: false
DRY_RUN: true
- if: ${{ steps.dry_run.new_tag != "" }}
run: |
v=$(grep ^CBMC_VERSION src/config.inc | perl -p -e 's/^CBMC_VERSION\s*=\s*//')
echo "CBMC_VERSION: $v"
echo "New tag: ${{ steps.dry_run.new_tag }}"
test "cbmc-$v" == ${{ steps.dry_run.new_tag }}
- name: Bump version and push tag
uses: anothrNick/[email protected]
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you checked if the default GITHUB_TOKEN has the rights to create a tag? It not being allowed to do some things is something that has bitten me in the past, that's why I’m asking.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call out. I don't know whether this works, but also I'm not sure how to figure it out other than trying it out? (It seems safe to do so: in the worst case, it does not create a tag, and we'd have to go back to the previous, manual approach.)

DEFAULT_BUMP: none
RELEASE_BRANCHES: develop
VERBOSE: false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this read the latest version from the existing tags?
If not we may need INITIAL_VERSION too:

INITIAL_VERSION (optional) - Set initial version before bump. Default 0.0.0.

Probably something like: INITIAL_VERSION: 5.20.1?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Supposedly the bash script behind this GitHub action does check for existing tags. But it may be worth flipping DRY_RUN back on to make sure this does actually work as expected.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have now added a commit to keep in in DRY_RUN mode.

DRY_RUN: true
13 changes: 5 additions & 8 deletions doc/ADR/release_process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,25 +11,22 @@ The current process we follow through to make a new release is the following:
1. At the point in time we want to make the release, we make a change to
`src/config.inc`, and update the configuration variable `CBMC_VERSION`.
This is important as it informs the various tools of the current version
of CBMC.

(This needs to be pushed as a PR, and after it gets merged we move on to:)

2. Then we make a `git tag` out of that commit, and push it to github. The
tag needs to be of the form `cbmc-<version>` with version being a version
of CBMC. The commit message must then contain one of \#major, \#minor, or
\#patch to inform the GitHub action that automatically creates a release tag.
The tag is of the form `cbmc-<version>`, with `<version>` being a version
number of the form of `x.y.z`, with `x` denoting the major version, `y`
denoting the minor version, and `z` identifying the patch version (useful
for a hotfix or patch.)

At this point, the rest of the process is automated, so we don't need to do
anything more, but the process is described below for reference:

3. `.github/workflows/regular-release.yaml` gets triggered on the `push`
2. `.github/workflows/regular-release.yaml` gets triggered on the `push`
of the tag, and creates a Github release of the version that was
described in thetag pushed (so, tag `cbmc-5.15.20` is going to
create the release titled `cbmc-5.15.20` on the release page).

4. `.github/workflows/release-packages.yaml` gets triggered automatically
3. `.github/workflows/release-packages.yaml` gets triggered automatically
at the creation of the release, and its job is to build packages for
Windows, Ubuntu 18.04 and Ubuntu 20.04 (for now, we may support more
specific Ubuntu versions later) and attaches them (after it has finished
Expand Down