This page discusses serveral Github actions which are used in multiple repositories for specific tasks. This page does not discuss the CI pipelines of individual repositories that take care of testing and linting checks.

By default, Github actions use the GITHUB_TOKEN which has reduced permissions. For many purposes, using a self-created token is required. For this reason the "openslides-automation" app exists. You can create a token for the app with the following step:

name: Generate access token
uses: tibdex/github-app-token@v2
id: generate-token
with:
    app_id: ${{ secrets.AUTOMATION_APP_ID }}
    private_key: ${{ secrets.AUTOMATION_APP_PRIVATE_KEY }}

The necessary secrets are set up in the OpenSlides organization and usable in all OS4-related repositories. The output of this step contains the requested token and can be accessed via ${{ steps.generate-token.outputs.token }}.

The file project-automation.yml is a so-called Reusable workflow. It is used to move issues and pull requests inside the project board. It is called by the following actions:

• project-issue-opened.yml/project-pull-reuqest-opened.yml: Automatically adds new issues/PRs to the project and moves them to the "Backlog" column
  • The workflow for issues does not exist in the main repository to not automatically add all community issues to the project board.
• project-issue-closed.yml/project-pull-request-closed.yml: Moves an issue/PR to the "Done" column when it is closed
• project-pull-request-review-requested.yml: Moves a PR to the "Review requested" column when a review is requested

Github automatically closes issues which were linked via keyword or sidebar to a pull request as soon as it is merged. Unfortunately, this only works on the repo's default branch. This means that issues for e.g. feature or staging branches need to be closed manually, which is often forgotten. The action close-issues.yml fixes this by automatically closing issues which were linked to PRs which were merged into other feature or staging branches. It does so by issuing a GraphQL request via another action to find all linked issues for a PR and then closing them via the Github CLI.

The action staging-to-main.yml is currently disabled as it stems from a previous concept of using staging branches. It is planned to update the action to make cherry-picking commits for staging branches easier. It should automate the following procedure:

• Trigger: A PR with the staging label gets merged into main
• Find the most current staging branch
• Cherry-pick the commit which was just merged into main on top of the staging branch
  • If conflicts occur, abort and write a comment in the closed PR
• Push the result to a dedicated branch for this commit and open a pull request to merge this commit into the staging branch

The file commands.yml contains the command \updatemeta. The use case is the following:

• You create a PR in a service repo which contains a new meta repository commit, for which you also create a PR in the meta repo
• The service repo's main branch gets updated with another meta repo commit, which leads to merge conflict in the submodule

This stems from the fact that git can only deal with the most simple merge conflicts when submodules are involved. But the strategy to fix this is simple:

• fetch the newest changes from main
• merge main into your branch, resulting in the merge conflict for the meta repo
• go into the meta repo and checkout the branch containing the changes for this feature
• fetch the newest changes from the meta repo's main
• merge main into your meta repo branch (should work without conflicts almost all the time as the meta repo does not get changed a lot)
• commit and push the merge to your branch
• go back up into the service repo, commit the merge and push

This is automatable via the Github CLI, which can automatically set up a local branch to track a pull request. This is what the aforementioned action does.

Unfortunately, this does not work if any of the merge commits contains changes to any workflows, probably because of a bug in the Github permission management. See https://github.com/orgs/community/discussions/112438#discussioncomment-8785041 for the relevant discussion. For commits where no workflows are touched, the command should work as intended.

The file create-prs-for-updates.yml in the meta repository automatically creates pull requests in the AU, backend, client and search service for each new commit in the meat repository's main branch. It does so by executing the workflow create-pr.yml via a matrix strategy to reduce code duplication. This workflow takes the following inputs:

• repository: The repository to create the PR in.
• commit: The commit to which the submodule should be updated.
• assignee: Who should be assigned in the service repository.
• setup-action: If given, it is interpreted as a workflow name (which must exist in the meta repo) which is executed before pushing the changes in the service repo. It is currently used in the AU to run go generate .../. before pushing the changes so that all model updates are automatically applied to the code.