Accept ASPECT_WORKFLOWS_DELIVERY_FORCE_TARGETS env var alongside --force-target#1027
Merged
gregmagolan merged 3 commits intomainfrom Apr 28, 2026
Merged
Conversation
277a025 to
aacde32
Compare
Adds a manual break-glass parameter to all four CI providers so users
can force-deliver specific targets without editing the pipeline:
- GitHub Actions: workflow_dispatch input → env on delivery-task
- Buildkite: input step (gated on UI-triggered builds via build.source)
→ meta-data → env in delivery-task
- GitLab: pipeline-level FORCE_TARGETS variable (default empty,
description shown on "Run pipeline" UI) → env on delivery-task
- CircleCI: pipeline parameter → env on delivery-task
Default is empty everywhere — normal selective delivery is preserved on
every push/PR build. Also exercises the new
ASPECT_WORKFLOWS_DELIVERY_FORCE_TARGETS env-var support added in this
PR.
6eef7ef to
b2debd6
Compare
allow_dependency_failure: true was too broad — it would also have masked pre-build failures. Switch to per-dependency allow_failure on the input step alone. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
gregmagolan
added a commit
that referenced
this pull request
Apr 28, 2026
…set (#1028) ## Summary `--force-target` (and the `ASPECT_WORKFLOWS_DELIVERY_FORCE_TARGETS` env var from #1027) only flip the change-detection skip for labels already selected by `--query` or positional args — they don't add new labels to the delivery set. Previously, unmatched force-target labels were silently ignored. This PR hard-fails at startup listing the unmatched labels, with a hint pointing at `--query` / positional args. ## Why This came up immediately after #1027 landed: a user wired `ASPECT_WORKFLOWS_DELIVERY_FORCE_TARGETS` to a Buildkite UI input expecting drop-in replacement of the legacy `ASPECT_WORKFLOWS_DELIVERY_TARGETS` (which was an *override*, not a force). They passed `//foo:bar` but the header still showed only `//examples/deliverable` — no error, no warning, no clue why. A typo or stale label silently turning a force-deliver into a no-op is a footgun, so we surface it loudly. Hard fail beats warn here because force-target is a break-glass operation and a silent miss is worse than a visible startup error. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Summary
Mirrors the legacy
ASPECT_WORKFLOWS_DELIVERY_TARGETSergonomics:aspect deliverynow readsASPECT_WORKFLOWS_DELIVERY_FORCE_TARGETS(whitespace-separated Bazel labels) and merges those labels with anything passed via--force-target.Why
CI systems generally make it easier to wire a user-supplied parameter field (workflow_dispatch input, Buildkite input step, GitLab pipeline variable, CircleCI pipeline parameter) to an env var than to template it into a flag. Previously a user had to edit the CI config to force-deliver an ad-hoc target list; now the CI job can declare a parameter once and accept the target list at trigger time.
Behavior:
--force-target(deduplicated) before change-detection runs.