Issue 2336 - Option to fail deployment

[Thomas Rønn (thomasroennTRM)]

❔What, Why & How

What

Adds an opt-in setting, failOnAppVersionDowngrade (default false). When it's enabled, the CI/CD deployment fails if an app in the build artifact has a lower version than the app already installed in the environment.

You can set it globally or per environment in DeployTo. The environment value takes precedence.
A new CheckDowngrade action runs before Deploy to Business Central in the PTE and AppSource App CI/CD workflows.
Why

Today, a deployment where the artifact version is lower than the installed version only produces a warning. The workflow still succeeds, so it's easy to miss that the apps were never updated. This setting lets you make that case fail the workflow.

How

The CI/CD workflow works out the effective setting for the environment.
If the setting is true, CheckDowngrade compares each app in the artifact with the installed version in the environment.
If any app would be downgraded, it writes one error per app and fails the deploy job.

Related to issue: #2336
#2336

✅ Checklist

• Add tests (E2E, unit tests) - did have som issues with getting the e2e to function, so not tested. Looks like this was optional.
• Update RELEASENOTES.md
• Update documentation (e.g. for new settings or scenarios)
• [-] Add telemetry

[Thomas Rønn (thomasroennTRM)]

@microsoft-github-policy-service agree

[Copilot]

Copilot review overview

🟡 Changes recommended

Settings resolution, environment targeting, and artifact selection can diverge from the actual deployment and cause false passes or failures.

Review effort: Balanced
Findings: 4 · 2

Open (6)

• Validate the actual deployment artifact set · New
• Use the resolved Business Central environment · New
• Use merged Settings for downgrade policy · New
• Use merged Settings for downgrade policy · New
• Add failOnAppVersionDowngrade to the environment schema · New
• Add required comment-based help · New

What changed in this PR

Adds an opt-in safeguard that blocks CI/CD deployments when artifact app versions are lower than installed versions.

Changes:

• Adds the CheckDowngrade action and unit tests.
• Integrates downgrade validation into PTE and AppSource workflows.
• Documents and registers the new setting.

File	Description
Actions/​CheckDowngrade/​CheckDowngrade.ps1	Implements downgrade detection.
Actions/​CheckDowngrade/​action.yaml	Defines the composite action.
Actions/​CheckDowngrade/​README.md	Documents action usage.
Tests/​CheckDowngrade.Action.Test.ps1	Tests core action behavior.
Templates/​Per Tenant Extension/​.github/​workflows/​CICD.yaml	Adds PTE pre-deployment validation.
Templates/​AppSource App/​.github/​workflows/​CICD.yaml	Adds AppSource pre-deployment validation.
Actions/​.Modules/​ReadSettings.psm1	Adds the default setting.
Actions/​.Modules/​settings.schema.json	Defines global schema metadata.
Scenarios/​settings.md	Documents global and environment settings.
RELEASENOTES.md	Announces the new action.

---

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

[Copilot]

Copilot review overview

🟡 Changes recommended

The checker can break custom deployments, and its test-app behavior conflicts with the documentation.

Review effort: Balanced
Findings: 1 · 1

Open (2)

• Downgrade check runs before custom deployment scripts · New
• Test apps are incorrectly included in downgrade validation · New

Resolved since last review (6)

• Use merged Settings for downgrade policy
• Use merged Settings for downgrade policy
• Use the resolved Business Central environment
• Validate the actual deployment artifact set
• Add required comment-based help
• Add failOnAppVersionDowngrade to the environment schema

[Copilot]

Copilot review overview

🟡 Changes recommended

The check can fail environments that the existing deployment action intentionally skips, and the documented settings sources are inaccurate.

Review effort: Balanced
Findings: 1 · 1

Open (2)

• Preserve CI/CD skip semantics when AuthContext is absent · New
• Align documented settings sources with ReadSettings behavior · New

Resolved since last review (2)

• Downgrade check runs before custom deployment scripts
• Test apps are incorrectly included in downgrade validation

