Repository navigation
feature: support if: conditionals on imports: entries #58221
Description
Summary
Extend the imports: frontmatter (documented at Sharing Workflows and Imports Reference) to support an if: conditional per import entry, so an imported shared fragment (and any parameters passed via with:) can be enabled/disabled based on an expression, similar to if: on GitHub Actions steps/jobs.
Motivation
Shared fragments such as shared/otlp.md often depend on secrets or vars that may not be configured in every consuming repository (e.g. GH_AW_OTEL_SENTRY_AUTHORIZATION). Today there's no way to conditionally skip an import at compile/runtime if the required secret/var is empty, forcing consumers to either always define the secret or fork/omit the import manually.
This was raised concretely in #57960, which asks for OpenTelemetry setup to be disabled automatically when the Sentry/OTLP auth secret is empty. Adding conditional imports would let the shared fragment itself express this, e.g.:
---
on:
schedule: daily
engine: copilot
imports:
- uses: shared/otlp.md
with:
Authentication: ${{ secrets.GH_AW_OTEL_SENTRY_AUTHORIZATION }}
if: ${{ secrets.GH_AW_OTEL_SENTRY_AUTHORIZATION != '' }}
---Proposed behavior
- Each entry under
imports:(both the shorthand string form and theuses:/with:parameterized form) can optionally include anif:expression. - When
if:evaluates to falsy, the import is skipped entirely at compile time (or resolved to a no-op) — no merged frontmatter/content/tools/MCP config from that fragment is applied, and no error is raised for missing secrets/vars referenced only inside the skipped fragment. - Expression syntax and evaluation context should be consistent with existing
${{ }}expression support elsewhere in the frontmatter (e.g.secrets.*,vars.*), reusing the existing expression evaluator rather than introducing a new one. - Compilation should clearly report (e.g. in
gh aw compileoutput or lock file comments) which imports were skipped due to a falsyif:, to aid debugging. - Should work for both local and remote imports, and interact sensibly with parameterized templates (
with:schema validation should still apply to the values that would be substituted if the import were active).
Related
- feature: disable opentelemetry if secrets in the Authorization key are empty #57960 — the immediate use case this would resolve
- Sharing Workflows guide
- Imports Reference
Activity
imports:entries (if:) #58232 as a duplicate of this issuepelikhan commentedon Oct 7, 2026
Status (2026-10-07; Needs progress check): Open since September 3, this request proposes conditional
imports:entries so shared fragments can be omitted when required configuration is absent; no discussion or implementation progress is provided here. The next step is to check whether conditional imports are being pursued and clarify how their conditions would be evaluated.pelikhan commentedon Oct 16, 2026
Community issue refresher — 2026-10-16: Still relevant, but currently explicitly unsupported.
Current main does not merely lack an example: the import parser rejects an
ifmember with “import 'if' is no longer supported.” The imports reference instead documents conditional optional runtime prompt imports. That is not equivalent to conditionally omitting merged tools, MCP configuration, steps, and frontmatter.Related #57960 and the design discussion #58232 are closed, but that alone does not implement this broader request. The unresolved design question is still compile-time structural merging versus runtime secret availability: the compiler cannot evaluate a repository secret's actual value while compiling.
A useful next decision is whether to pursue runtime-gated generated behavior or deliberately keep structural imports unconditional and document narrower alternatives. This is static inspection, not a workflow execution or a claim that the original OTLP failure still reproduces.
pelikhan commentedon Oct 22, 2026
Relevance check — 2026-10-22: keep open; the requested structural conditional imports remain unsupported. Checked live remote
mainatffdd9c9efe6a, not the October 16 snapshot.The parser still explicitly rejects
imports.if, and the current reference distinguishes unconditional structural imports from conditional optional runtime prompt imports. This is deliberate: merged #38247 removed conditional frontmatter imports to keep setup/security posture stable. Neither that prompt alternative nor closure of the narrower OTLP issue #57960 implements omission of merged tools, MCP configuration, steps, and frontmatter requested here; #58232 was closed as a duplicate, not as delivery of this feature.Next concrete step: record a maintainer design decision on whether to revisit structural gating under the compile-time security boundary or keep it unsupported and provide a narrowly scoped runtime-gated integration pattern. Any proposal must specify when conditions are evaluated (actual repository secret values are unavailable to the compiler), what is omitted, skipped-import validation, and diagnostics. No claim of implementation or runtime reproduction.