Skip to content

Updater and danger - convert to actions #113

@vaind

Description

@vaind

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"

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions