Replace duplicated test-secret blocks with `secrets: inherit` in ModuleLocal workflows

[MariusStorhaug]

Maintaining the test infrastructure secrets for local module testing requires editing the same seven-secret block in four places: workflow.yml, BeforeAll-ModuleLocal.yml, Test-ModuleLocal.yml, and AfterAll-ModuleLocal.yml. Adding, renaming, or removing a secret requires synchronized edits across all four files with no compiler or linter to catch drift.

Request

Current experience

The following secret declarations and env: mappings are 100% identical across three reusable workflows:

Secret	BeforeAll-ModuleLocal.yml	Test-ModuleLocal.yml	AfterAll-ModuleLocal.yml
TEST_APP_ENT_CLIENT_ID	✓	✓	✓
TEST_APP_ENT_PRIVATE_KEY	✓	✓	✓
TEST_APP_ORG_CLIENT_ID	✓	✓	✓
TEST_APP_ORG_PRIVATE_KEY	✓	✓	✓
TEST_USER_ORG_FG_PAT	✓	✓	✓
TEST_USER_USER_FG_PAT	✓	✓	✓
TEST_USER_PAT	✓	✓	✓

Additionally, workflow.yml passes these same seven secrets explicitly to each of the three child workflows (lines 170–177, 196–203, 218–223), adding a fourth copy of the list.

Desired experience

Secrets are declared once and inherited by child workflows automatically. Adding a new test secret requires editing only one file.

Acceptance criteria

• Test secrets are defined in a single location
• Adding or removing a test secret requires editing only one file
• BeforeAll-ModuleLocal.yml, Test-ModuleLocal.yml, and AfterAll-ModuleLocal.yml receive secrets without explicit per-secret pass-through
• No change in runtime behavior — all tests continue to have access to the same secrets

Note

This is a DRY violation. It also overlaps with #52 (support passing arbitrary secrets), but this issue is narrower: eliminate the structural duplication regardless of how arbitrary secrets are eventually handled.

---

Technical decisions

Approach: Use GitHub Actions secrets: inherit on the workflow_call invocations in workflow.yml. This passes all secrets from the caller to the reusable workflow without enumerating them. The child workflows then reference secrets directly in their env: blocks without needing secrets: input declarations.

Trade-off: secrets: inherit passes all available secrets, not just test secrets. This is acceptable because:

• The child workflows only reference the specific secret names they need in their env: blocks
• The security boundary is the repository/organization secret scope, not the workflow declaration
• This pattern is already recommended by GitHub for exactly this use case

Alternative considered: A single composite action wrapping the secret-to-env mapping — rejected because composite actions cannot access secrets context directly.

---

Implementation plan

workflow.yml changes

• Replace explicit secrets: blocks on BeforeAll-ModuleLocal, Test-ModuleLocal, and AfterAll-ModuleLocal jobs with secrets: inherit

Child workflow changes

• Remove secrets: input declarations from BeforeAll-ModuleLocal.yml
• Remove secrets: input declarations from Test-ModuleLocal.yml
• Remove secrets: input declarations from AfterAll-ModuleLocal.yml
• Update env: blocks in each child workflow to reference ${{ secrets.SECRET_NAME }} directly (instead of ${{ secrets.SECRET_NAME }} via the input — verify current syntax)

Testing

• Verify BeforeAll.ps1 still receives test secrets as environment variables
• Verify test jobs still authenticate successfully
• Verify AfterAll.ps1 cleanup still works with inherited secrets