Merge bugfix into feature branch

.changelog-bugfix.md

@@ -1,3 +1,4 @@
 # Quality-of-Life Improvements
 
+- Releases are now automated via continuous integration, including the update of the project's changelog.
 - The presentation of algorithmic parameters in the documentation has been improved.

.github/workflows/release.yml

@@ -0,0 +1,23 @@
+---
+name: Trigger release
+on: workflow_dispatch
+jobs:
+  update_changelog:
+    name: Update changelog
+    uses: ./.github/workflows/template_update_changelog.yml
+    with:
+      release_branch: ${{ github.ref_name }}
+    secrets:
+      token_app_id: ${{ secrets.TOKEN_APP_ID }}
+      token_app_secret: ${{ secrets.TOKEN_APP_SECRET }}
+  release:
+    needs: update_changelog
+    name: Publish release on GitHub
+    uses: ./.github/workflows/template_release.yml
+    with:
+      release_branch: ${{ github.ref_name }}
+      release_version: ${{ needs.update_changelog.outputs.release_version }}
+      changelog: ${{ needs.update_changelog.outputs.latest_changelog }}
+    secrets:
+      token_app_id: ${{ secrets.TOKEN_APP_ID }}
+      token_app_secret: ${{ secrets.TOKEN_APP_SECRET }}

.github/workflows/template_release.yml

@@ -0,0 +1,39 @@
+---
+name: Publish release on GitHub
+on:
+  workflow_call:
+    inputs:
+      release_branch:
+        required: true
+        type: string
+      release_version:
+        required: true
+        type: string
+      changelog:
+        required: true
+        type: string
+    secrets:
+      token_app_id:
+        required: true
+      token_app_secret:
+        required: true
+jobs:
+  release:
+    name: Publish release on GitHub
+    runs-on: ubuntu-latest
+    steps:
+      - name: Generate token
+        uses: actions/create-github-app-token@v1
+        id: app-token
+        with:
+          app-id: ${{ secrets.token_app_id }}
+          private-key: ${{ secrets.token_app_secret }}
+      - name: Publish release on GitHub
+        uses: softprops/action-gh-release@v2
+        with:
+          target_commitish: ${{ inputs.release_branch }}
+          name: Version ${{ inputs.release_version }}
+          tag_name: ${{ inputs.release_version }}
+          body: ${{ inputs.changelog }}
+          make_latest: true
+          token: ${{ steps.app-token.outputs.token }}

.github/workflows/template_update_changelog.yml

@@ -0,0 +1,63 @@
+---
+name: Update changelog
+on:
+  workflow_call:
+    inputs:
+      release_branch:
+        required: true
+        type: string
+    secrets:
+      token_app_id:
+        required: true
+      token_app_secret:
+        required: true
+    outputs:
+      release_version:
+        value: ${{ jobs.update_changelog.outputs.release_version }}
+      latest_changelog:
+        value: ${{ jobs.update_changelog.outputs.latest_changelog }}
+jobs:
+  update_changelog:
+    name: Update changelog
+    runs-on: ubuntu-latest
+    outputs:
+      release_version: ${{ steps.print-version.outputs.version }}
+      latest_changelog: ${{ steps.print-latest-changelog.outputs.changelog }}
+    steps:
+      - name: Generate token
+        uses: actions/create-github-app-token@v1
+        id: app-token
+        with:
+          app-id: ${{ secrets.token_app_id }}
+          private-key: ${{ secrets.token_app_secret }}
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+          token: ${{ steps.app-token.outputs.token }}
+          ref: ${{ inputs.release_branch }}
+      - name: Setup git
+        uses: fregante/setup-git-user@v2
+      - name: Update changelog
+        run: |
+          ./build update_changelog_${{ inputs.release_branch }}
+          git add .changelog-*.md
+          git add CHANGELOG.md
+          git commit -m "[Bot] Update changelog."
+          git push
+      - name: Save release version to output
+        id: print-version
+        run: |
+          VERSION=$(./build print_version)
+          EOF=$(dd if=/dev/urandom bs=15 count=1 status=none | base64)
+          echo "version<<$EOF" >> $GITHUB_OUTPUT
+          echo "$VERSION" >> $GITHUB_OUTPUT
+          echo "$EOF" >> $GITHUB_OUTPUT
+      - name: Save changelog to output
+        id: print-latest-changelog
+        run: |-
+          CHANGELOG=$(./build print_latest_changelog)
+          EOF=$(dd if=/dev/urandom bs=15 count=1 status=none | base64)
+          echo "changelog<<$EOF" >> $GITHUB_OUTPUT
+          echo "$CHANGELOG" >> $GITHUB_OUTPUT
+          echo "$EOF" >> $GITHUB_OUTPUT