[Copilot]

Copilot review overview

🟡 Changes recommended

The action declares Publish support but does not handle the standard device-code authentication flow.

Review effort: Balanced
Findings: 1

Open (1)

• Handle device-code authentication in Publish action checks · New

Resolved since last review (2)

• Preserve CI/CD skip semantics when AuthContext is absent
• Align documented settings sources with ReadSettings behavior

[Copilot]

Copilot review overview

🔵 Needs a closer look

The pre-check excludes test apps that the deployment can publish, leaving a documented partial-deployment scenario unprotected.

Review effort: Balanced
Findings: None

Resolved since last review (1)

• Handle device-code authentication in Publish action checks

Previously missed (1)

In code that hasn't changed since last review

Validate test apps using the resolved deployment setting

Actions/​CheckDowngrade/​CheckDowngrade.ps1:83

This forces test apps out of the pre-check even when the resolved deployment setting enables them. Deploy.ps1 uses the original setting and publishes those test apps, so a downgraded test app can still be attempted after the check passes, allowing the partial-deployment scenario this pre-check is meant to prevent. Preserve includeTestAppsInSandboxEnvironment so every app selected for publishing is validated, and update the test/documentation that currently codifies the exclusion.

[Copilot]

Copilot review overview

🟢 Approval recommended

The opt-in behavior is implemented consistently and adequately tested, with only a non-blocking release-note clarification identified.

Review effort: Balanced
Findings: None

Previously missed (1)

In code that hasn't changed since last review

Reference repository/environment setting instead of action input

RELEASENOTES.md:3

This release note points users to the action input, but the generated CI/CD workflows hard-code that input to true; users opt in through the repository/environment setting instead. Please name the setting here so the configuration guidance matches the workflow and Scenarios/settings.md.

[Copilot]

Copilot review overview

🟡 Changes recommended

The release note incorrectly states that project-subfolder settings can enable the feature.

Review effort: Balanced
Findings: 1

Open (1)

• Clarify setting scope to repository and environment overrides · New

[Copilot]

Copilot review overview

🟢 Approval recommended

The implementation, workflow integration, tests, schema, and documentation consistently support the opt-in downgrade policy.

Review effort: Balanced
Findings: None

Resolved since last review (1)

• Clarify setting scope to repository and environment overrides

[Copilot]

Copilot review overview

🟡 Changes recommended

The separate precheck has a deployment race and can fail environments that the Deploy action would intentionally skip.

Review effort: Balanced
Findings: 2 · 1

Open (3)

• Enforce downgrade policy at publish time to prevent TOCTOU bypass · New
• Enforce downgrade policy at publish time to prevent TOCTOU bypass · New
• Apply deployment eligibility gates before checking installed app versions · New

[Alexander Holstrup (aholstrup1)]

A few smaller comments but otherwise looks good to me. Thanks for contributing! 🚀

[Alexander Holstrup (aholstrup1)]

We also have a deploy step in PublishToEnvironment.yaml. We might need to do something similar there

AL-Go/Templates/Per Tenant Extension/.github/workflows/PublishToEnvironment.yaml

Lines 152 to 163 in ba1b347

	- name: Deploy to Business Central
	id: Deploy
	uses: microsoft/AL-Go-Actions/Deploy@main
	env:
	Secrets: '${{ steps.ReadSecrets.outputs.Secrets }}'
	with:
	shell: ${{ matrix.shell }}
	environmentName: ${{ matrix.environment }}
	artifactsFolder: '.artifacts'
	type: 'Publish'
	deploymentEnvironmentsJson: ${{ needs.Initialization.outputs.deploymentEnvironmentsJson }}
	artifactsVersion: ${{ github.event.inputs.appVersion }}

[Alexander Holstrup (aholstrup1)]

Personally, I'm not a huge fan on PowerShell embedded in the yaml files like this. I'm wondering if we could just check if failOnAppVersionDowngrade is true as the first thing inside the CheckDowngrade action. If it is false, then we just exit.