Add CI to help automate releases (#115)

Adds a CI automation to auto-bump releases based on a github workflow

Running the workflow is manual, but this removes the manual step of
checking out and creating the "bump version" PR.

I modeled the github action on the chapel-vscode one, so it should be
correct:
https://github.com/chapel-lang/chapel-vscode/blob/main/.github/workflows/bump-version.yml

Author: jabraham17

.github/workflows/bump-version.yml

@@ -0,0 +1,41 @@
+name: Bump version
+
+on:
+  workflow_dispatch:
+
+jobs:
+  bump-patch:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v4
+    - name: Install Node.js
+      uses: actions/setup-node@v4
+      with:
+        node-version: 20
+    - name: Exit if branch exists
+      run: |
+        BRANCH_NAME="update-version"
+        if git ls-remote --heads origin $BRANCH_NAME | grep -q $BRANCH_NAME; then
+          echo "Branch $BRANCH_NAME already exists."
+          exit 1
+        fi
+    - name: Create a new branch
+      run: |
+        git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com"
+        git config --global user.name "github-actions[bot]"
+        git checkout -b update-version
+        git push --set-upstream origin update-version
+    - name: Bump Version
+      run: |
+        ./util/bump-version.sh
+        git commit -am "Bump version for next release"
+        git push
+    - name: create pull request
+      run: >
+        gh pr create
+        -B main
+        -H update-version
+        --title 'Bump version for next release'
+        --body 'Bump the version in prep for next release'
+      env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

README.rst

@@ -46,16 +46,16 @@ Making a Release
 #. Click “Draft a new release” button on top of screen
 #. For the tag, make a new tag with the new version number
 #. You can generate the release notes via the “generate release notes” button,
-   comparing against the most recent release.  This will autofill in the details
+   comparing against the most recent release. This will autofill in the details
    for you
-#. Click “Publish release”
+#. Click "Publish release"
     - This will trigger the workflow to push a new release to PyPI, assuming no
       problems have snuck into our release procedure since the last time it was
       run
-#. Open a PR bumping the version to the next version number so that we’re ready
-   for the next change.  This should always be the first PR in a new release
-   (otherwise we’ll have build issues), so it should be straight-forward to
-   figure out how to do this
+#. Open a PR bumping the version to the next version number so that we're ready
+   for the next change. This should always be the first PR in a new release
+   (otherwise we'll have build issues). This can be done by running the
+   'bump-version' GitHub Action, which will create the PR for you.
 
 In case of issues, the release pushing job is in
 .github/workflows/python-publish.yml

util/bump-version.sh

@@ -0,0 +1,22 @@
+#!/usr/bin/env bash
+
+set -e
+
+SCRIPT_DIR=$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)
+
+version_file="$SCRIPT_DIR/../sphinxcontrib/chapeldomain/__init__.py"
+current_version=$(grep -E "VERSION\s*=\s*'[0-9.]+" "$version_file" | awk -F"=" '{print $2}' | tr -d ' ' | tr -d "'")
+echo "Current version: $current_version"
+major_version=$(echo "$current_version" | awk -F"." '{print $1}')
+minor_version=$(echo "$current_version" | awk -F"." '{print $2}')
+patch_version=$(echo "$current_version" | awk -F"." '{print $3}')
+
+
+new_patch_version=$((patch_version + 1))
+new_version="${major_version}.${minor_version}.${new_patch_version}"
+echo "New version: $new_version"
+
+# update the version file
+set -x
+sed -E "s|^(VERSION[[:space:]]*=[[:space:]]*)'[^']+'$|\1'${new_version}'|" "$version_file" > "${version_file}.tmp"
+mv "${version_file}.tmp" "$version_file"