.version

@@ -1 +1 @@
-0.11.2
+0.12.0

doc/developer_guide/coding_standards.md

@@ -16,6 +16,7 @@ A track record of past runs can be found on GitHub in the [Actions](https://gith
 
 The workflow definitions of individual CI jobs can be found in the directory [.github/workflows/](https://github.com/mrapp-ke/MLRL-Boomer/tree/8ed4f36af5e449c5960a4676bc0a6a22de195979/.github/workflows). Currently, the following jobs are used in the project:
 
+- `release.yml` defines a job for releasing a new version of the software developed by this project. The job can be triggered manually for one of the branches mentioned in the section {ref}`release-process`. It automatically updates the project's changelog and publishes a new release on GitHub.
 - `publish.yml` is used for publishing pre-built packages on [PyPI](https://pypi.org/) (see {ref}`installation`). For this purpose, the project is built from source for each of the target platforms and architectures, using virtualization in some cases. The job is run automatically when a new release was published on [GitHub](https://github.com/mrapp-ke/MLRL-Boomer/releases). It does also increment the project's major version number and merge the release branch into its upstream branches (see {ref}`release-process`).
 - `publish_development.yml` publishes development versions of packages on [Test-PyPI](https://test.pypi.org/) whenever changes to the project's source code have been pushed to the main branch. The packages built by each of these runs are also saved as [artifacts](https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts) and can be downloaded as zip archives.
 - `test_publish.yml` ensures that the packages to be released for different architectures and Python versions can be built. The job is run for pull requests that modify relevant parts of the source code.
@@ -180,7 +181,9 @@ We do not allow directly pushing to the above branches. Instead, all changes mus
 
 Once modifications to one of the branches have been merged, {ref}`Continuous Integration <ci>` jobs are used to automatically update downstream branches via pull requests. If all checks for such pull requests are successful, they are merged automatically. If there are any merge conflicts, they must be resolved manually. Following this procedure, changes to the feature branch are merged into the main branch (see `merge_feature.yml`), whereas changes to the bugfix branch are first merged into the feature branch and then into the main branch (see `merge_bugfix.yml`).
 
-Whenever a new release has been published, the release branch is merged into the upstream branches (see `merge_release.yml`), i.e., major releases result in the feature and bugfix branches being updated, whereas minor releases result in the bugfix branch being updated. The version of the release branch and the affected branches are updated accordingly. The version of a branch is specified in the file `.version` in the project's root directory. Similarly, the file `.version-dev` is used to keep track of the version number used for development releases (see `publish_development.yml`).
+We use a {ref}`Continuous Integration <ci>` job for triggering a new release, including the changes of one of the branches mentioned above (see `release.yml`). Depending on the release branch, the job automatically collects the corresponding changelog entries from the files `.changelog-main.md`, `.changelog-feature.md`, and `.changelog-bugfix.md` and updates the file `CHANGELOG.md` in the project's root directory accordingly. Afterward, it will publish the new release on GitHub, which will in turn trigger the publishing of pre-built packages (see `publish.yml`).
+
+Whenever a new release has been published, the release branch is merged into the upstream branches (see `merge_release.yml`), i.e., major releases result in the feature and bugfix branches being updated, whereas minor releases result in the bugfix branch being updated. The version of the release branch and the affected branches are updated accordingly. The file `.version` in the project's root directory specifies the version of each of these branches. Similarly, the file `.version-dev` keeps track of the version number used for development releases (see `publish_development.yml`).
 
 (dependencies)=