Automatically create release tags via GitHub actions

Release tags are now created automatically when including an indicator
(see updated documentation) in the commit message.

Author: tautschnig

.github/workflows/create-release-tag.yaml

@@ -0,0 +1,34 @@
+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 }}
+        DEFAULT_BUMP: none
+        RELEASE_BRANCHES: develop
+        VERBOSE: false

doc/ADR/release_process.md

@@ -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