Seed test fixture files into shared test repository to enable workflow and artifact testing against owned infrastructure

[MariusStorhaug]

The module exposes a workflow surface — Get-GitHubWorkflow, Start-GitHubWorkflow, Enable-GitHubWorkflow, Disable-GitHubWorkflow, and the run management functions in Workflows/Runs/ — but none of these are exercised in Actions.Tests.ps1. The current Actions tests cover only OIDC claims. The shared test repository is created with a README, a license, and a .gitignore, but contains no .github/workflows/ files, so the Workflow functions have no target to operate on.

Similarly, Artifacts.Tests.ps1 reads artifacts from $env:GITHUB_REPOSITORY_OWNER / $env:GITHUB_REPOSITORY_NAME (the PSModule/GitHub repository itself) and the current workflow run. This means artifact tests can only run inside the CI workflow — they silently have no data and likely fail when run locally or against the shared test repository.

Request

Desired capability

A set of version-controlled test fixture files in tests/Data/ that the shared test repository's BeforeAll seed into the repository via the GitHub API. Once seeded, the fixture content is stable and predictable, providing a reliable surface for testing workflow and content-related functions without relying on the live state of PSModule/GitHub itself.

The primary fixture is a workflow_dispatch-enabled GitHub Actions workflow. With this in the shared test repository, the following become testable against owned infrastructure:

• Get-GitHubWorkflow — list and retrieve workflows by ID or filename
• Enable-GitHubWorkflow / Disable-GitHubWorkflow — toggle state
• Start-GitHubWorkflow — dispatch a run
• Get-GitHubWorkflowRun / Stop-GitHubWorkflowRun / Restart-GitHubWorkflowRun / Remove-GitHubWorkflowRun — manage runs produced by the dispatched workflow

Secondary fixtures (simple text or binary files, a README, a nested directory structure) support testing file content APIs if those are added in future, and make the shared repository more representative of a real-world repository.

Acceptance criteria

• tests/Data/ contains at least one workflow_dispatch-enabled workflow YAML file that can be committed into a test repository and triggered via Start-GitHubWorkflow.
• tests/BeforeAll.ps1 (or the leaf test file BeforeAll) seeds the fixture files into the shared test repository using the module's own file-creation APIs, so the process exercises the module under test.
• Actions.Tests.ps1 is expanded to cover Get-GitHubWorkflow, Enable-GitHubWorkflow, Disable-GitHubWorkflow, Start-GitHubWorkflow, and at least Get-GitHubWorkflowRun.
• Artifact tests no longer depend on the live state of PSModule/GitHub or the current workflow run — they use artifacts produced by workflow runs dispatched against the shared test repository.
• All fixture-seeded content is idempotent (seeding the same files twice produces the same repository state).
• No test reads from $env:GITHUB_REPOSITORY_OWNER / $env:GITHUB_REPOSITORY_NAME to access PSModule/GitHub itself as a data source.

---

Technical decisions

Fixture file location: tests/Data/Workflows/ for workflow YAML files. A single test-dispatch.yml is sufficient to start — a minimal workflow_dispatch workflow that does something verifiable (e.g., writes a step summary or creates a simple artifact). Additional fixtures can be added as further functions are tested.

Seeding mechanism: Use New-GitHubContent (or Set-GitHubContent if it exists) to commit each fixture file into the shared repository's .github/workflows/ path during BeforeAll. This exercises the module's content API as a side effect. Files are committed to the default branch so the workflow is immediately dispatchable. Because Set-* is idempotent, re-running BeforeAll on the same repository produces no duplicate commits.

Artifact test re-homing: Artifact tests should dispatch the test workflow (via Start-GitHubWorkflow) and wait for the run to produce an artifact, then assert against that artifact. Alternatively, if waiting for a run is too slow or unreliable, a pre-created artifact fixture could be uploaded directly via the GitHub API rather than produced by a real run — but this only tests the artifact retrieval side, not the full pipeline. The right scope is a discussion item.

BeforeAll vs. leaf BeforeAll: Seeding workflow files into the shared repository can happen in tests/BeforeAll.ps1 alongside repository creation (since workflows are repository-level fixtures, not per-test-run resources). This keeps the per-leaf BeforeAll lightweight. Alternatively, workflow seeding can live in Actions.Tests.ps1's per-context BeforeAll if tighter test isolation is preferred.

Workflow dispatch timing: Start-GitHubWorkflow returns immediately; the run appears in the API after a short delay. Tests that query runs after dispatch need a polling or wait strategy. Existing patterns in the module or test suite (if any) should be reused; if none exist, a small helper in tests/Data/ is appropriate.

Open: Whether to expand artifact tests to cover a full dispatch → run → artifact lifecycle, or scope this issue to workflow fixture seeding + workflow function coverage only, leaving artifact re-homing as a follow-up. The acceptance criteria above target the broader scope; this can be narrowed during planning.

---

Implementation plan

Fixture files

• Add tests/Data/Workflows/test-dispatch.yml — a minimal workflow_dispatch workflow (e.g., writes hello from test-dispatch to $GITHUB_STEP_SUMMARY; optionally uploads a small artifact)
• Add any additional fixture files (text, binary, nested directory) as needed for content API coverage

BeforeAll seeding

• In tests/BeforeAll.ps1, after creating the shared repository, commit test-dispatch.yml to .github/workflows/test-dispatch.yml using New-GitHubContent (or Set-GitHubContent)
• Confirm the commit is idempotent — if the file already exists with the same content, no redundant commit is made
• Confirm the workflow is enabled and visible via Get-GitHubWorkflow after seeding

Actions.Tests.ps1 expansion

• Add Get-GitHubWorkflow — list all workflows, retrieve by ID and by filename
• Add Enable-GitHubWorkflow / Disable-GitHubWorkflow — verify state transitions and idempotency
• Add Start-GitHubWorkflow — dispatch a run and confirm a run appears in Get-GitHubWorkflowRun
• Add Get-GitHubWorkflowRun — list runs, filter by workflow, retrieve by ID
• Add Stop-GitHubWorkflowRun / Remove-GitHubWorkflowRun — at minimum, clean up runs created during tests

Artifacts.Tests.ps1 re-homing

• Replace $Owner = $env:GITHUB_REPOSITORY_OWNER / $Repository = $env:GITHUB_REPOSITORY_NAME with the shared test repository owner and name
• Replace $WorkflowRunId = $env:GITHUB_RUN_ID with a run ID obtained from a dispatched test workflow run (or a pre-uploaded artifact if full dispatch is out of scope)
• Confirm artifact tests pass both in CI and when run locally (with appropriate credentials)

Verification

• Run Actions.Tests.ps1 standalone (Invoke-Pester tests/Actions.Tests.ps1) against a populated shared test repository and confirm all new tests pass
• Run Artifacts.Tests.ps1 standalone and confirm it no longer depends on PSModule/GitHub or GITHUB_RUN_ID

[MariusStorhaug]

Heads up: when this work changes how tests provision, share, or tear down infrastructure (e.g., adding a fixture-seeding step to BeforeAll.ps1 or per-context BeforeAll), update .github/instructions/tests.instructions.md in the same PR. That file is the single source of truth for test conventions and is auto-loaded by Copilot for every edit under tests/**, so contributors and the agent stay aligned.