Move CreateRelease update check to separate job

[Florian (frottke)]

❔What, Why & How

Change

This PR moves the existing AL-Go system file update check out of the CreateRelease job and into a dedicated CheckForUpdates job.

The change applies to both the AppSource App and Per Tenant Extension release templates.

The update check does not need to block release creation. With a separate job, CheckForUpdates can run in parallel with CreateRelease, so release creation no longer has to wait for the check to complete.

The check itself remains reporting-only. Updates are still applied through the existing Update AL-Go System Files workflow.

Additional test coverage

While working on this, I noticed that the existing ModifyRunsOnAndShell logic had no test coverage.

I added tests for the existing behavior, including workflows with multiple jobs and the validation of invalid runner/shell combinations.

Open question

While looking at the update check, I also started wondering whether we need it in the Create Release workflow at all.

In many cases, CI/CD has already run shortly before creating a release and performed the same check. I am not sure the additional check during release creation provides much value.

Would it make sense to remove it from Create Release entirely? If so, I can adjust this PR accordingly.

✅ Checklist

• Add tests (E2E, unit tests)
• Update RELEASENOTES.md
• Update documentation (e.g. for new settings or scenarios)
• Add telemetry

[Copilot]

Pull request overview

Moves update checks into a parallel job so release creation no longer waits for them.

Changes:

• Adds independent CheckForUpdates jobs to both release templates.
• Adds tests for runner and shell customization.
• Updates documentation and release notes.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
Tests/CheckForUpdates.Action.Test.ps1	Tests runner and shell modification behavior.
Templates/Per Tenant Extension/.github/workflows/CreateRelease.yaml	Separates the update check from release creation.
Templates/AppSource App/.github/workflows/CreateRelease.yaml	Separates the update check from release creation.
Scenarios/CreateRelease.md	Documents the independent update-check job.
RELEASENOTES.md	Announces the workflow improvement.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

Both reporting-only jobs must be restricted to job-level read permissions while retaining id-token: write.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (4)

Templates/AppSource App/.github/workflows/CreateRelease.yaml:129

• The update-check cleanup also needs to stop explicitly requesting ghTokenWorkflow in the CreateRelease job. That job now only consumes TokenForPush, and ReadSecrets already resolves ghTokenWorkflow when useGhTokenWorkflowForPush is true; leaving it in the list retrieves and emits the secret even when that option is false.

          get: repoName,type,powerPlatformSolutionFolder

Templates/AppSource App/.github/workflows/CreateRelease.yaml:70

• Add CheckForUpdates to PostProcess.needs. As written, PostProcess can run while this independent job is still in progress; WorkflowPostProcess then queries job conclusions and records success/duration before this check finishes, so a later failure or delay is omitted from telemetry. Waiting only in PostProcess preserves parallel release creation while ensuring finalization is actually last.

  CheckForUpdates:

Templates/Per Tenant Extension/.github/workflows/CreateRelease.yaml:129

• The update-check cleanup also needs to stop explicitly requesting ghTokenWorkflow in the CreateRelease job. That job now only consumes TokenForPush, and ReadSecrets already resolves ghTokenWorkflow when useGhTokenWorkflowForPush is true; leaving it in the list retrieves and emits the secret even when that option is false.

          get: repoName,type,powerPlatformSolutionFolder

Templates/Per Tenant Extension/.github/workflows/CreateRelease.yaml:70

• Add CheckForUpdates to PostProcess.needs. As written, PostProcess can run while this independent job is still in progress; WorkflowPostProcess then queries job conclusions and records success/duration before this check finishes, so a later failure or delay is omitted from telemetry. Waiting only in PostProcess preserves parallel release creation while ensuring finalization is actually last.

  CheckForUpdates:

• Files reviewed: 5/5 changed files
• Comments generated: 2
• Review effort level: Balanced

[Florian (frottke)]

I’m not sure about that. At the moment, it’s identical to CICD.yaml.
Maria Zhelezova (@mazhelez), what do you think?

[Florian (frottke)]

I’m not sure about that. At the moment, it’s identical to CICD.yaml.
Maria Zhelezova (@mazhelez), what do you think?