* ci: expand labeler globs and skip dependabot pr policy
.NET product paths never matched app, so backend PRs stayed unlabeled. Dependabot PRs still ran commit-subject and pin checks on generated titles. Skip those PRs in the reusable policy job.
* fix(labeler): match nested elastic beanstalk config paths
Root-only .ebextensions and .platform globs miss api/.ebextensions in monorepos. Mirror the Dockerfile nested form.
ci-python-app.yaml and ci-mobile-ios.yaml built their concurrency group
from ${{ github.job }}. In a called workflow that expression evaluates to
the caller's job id, not the job's own id, so every job in the reusable
resolved to the same group. With cancel-in-progress: true they cancelled
each other.
Observed in pr-reviewer after repinning it off a ref that predates the
concurrency blocks: one run, ci / lint cancelled 1s after start by a
sibling, ci / subproject-tests succeeded, and the aggregator failed on the
cancelled dependency.
Replaces the expression with the job id written out literally in all 7
groups, and records the reason at the first block in each file.
release.yaml documented a generic caller example but not the caller that
actually exists in this repo. Notes that release-on-merge.yaml computes the
version, calls this workflow by local path, and is the only caller that does
so without a version comment.
Callers pin `uses:` to a commit SHA of this repo. Dependabot's
github-actions updater finds a newer SHA for a pinned ref by reading the
target repo's tags and releases; this repo has 0 tags and 0 releases, so
there is nothing for it to resolve and it reports no update. The fleet's
pins have not moved as a result.
Adds a caller for the release reusable, triggered on push to main and
filtered to paths under .github/workflows/ excluding the three files no
caller consumes (ci.yaml, labeler.yaml, and this file).
Version is a patch bump from the highest existing vMAJOR.MINOR.PATCH tag,
1.0.0 when none exist. workflow_dispatch takes an explicit version for
minor and major bumps.
Runs are serialised with cancel-in-progress false: two merges landing
together would otherwise read the same highest tag, compute the same next
version, and the second would hit the reusable's existing-tag guard and
no-op, leaving that change unreleased.
release.yml / release.properties.json and ci-mobile-ios.yml /
ci-mobile-ios.properties.json are new caller templates for the two reusable
workflows added in 9389e51. Both pin the reusable to 9389e51, the commit that
introduces the workflow files.
release.yml triggers on workflow_dispatch with a required `version` input and
declares `permissions: contents: write`, which the reusable needs to push the
tag and publish the Release. ci-mobile-ios.yml triggers on pull_request and
keys its job `ci` so the check context resolves to `ci / ci`.
ci-python.yml now passes `node-version: "24"`. Its target,
ci-python-sam.yaml, declares that input at line 34 with default "24"; the
ci-static, ci-typescript-frontend, ci-node, cdk-deploy and mobile-ios-deploy
templates already pass the same value.
Both new .properties.json files carry the same five keys as the thirteen
existing ones: categories, description, filePatterns, iconName, name.
release.yaml is workflow_call-only. It normalises and validates a `version`
input against MAJOR.MINOR.PATCH, skips every mutating step when the tag or a
Release for it already exists, creates an annotated tag with `git tag -a` and
publishes a GitHub Release with `gh release create --verify-tag`. Top-level
permissions grant `contents: write` only; no id-token is requested. The
previous-tag lookup and `--generate-notes` both work in a repo with no tags.
ci-mobile-ios.yaml is workflow_call-only and pairs with cd-mobile-ios.yaml,
reusing its node-version, ruby-version, working-directory,
cache-dependency-path and fastlane-lane input names. Job `js` runs npm ci,
typecheck, optional lint and optional tests on ubuntu-latest. Job `ios-build`
runs pod install and `xcodebuild build` on macos-26 with
CODE_SIGNING_ALLOWED=NO, CODE_SIGNING_REQUIRED=NO and CODE_SIGN_IDENTITY="";
it declares no secrets and performs no upload. Job `ci` aggregates both via
`needs` so a caller job keyed `ci` reports `ci / ci`. All three jobs carry
job-level concurrency with cancel-in-progress: true. Top-level permissions are
`contents: read`.
The Fastlane branch carries a per-line `# shellcheck disable=SC2086` because
fastlane requires the platform and lane as two argv entries.
The self-CI gate ran `./actionlint -shellcheck=`, and the empty value
silently disabled the shell-linting half of the check — so every `run:`
body in the reusable workflows this repo publishes was unlinted, on the
exact path that deploys to AWS.
Measured against the pinned actionlint 1.7.12 and the shellcheck the
ubuntu-latest runner ships (0.9.0-1), the real backlog was 5 findings,
not the 4 the old comment claimed. Three were genuine and are fixed in
the shell:
- cd-cdk.yaml "Publish .NET project" (SC2046): the project path was
interpolated inline and `$(dirname ...)` was unquoted, so a path
containing whitespace split into several arguments. Now passed via
env indirection and quoted, which also removes the last inline
expression interpolation from that step.
- cd-cdk.yaml / ci-python-sam.yaml "Install Python dependencies"
(SC2044 x2): `for req in $(find ...)` word-split and globbed every
path found. Replaced with a NUL-delimited `while read` loop.
Two are deliberate and are suppressed per-line, with the reasoning in a
comment directly above:
- cd-sam.yaml `sam deploy ... $PARAMS` and cd-cdk.yaml
`cdk deploy $STACKS` (SC2086 x2) rely on word-splitting so multiple
parameter overrides / stack selectors reach the CLI as separate argv
entries. Quoting them would collapse each into a single argument and
break every parameterised or multi-stack deploy, so they keep the
unquoted expansion and carry a scoped `# shellcheck disable=SC2086`.
The gate now runs plain `./actionlint` (shellcheck defaults to the
binary on PATH) and prints `shellcheck --version` first, so the check
fails loudly if a future runner image drops it instead of quietly
linting less.
cd-dotnet-eb already serialises deploys per environment; the other three
deploy reusables had no concurrency group, so back-to-back merges could
start overlapping runs against the same target. CloudFormation rejects a
concurrent update on the same stack and cd-sam/cd-cdk pre-flight already
hard-fails on an in-progress stack, so the symptom is a failed run that
needs a manual re-run rather than a corrupted deploy. Grouping makes
those deploys queue instead.
Each group key names the thing being deployed, so independent targets in
one caller repo still deploy in parallel:
cd-sam region + stack-name (both always non-empty)
cd-cdk region + stacks + stack-name
cd-mobile-ios working-directory + fastlane-lane (both default)
cd-cdk keys on the stack selector rather than stack-name because
seahaven-org-baseline calls it from five jobs in a single run, one per
AWS account, and two of those pass no stack-name. Keying on stack-name
alone would collapse them into one group and serialise five independent
per-account deploys.
cancel-in-progress is false on all three, matching cd-dotnet-eb: unlike
CI, cancelling a deploy midway can leave infrastructure mid-update.
GitHub Actions expressions are substituted into a run body as text
before bash parses it, so a value carrying a quote, a command
substitution, or a newline becomes shell syntax rather than data.
cd-sam.yaml interpolated the parameter-overrides secret straight into
a shell test and an assignment, putting secret material into the script
body. cd-cdk.yaml interpolated the caller-supplied post-deploy-script
input into a bash invocation, which is caller-controlled command
injection rather than secret exposure.
Both now use env-var indirection, matching the STACKS precedent in the
CDK deploy step. PARAM_OVERRIDES is deliberately left unquoted at the
point of use: parameter-overrides carries multiple Key=Value pairs that
must reach sam deploy as separate argv entries, so quoting it would
collapse every override into one argument and break deploys that use
it. POST_DEPLOY_SCRIPT is a single path and is quoted.
Behaviour is otherwise unchanged. An empty parameter-overrides still
produces no --parameter-overrides flag at all, and an empty
post-deploy-script is still skipped by the step-level if condition,
which is a workflow expression and not shell.
