feat(actions): Make release workflow reusable for external repos#672
feat(actions): Make release workflow reusable for external repos#672
Conversation
Add workflow_call trigger to release.yml so external repositories can call it as a reusable workflow. This provides two options for adopting Craft: - Reusable workflow: Zero-config, batteries-included release flow - Composite action: Flexible, allows custom pre/post steps The workflow handles both Craft's own releases (dogfooding with local action) and external repos (using published getsentry/craft@v2 action). Documentation updated to present both options with comparison table.
Suggested Version Bump🟡 Minor (new features) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨Documentation 📚🤖 This preview updates automatically when you update the PR. |
|
| id: craft-local | ||
| uses: ./ | ||
| env: | ||
| GITHUB_TOKEN: ${{ steps.token.outputs.token }} |
There was a problem hiding this comment.
Bug: When workflow_dispatch is run on a fork, the token generation step is skipped, but the craft-local step still tries to use its output, resulting in an empty GITHUB_TOKEN.
Severity: HIGH | Confidence: High
🔍 Detailed Analysis
When the workflow is triggered via workflow_dispatch on a fork of the getsentry/craft repository, the token generation step is skipped. This is because its condition if: github.event_name == 'workflow_dispatch' && github.repository == 'getsentry/craft' evaluates to false on a fork. The subsequent craft-local step, however, is still executed and attempts to use the output from the skipped step via ${{ steps.token.outputs.token }}. In GitHub Actions, referencing an output from a skipped step results in an empty string. This causes the craft action to run with an empty GITHUB_TOKEN, leading to authentication failures and GitHub API errors. This bug prevents contributors from successfully testing the workflow on their forks.
💡 Suggested Fix
Add a condition to the craft-local step to ensure it only runs when the token generation step has also run. The condition should mirror the one on the token step: if: github.event_name == 'workflow_dispatch' && github.repository == 'getsentry/craft'.
🤖 Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: .github/workflows/release.yml#L121
Potential issue: When the workflow is triggered via `workflow_dispatch` on a fork of the
`getsentry/craft` repository, the token generation step is skipped. This is because its
condition `if: github.event_name == 'workflow_dispatch' && github.repository ==
'getsentry/craft'` evaluates to false on a fork. The subsequent `craft-local` step,
however, is still executed and attempts to use the output from the skipped step via `${{
steps.token.outputs.token }}`. In GitHub Actions, referencing an output from a skipped
step results in an empty string. This causes the `craft` action to run with an empty
`GITHUB_TOKEN`, leading to authentication failures and GitHub API errors. This bug
prevents contributors from successfully testing the workflow on their forks.
Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 7958081
Summary
Add
workflow_calltrigger torelease.ymlso external repositories can call it as a reusable workflow, providing an easier adoption path for Craft.Changes
.github/workflows/release.ymlworkflow_calltrigger with inputs mirroringaction.yml./action with release bot tokengetsentry/craft@v2with inherited secretsdocs/src/content/docs/github-actions.mdUsage
External repos can now use either approach: