[Bug]: Publish To Environment workflow does not log user inputs and reports false success when environments are skipped

[SteveKrisjanovsD365]

AL-Go Bug Report: Publish To Environment workflow does not log user inputs and reports false success

AL-Go version

v8.2

Describe the issue

The "Publish To Environment" workflow has two critical usability issues:

1. Does not log user-provided inputs (environment name, projects, branch) clearly in workflow run logs
2. Reports SUCCESS when nothing is published (when 0 environments match due to branch policy or other filtering)

When a deployment fails due to branch policy mismatch, the only indication is buried thousands of lines deep in verbose settings JSON dumps, making troubleshooting nearly impossible. Worse, the workflow reports a green checkmark (SUCCESS) even though it skipped all publish steps.

Current behavior:

• User triggers "Publish To Environment" workflow manually via GitHub UI
• User provides: environment name, projects list, and selects branch
• Workflow logs only show: Inputs: - environmentName = 'MyEnvironment'
• The "projects" input is NOT logged
• The selected branch is NOT logged at the input stage
• When branch policy fails, the only clue is: "Environment MyEnvironment is not setup for deployments from branch feature/my-branch" buried ~10,000 lines into the log in the settings JSON dump
• Workflow completes with: EnvironmentCount=0
• Workflow reports SUCCESS (green checkmark) even though nothing was deployed

This creates a false positive where users believe their apps were deployed to UAT/production when in reality the workflow silently skipped all publish steps.

Expected behavior

The workflow should:

1. Clearly log all user-provided inputs at the start of the workflow run
2. Report WARNING or FAILURE when 0 environments matched and nothing was published
3. Provide clear explanation of why environments were skipped

Example of proper logging:

Workflow Inputs (User-Provided):
- environmentName: MyUATEnvironment
- projects: *
- branch: feature/my-feature

Deployment Config Evaluation:
- Checking DeployToMyUATEnvironment configuration...
  - Branch policy: ["main*", "release/*"]
  - Current branch: feature/my-feature
  - Branch match: FAILED
  - Reason: Current branch does not match allowed branch patterns

Environment Resolution Result:
- Matched environments: 0
- Reason: Branch policy rejection for all matching environments
- Action: Skipping all publish steps
- Workflow Status: WARNING (or FAILURE)

Suggested workflow status behavior:

When EnvironmentCount=0 (no environments matched):

• Option 1 (Preferred): Mark workflow as FAILED with clear error message: "No environments matched the deployment criteria. Check branch policies and environment configuration."
• Option 2 (Minimum): Mark workflow as SUCCESS with WARNING annotation: "Workflow completed but no environments were published to (0 matched)."
• Current (Wrong): Mark workflow as SUCCESS with no indication that nothing was deployed

This would prevent users from believing deployments succeeded when they actually didn't happen.

Steps to reproduce

1. Set up an AL-Go for GitHub AppSource repository with v8.2
2. Configure a deployment environment in .github/AL-Go-Settings.json:

   "DeployToMyUATEnvironment": {
     "EnvironmentName": "MyUATEnvironment",
     "continuousDeployment": false,
     "Branches": ["main*", "release/*"],
     "Projects": "Project1,Project2,Project3",
     "SyncMode": "ForceSync"
   }

3. Create a feature branch: feature/test-deployment
4. Manually trigger "Publish To Environment" workflow from GitHub UI:
   • Select branch: feature/test-deployment
   • Environment name: MyUATEnvironment
   • Projects: *
5. Wait for workflow to complete
6. Check workflow logs and status

Observed:

• Logs show: Inputs: - environmentName = 'MyUATEnvironment'
• No indication of what was entered for "projects" or which branch was selected
• Branch policy failure message buried ~10,000 lines deep in settings JSON dump
• EnvironmentCount=0 (no environments matched)
• Workflow reports SUCCESS with green checkmark
• User believes deployment succeeded when nothing was actually deployed

Expected:

• Clear logging of all user inputs at workflow start
• Clear explanation of why deployment config didn't match
• Workflow should fail (or at minimum warn) when EnvironmentCount=0

Additional context (logs, screenshots, etc.)

Relevant log excerpt (current behavior)

Initialization	UNKNOWN STEP	2026-02-27T20:54:43.4224654Z Inputs:
Initialization	UNKNOWN STEP	2026-02-27T20:54:43.4307878Z - environmentName = 'MyUATEnvironment'

[... 10,000+ lines of verbose settings JSON dump ...]

Initialization	UNKNOWN STEP	2026-02-27T20:55:07.4896035Z Environment MyUATEnvironment is not setup for deployments from branch feature/test-deployment
Initialization	UNKNOWN STEP	2026-02-27T20:55:07.4919143Z EnvironmentsMatrixJson={"matrix":{"include":[]},"fail-fast":false}
Initialization	UNKNOWN STEP	2026-02-27T20:55:07.4976445Z EnvironmentCount=0
Initialization	UNKNOWN STEP	2026-02-27T20:55:07.5017595Z UnknownEnvironment=0

[Workflow completes with SUCCESS status]

Note: The "projects" input is never logged anywhere in the workflow output.

Real-world impact

This false positive success has serious consequences:

1. Deployment pipeline confidence: Users believe apps are deployed to UAT/production when they're not
2. Manual verification required: Users must manually check app versions in target BC environments after every publish workflow (defeating automation)
3. Debugging difficulty: When deployments silently fail, users waste hours grepping logs to find the buried rejection message
4. Branch policy errors: Users don't realize their branch isn't allowed until they manually read AL-Go-Settings.json

Example scenario:

• Developer merges code to epic/hotfix branch
• Developer triggers "Publish To Environment" → Cannabis365UAT
• Workflow reports SUCCESS (green checkmark)
• Developer believes UAT is updated and notifies QA team
• QA team tests and finds old version still deployed
• Developer discovers branch policy rejected epic/* branches
• Hours wasted because workflow reported success when it did nothing

Suggested fixes

Fix 1: Improve input logging (in DetermineDeploymentEnvironments action)

• Echo all user inputs at workflow start
• Log branch policy evaluation with pass/fail per environment
• Clearly state final environment count and action taken

Fix 2: Fail workflow when EnvironmentCount=0

• Check EnvironmentCount at end of DetermineDeploymentEnvironments step
• If EnvironmentCount=0, mark workflow as FAILED with error message
• Error message should explain why (branch policy, environment not found, etc.)

Fix 3 (Alternative): Warning annotation when EnvironmentCount=0

• If FAILURE is too strict for some workflows, add WARNING annotation
• Clearly visible in GitHub UI that nothing was deployed
• Better than silent SUCCESS

[spetersenms]

Hi @SteveKrisjanovsD365, thanks for your concern. I can see where you are coming from. The reason we have the current setup is because users are very split on how they want this to work. We have explored both options, but eventually chose the current one as that seemed to please most people. I can see how that does not work for everyone, so I'll explore if we can maybe add a setting to configure if you want a warning, error or nothing in situations like the one you have.