fix(action): Simplify install by using build artifact with release fallback#705
Merged
fix(action): Simplify install by using build artifact with release fallback#705
Conversation
Contributor
Semver Impact of This PR🟢 Patch (bug fixes) 📋 Changelog PreviewThis is how your changes will appear in the changelog. Bug Fixes 🐛Action
🤖 This preview updates automatically when you update the PR. |
fcd0476 to
9196836
Compare
…llback The github context is not available when the `uses:` field is evaluated, so we can't use dynamic action references. Instead, inline the install logic into action.yml: - For dogfooding (getsentry/craft): Download from build artifact if available - For all repos (or if artifact unavailable): Download from release using github.action_ref, with fallback to latest This removes the install/ sub-action and all the duplicate Node.js/pnpm build-from-source logic, keeping the flow simple while still enabling dogfooding via the build job's artifact.
9196836 to
637cdde
Compare
In the getsentry/craft repo, the build artifact should always be available from the build job. If the download fails, that's a real error we should surface rather than silently falling back to the release binary.
betegon
approved these changes
Jan 12, 2026
Member
betegon
left a comment
There was a problem hiding this comment.
this will unblock Spotlight too.
Add explicit craft_version input as the primary source for determining which Craft version to install, with github.action_ref as a fallback. This ensures reliable version pinning for external repos even if github.action_ref is empty or unavailable in certain contexts. The install logic now: 1. Use craft_version input if provided 2. Fall back to github.action_ref if not 3. If both are empty or "latest", download latest release 4. Otherwise download the specified version with fallback to latest if not found
The merge-artifacts job in build.yml only runs if both build and docs jobs succeed. If docs fails, merge-artifacts is skipped and the artifact won't exist. Without continue-on-error, the download would fail and break the release workflow. Restoring continue-on-error allows graceful fallback to downloading from release if the artifact doesn't exist for any reason.
billyvg
approved these changes
Jan 12, 2026
Member
billyvg
left a comment
There was a problem hiding this comment.
Looks good pending bot review.
Since docs should block releases, if the docs job fails, merge-artifacts won't run and the artifact won't exist. Without continue-on-error, the artifact download will fail, properly propagating the failure. This ensures the release workflow fails fast if any required build step (including docs) fails, rather than silently falling back to downloading from release. Also adds if-no-files-found: ignore to the merge-artifacts upload step to handle the gh-pages.zip file that may not exist.
Add comprehensive error handling to prevent silent failures: 1. Use 'set -euo pipefail' to fail fast on any error 2. Change curl flags from -s to -fsSL (fail on HTTP errors) 3. Verify CRAFT_URL is not empty before downloading 4. Verify downloaded binary is not empty after download 5. Use GitHub Actions error annotations (::error::) for clear failures This prevents scenarios where: - GitHub API fails/rate limits - Network issues occur - Release asset is missing - Binary download fails but script continues All these cases now fail fast with clear error messages.
7 tasks
BYK
added a commit
that referenced
this pull request
Jan 12, 2026
…e install The install/ sub-action was removed in #705, breaking the changelog-preview workflow which still referenced getsentry/craft/install@master. Replace it with the same inline install logic from action.yml: - Download from release using craft-version input - Fall back to latest if version not found - Add robust error handling and validation
BYK
added a commit
that referenced
this pull request
Jan 12, 2026
…e install The install/ sub-action was removed in #705, breaking the changelog-preview workflow which still referenced getsentry/craft/install@master. Replace it with inline install logic that downloads from release: - Respects craft-version input (defaults to latest) - Falls back to latest if specified version not found - Adds robust error handling with set -euo pipefail - Verifies download succeeded and binary is valid - Runs craft --version to confirm installation Note: Dogfooding (using build artifact from PRs) is not implemented because: - Build workflow runs separately with workflow-scoped artifacts - Cross-workflow artifact fetching adds complexity - Changelog preview is less critical than main release action We always use released versions for changelog previews.
BYK
added a commit
that referenced
this pull request
Jan 12, 2026
…e install (#706) ## Problem PR #705 removed the `install/` sub-action, but the `changelog-preview.yml` workflow was still referencing it: ```yaml uses: getsentry/craft/install@master ``` This broke the changelog preview workflow for all PRs. ## Solution Replace the deleted sub-action reference with inline install logic that downloads Craft from release: - Respects `craft-version` input (defaults to latest) - Falls back to latest if specified version doesn't exist - Adds robust error handling with `set -euo pipefail` - Verifies download succeeded and binary is valid - Runs `craft --version` to confirm installation ## Why No Dogfooding? Unlike the main release action, this workflow **does not dogfood** (use build artifacts from PRs) because: 1. **Different workflow runs**: The build workflow runs separately, and artifacts are scoped to that workflow run 2. **Complexity**: Cross-workflow artifact fetching would require additional dependencies and logic 3. **Timing issues**: Build workflow might still be running when changelog-preview starts 4. **Lower criticality**: Changelog preview is less critical than the main release action For changelog previews, we always use the released version of Craft.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The previous fix (#704) used
uses: getsentry/craft/install@${{ github.action_ref }}which fails because thegithubcontext is not available when theuses:field is evaluated:Additionally, the
install/sub-action duplicated build logic (Node.js, pnpm, build from source) that was already in the build job.Solution
Simplify the install flow:
getsentry/craft): Download from build artifact if availablegithub.action_ref, with fallback to latestThis approach:
install/sub-action entirelygithub.action_refin a shell script where the context is availableNet result: 34 additions, 91 deletions - much simpler!