-
-
Notifications
You must be signed in to change notification settings - Fork 8
Description
Historically, Updater and Danger workflows were reusable github workflows.
This, however, poses a problem with the part that the workflows need to fetch scripts they need to run (dangerfile.js or powershell scripts in case of Updater). How this was done was a wget/invoke-webrequest that just download the script:
| wget https://raw.githubusercontent.com/getsentry/github-workflows/${{ inputs._workflow_version }}/danger/dangerfile.js -P ${{ runner.temp }} |
The problem is that the reusable workflow, when called from the consuming repository, doesn't get any information about the version the caller triggered it with, e.g. 2.14.0. I've tried getting around this by specifying the version in the workflow itself but then it fails when using craft to release due to the lack of permissions of the release action to update workflow files: refusing to allow a GitHub App to create or update workflow .github/workflows/danger.ymlwithoutworkflows permission
Previously, we've just had "v2" specified in the workflow and relied on the file pulling the latest version at all times. This poses a problem if you want to just test out a release in a separate repository, before marking it stable and potentially break all the repos consuming v2.
Proposed solution
Changing the workflows to a composite action should work, because we'd get the ${{ github.action_path } context, like we already use in https://github.com/getsentry/github-workflows/blob/main/sentry-cli/integration-test/action.yml#L20
Potential Issues
- Runner flexibility lost: updater can't specify runs-on
If we do this, we'll need to make a major release to avoid breaking anyone using "v2"