This GitHub app allows you to centrally manage and run multiple GitHub Actions workflows across multiple repositories. Currently this is a limitation in GitHub Actions, as it only allows you to configure and manage Actions workflows on a repository level. This app helps you - for example - to centrally define central workflows for linting, compliance checks, and more.
You can install the app by clicking here. Make sure you install it on all repositories:
If you don't want to install it on all repositories, then make sure to at least include the
.github repository of your organization.
After you install the app, you can create a centrally managed workflow. There are a couple of things to keep in mind when you do this:
This app dispatches workflow runs with the
repository_dispatch event and the
org-workflow-bot type. Create a new workflow in the
.github/workflows directory of your organization's
.github repository with the yml definition below:
name: compliance-check on: repository_dispatch: types: [org-workflow-bot] # <-- requirement to trigger central workflows
To let this app keep track of Action runs and expose this information back to the original commit in the source repository it needs to register the workflow run. Like in the example below, start the workflow by registering the run. After this you can add your steps and jobs like you would in a typical Actions workflow.
name: compliance-check on: repository_dispatch: types: [org-workflow-bot] jobs: register-and-lint: runs-on: ubuntu-latest steps: - uses: SvanBoxel/organization-workflow@main with: id: $ callback_url: $ sha: $ run_id: $ name: $ # Default: name of workflow. This name is shown with the check, but can be changed. # ... the checks and jobs that need to happen in your workflow.
Make sure to not change the
name argument is shown next to the check on the original commit and can be changed. (default is the name of the workflow)
(☝ source repository)
You have the possibilty to show the user specific documentation or enforce specific checks, see Action inputs for more information about this.
👀 Optional: If you don't register the run, the workflow is triggered without providing information to the user that pushed the commit like in the image above. You can still manually provide this information using one of the Check Actions that is available in the GitHub Marketplace.
Because the GITHUB_SECRET is scoped to the repository it is running in, you need to leverage the GitHub App to get access to the repository that triggered the workflow. You can use the repository, ref, and token that is supplied in the dispatch payload by the app for this:
- name: Checkout uses: email@example.com with: repository: $ ref: $ token: $ - name: Markdown Lint
❗ The token in the dispatch payload is redacted in the workflow logs and cannot be used by users that only have read access to the
.githubrepository. Any user who has push access to the main branch of the
.githubrepository can however use this token in a workflow and execute commands that are within the scope of this application. (See App permissions)
This app needs the following permissions:
When installed in an organization, the app's logic is triggered by any
push event. When this happens, the app collects all relevant information and dispatches this to the
.github repository of your organization. Here, all central workflow files configured with the
repository_dispatch event and
org-workflow-bot type are triggered.
To map commits, checks, and workflow run, and to make sure workflows can rerun without any problem, some data persistence is needed. Because of this you need to register the run at the start of a workflow. When the workflow finishes the app retrieves what source repository and commit triggered the central workflow, and exposes the workflow results back to the original commit. This data (source repository, check id, sha, and run id) is automatically removed after 90 days.
github.workflowto use the name of the workflow)
.github/workflows/compliance-info.md) Default: null
- uses: SvanBoxel/organization-workflow@main with: id: $ callback_url: $ sha: $ run_id: $ name: $ enforce: true enforce_admin: true documentation: "README.md"
A Codespaces environment is defined so you can get started right away. Open this repository in the codespace and run
npm run dev to start the app in development mode. It will prompt you to follow a couple of instruction to configure your GitHub app and set your .env values.
This codespaces comes and configured installed with:
This app depends on NodeJS to run the application and MongoDB for data persistence. Follow the following steps to run this app locally:
# Install dependencies npm install
.env and populate it with your MongoDB host and credentials and your proxy url. Make sure to run a tool like ngrok or localtunnel to expose your application to the internet. Smee.io is not supported, as it is a webhook proxy service and cannot forward Express endpoint calls
Now you can run the app with the following command:
npm run build:watch
This will prompt you to visit http://localhost:3000 and configure the app on the GitHub side. After you do this it will automatically populate the
PRIVATE_KEY field in the
npm run build npm test npm run start
You can find a Terraform definition in the
./infra directory for deployments to Azure.
If you have suggestions for how this GitHub app could be improved, or want to report a bug, open an issue! We'd love all and any contributions.
For more, check out the Contributing Guide.