Merge pull request #1135 from mrapp-ke/workflow-update-github-actions

Workflow for updating Github Actions

.changelog-bugfix.md

@@ -4,3 +4,4 @@
 - 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.
 - Outdated GitHub Actions can now be printed via the build target `check_github_actions`. Alternatively, the build target `update_github_actions` may be used to update them automatically.
+- Continuous Integration is now used to automatically update outdated GitHub Actions on a regular schedule.

.github/workflows/update_github_actions.yml

@@ -0,0 +1,62 @@
+---
+name: Update GitHub Actions
+on:
+  pull_request:
+    types:
+      - opened
+      - reopened
+      - synchronize
+    paths:
+      - .github/workflows/test_changelog.yml
+      - build
+      - build.bat
+      - build_system/main.py
+      - build_system/core/**
+      - build_system/util/**
+      - build_system/targets/paths.py
+      - build_system/targets/dependencies/*
+      - build_system/targets/dependencies/github/*
+  schedule:
+    - cron: 0 3 * * 0
+  workflow_dispatch:
+jobs:
+  update_github_actions:
+    name: Update GitHub Actions
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          ref: bugfix
+      - name: Setup Python
+        uses: actions/setup-python@v5
+        with:
+          python-version-file: .version-python
+      - name: Setup git
+        uses: fregante/setup-git-user@v2
+      - 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: Update GitHub Actions
+        run: |
+          GITHUB_TOKEN=${{ steps.app-token.outputs.token }} ./build update_github_actions
+          git add .github/workflows/*.y*ml
+      - name: Submit pull request
+        id: pull-request
+        uses: peter-evans/create-pull-request@v7
+        with:
+          token: ${{ steps.app-token.outputs.token }}
+          commit-message: Update GitHub Actions.
+          branch: update-github-actions
+          title: Update GitHub Actions
+          labels: bot
+          assignees: mrapp-ke
+          body: Update the versions of outdated GitHub Actions.
+      - name: Enable auto-merge
+        if: ${{ steps.pull-request.outputs.pull-request-operation == 'created' }}
+        env:
+          GH_TOKEN: ${{ steps.app-token.outputs.token }}
+        run: gh pr merge --merge --auto "${{ steps.pull-request.outputs.pull-request-number }}"

CHANGELOG.md

@@ -92,7 +92,7 @@ This release comes with several API changes. For an updated overview of the avai
 - Development versions of wheel packages are now regularly built via Continuous Integration, uploaded as artifacts, and published on [Test-PyPI](https://test.pypi.org/).
 - Continuous integration is now used to maintain separate branches for major, feature, and bugfix releases and keep them up-to-date.
 - The runtime of Continuous Integration jobs has been optimized by running individual steps only if necessary, caching files across subsequent runs, and making use of parallelization.
-- When tests are run via Continuous Integration, a summary of the test results is now added to merge requests and GitHub workflows.
+- When tests are run via Continuous Integration, a summary of the test results is now added to pull requests and GitHub workflows.
 - Markdown files are now used for writing the documentation.
 - A consistent style is now enforced for Markdown files by applying the tool `mdformat` via Continuous Integration.
 - C++ 17 or newer is now required for compiling the project.

doc/developer_guide/continuous_integration.md

@@ -14,6 +14,8 @@ The workflow definitions of individual CI jobs can be found in YAML files locate
 
 ## Quality Control
 
+The following CI jobs are run automatically for all pull requests to ensure that their changes do not introduce any regressions. If one or more jobs fail, the respective pull request cannot be merged.
+
 - `test_build.yml` builds the project for each of the supported target platforms, i.e., Linux, Windows, and macOS (see {ref}`compilation`). In the Linux environment, this job does also execute all available unit and integration tests (see {ref}`testing`). It is run for pull requests whenever relevant parts of the project's source code have been modified.
 - `test_changelog.yml` ensures that all changelog files in the project adhere to the structure that is necessary to be processed automatically when publishing a new release. This job is run for pull requests if they modify one of the changelog files.
 - `test_doc.yml` generates the latest documentation (see {ref}`documentation`) whenever relevant parts of the source code are affected by a pull request.
@@ -24,6 +26,8 @@ The workflow definitions of individual CI jobs can be found in YAML files locate
 
 ## Automated Releases
 
+The release process described {ref}`here <release-process>` is fully automated via the CI jobs listed below. They are responsible for merging changes, which have been added to the code base via pull requests, to the correct release branches, updating the version numbers of these branches, and triggering releases.
+
 - `merge_feature.yml` and `merge_bugfix.yml` are used to merge changes that have been pushed to the feature or bugfix branch into downstream branches via pull requests (see {ref}`downstream-merges`).
 - `merge_release.yml` is used to merge all changes included in a new release published on [GitHub](https://github.com/mrapp-ke/MLRL-Boomer/releases) into upstream branches and update the version numbers of these branches (see {ref}`upstream-merges`).
 - `release.yml` defines a job for releasing a new version of the software developed by this project (see {ref}`triggering-releases`). 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.
@@ -32,5 +36,13 @@ The workflow definitions of individual CI jobs can be found in YAML files locate
 
 ## Publishing Packages
 
+The following CI jobs are used for building our software for different target platforms and architectures and publishing the resulting packages.
+
 - `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.
+
+## Maintenance
+
+The CI jobs listed below are run periodically to perform different maintenance tasks, such as the automatic update of dependencies.
+
+- `update_github_actions.yml` checks for outdated GitHub Actions used in workflow definition files. In cases where any updates are necessary, a pull request with the respective changes is opened. If the pull request passes all {ref}`necessary checks <ci-testing>`, it is merged automatically. Otherwise, manual intervention is needed.