Repository navigation
Add reusable build workflow invocation for spel CI - #79
Merged
Merged
Conversation
plus3it/spel#839 (feat/workflow-call-support) has merged into master at 525049d. Point the build job there instead of the PR branch tip.
GitHub Actions statically validates permissions for every job in a called reusable workflow's graph, including jobs gated by an if: condition that will never actually run in this context. spel's release-pr job declares contents: write and pull-requests: write, so the build job here must grant at least that ceiling or the workflow call is rejected at validation time, even though release-pr only runs for spel's own schedule/SPEL_RELEASE triggers. See actions/runner#4151 and https://github.com/orgs/community/discussions/63736 for confirmation this is a known, by-design GitHub Actions limitation.
The CodeBuild GitHub webhook integration gates on the workflow job's parent workflow name, which must be exactly 'Build images' (matching spel's own top-level workflow name) for the webhook to trigger CodeBuild-hosted runners. Renamed from 'Build AMIs via spel' to match.
eemperor
previously approved these changes
Sep 29, 2026
Contributor
|
This pull request does not currently match the merge queue conditions, so it cannot be queued from here. The box comes back if it matches again. |
lorengordon
force-pushed
the
feat/spel-build-workflow
branch
from
September 29, 2026 16:14
82bc40b to
f9d09b0
Compare
lorengordon
force-pushed
the
feat/spel-build-workflow
branch
from
September 29, 2026 17:48
f9d09b0 to
2b51a5e
Compare
eemperor
approved these changes
Sep 29, 2026
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.
Description:
Adds
.github/workflows/build.yml, which invokes spel's newworkflow_call-triggered reusable build workflow to run ephemeral/on-demand AMI builds directly from this repo, without needing to push changes to spel first.workflow_dispatch(with optionalSPEL_VERSION,SPEL_FORCE,SPEL_BUILDERS,SPEL_PROJECTSoverrides) and on PR review comments containing/build.preparejob computes defaults (full builder/project matrix, date+sha version) and builds the JSON-encodedAMIGEN9_SOURCEpointing at the PR head branch (for review-triggered builds) or the pushed ref otherwise.buildjob callsplus3it/spel/.github/workflows/build.ymlviauses:, passing the computed inputs through.Rationale:
Currently, testing amigen9 changes against spel's build pipeline requires opening a PR against spel itself. This workflow lets contributors trigger a full spel-driven AMI build directly from an amigen9 branch or PR, using amigen9's own CodeBuild-hosted runners.
plus3it/spel#839 (
feat/workflow-call-support), which addsworkflow_callsupport to spel's build workflow, has now merged into spel'smaster. Thebuildjob is pinned to that merge commit (525049d).Permissions fix:
After re-pinning to the real merge commit, the
buildjob started failing workflow validation with:This is confirmed as a known, by-design GitHub Actions limitation, not a bug in this workflow: GitHub statically validates the permissions declared by every job in a called reusable workflow's graph against the caller's granted permission ceiling at workflow-parse time, before any
if:conditions are evaluated at runtime. spel'srelease-prjob declarescontents: write, pull-requests: writeand is only gated to run viaif:(never true for amigen9's triggers), but its declared permissions still had to fit within the ceiling amigen9 granted.References:
needs/ifshould prevent errors about nested jobs violating permissions actions/runner#4151 ("needs/ifshould prevent errors about nested jobs violating permissions" — confirms there is no way to guard against this viaif:)ifcondition... in theSet up jobstep")Fixed by adding a job-level
permissions:override on thebuildjob grantingcontents: writeandpull-requests: write, matching spel's ceiling requirement. These elevated permissions are never actually exercised sincerelease-prnever runs for amigen9's triggers.Reference Issue:
N/A