fix(ci): OPENAI_BASE_URL is optional, and an Actions variable not a secret

[Brian Krabach (bkrabach)]

Mirror of microsoft/amplifier-bundle-dot-runner#86, for this repo's own
capsule pipelines. Two owner rulings, 2026-09-07:

1. OPENAI_BASE_URL is OPTIONAL. Absent, the luna instance runs on the
   provider-openai module's own default endpoint -- "the default should have
   been fine". The preflight must not refuse for its absence.
2. It is NOT a secret. It is an endpoint URL, now set as a repository
   VARIABLE on both repos, so every workflow reads
   ${{ vars.OPENAI_BASE_URL || secrets.OPENAI_BASE_URL }} -- variable first,
   secret kept as a fallback so anyone who provisioned it as a secret is not
   broken. Character-identical to the expression in dot-runner#86.

What still refuses, unchanged

The issue-#155 / EXTENSIONS §36 guarantee is untouched: no run starts unable
to reach its second judge. The preflight still refuses, before any of the
30-90+ minute budget is spent, on

• a missing OPENAI_API_KEY (still a repo SECRET, still REQUIRED), and
• an instance the graphs address that provider-instances.yaml does not define.

Nothing was weakened to make the endpoint optional. Two new refusals were
added, because the mechanism has its own failure modes: an optional-vars:
directive naming a placeholder the template never references, and an unset
optional var still referenced after the line deletion -- i.e. in a shape too
tangled to remove surgically. An unexpandable ${VAR} is left VERBATIM by the
engine, which in a base_url would aim the run at a literal host.

How "optional" is expressed

provider-instances.yaml declares it, in a machine-readable directive the
installer reads:

#   optional-vars: OPENAI_BASE_URL

install_provider_instances.sh already derived the instance ids from the
graphs and the credential names from the template, so that neither list is
written down twice; optionality now comes from the same place. Unset, the whole
base_url: ${OPENAI_BASE_URL} line is left out of the installed file and the
step log says which branch the run took, in the same words dot-runner's inline
preflight uses:

  credentials present : OPENAI_API_KEY (values not printed; the file on disk holds ${VAR} placeholders, not secrets)
  keys omitted        : OPENAI_BASE_URL
  OPENAI_BASE_URL is unset -- OPTIONAL by owner ruling 2026-09-07, so its key was left out of the installed instance and the provider module's own default endpoint applies. ...

"The operator chose the default" and "the endpoint silently went missing" must
not read the same in a job log.

The scrubber

OPENAI_BASE_URL stays on the literal watch list -- an endpoint's value
carries no debugging value in evidence. What matters now is the EMPTY case,
which this change makes normal: an empty literal matches at every position in
every file, so an unguarded watch list would not leak the evidence tree, it
would destroy it. MIN_LITERAL_LEN already prevented that; nothing pinned it
and nothing said why it mattered. Now both, with a positive control so the
empty-value test cannot pass vacuously.

Tests -- RED first

tests/test_provider_base_url_optional.py is new and was RED before the
change, 5 of 11 failing on the unmodified tree:

FAILED test_absent_base_url_installs_the_instance_without_the_key
FAILED test_the_omission_is_surgical
FAILED test_every_workflow_reads_base_url_from_vars_then_secrets[capsule-specify.yml]
FAILED test_every_workflow_reads_base_url_from_vars_then_secrets[feature-specify.yml]
FAILED test_every_workflow_reads_base_url_from_vars_then_secrets[capsule-implement.yml]
5 failed, 5 passed

It runs the SHIPPED installer in a throwaway HOME with an explicitly built
environment, so a developer who exports OPENAI_BASE_URL cannot colour the
result. It covers unset and set-but-empty -- the shape CI actually
produces, since Actions sets the env entry to "" rather than dropping it --
proves the omission is surgical (installed file == template minus exactly that
one line, byte for byte), proves neither the URL nor the key is ever expanded
onto disk, keeps the two surviving refusals locked, and pins the workflow
expression fail-closed.

Verification

• python -m pytest tests/ -q --ignore=tests/e2e -> 241 passed, 2 skipped
  (both skips pre-existing).
• actionlint (with shellcheck) on all three changed workflows: the only
  findings are two pre-existing SC2012 infos, present identically on main.
• shellcheck clean on install_provider_instances.sh; PyYAML parses every
  workflow and the installed settings file in both branches.
• dot -Tsvg renders task-runner.dot after its header-comment fix.
• The scrubber's own suite: 33 passed, 103 subtests.

Records

A dated record keeps its words; a live claim gets corrected. The pipeline
README's Files rows and install_provider_instances.sh's refusal count are
corrected in place; the "New repo secrets required: OPENAI_API_KEY,
OPENAI_BASE_URL" lines in the README's re-sync log and in
docs/designs/REVIEW-pipelines-2026-09.md §4.4 are left verbatim and
superseded by an appended entry / a second addendum. task-runner.dot's header
bullet had been left by a same-day rename saying "OPENAI_API_KEY /
OPENAI_BASE_URL, not OPENAI_API_KEY" -- the same variable on both sides of a
contrast -- and now says what it meant to.

Generated with Amplifier

Co-Authored-By: Amplifier 240397093+microsoft-amplifier@users.noreply.github.com