[Bug]: Workflow names contain leading spaces breaking CLI usage

[SteveKrisjanovsD365]

AL-Go Bug Report: Workflow names contain leading spaces breaking CLI usage

AL-Go version

v8.2

Describe the issue

Many AL-Go workflow files have names that begin with a leading space character, making them incompatible with GitHub CLI (gh) workflow commands. This breaks automation scripts and CLI-based workflows.

Affected workflows in AL-Go AppSource template:

• CI/CD (space before CI/CD)
• Publish To Environment (space before Publish)
• Create release (space before Create)
• Create Online Dev. Environment (space before Create)
• Test Current (space before Test)
• Deploy Reference Documentation (space before Deploy)
• Increment Version Number (space before Increment)
• Test Next Major (space before Test)
• Test Next Minor (space before Test)
• Publish To AppSource (space before Publish)
• Update AL-Go System Files (space before Update)

Not affected (no leading space):

• Add existing app or test app
• Create a new app
• Create a new performance test app
• Create a new test app
• Pull Request Build
• Troubleshooting
• _Build AL-Go project

The inconsistency suggests this was unintentional.

Why this is a problem

1. GitHub CLI incompatibility

The gh CLI tool is the official GitHub command-line interface and is widely used for automation. When workflow names contain leading spaces, CLI commands fail:

# This fails:
gh workflow run "CI/CD" --ref main

# Error:
# could not find any workflows named CI/CD

# This works, but is unintuitive:
gh workflow run " CI/CD" --ref main

Users must discover through trial and error that workflows have hidden leading spaces. The GitHub web UI provides no visual indication that spaces exist in workflow names.

2. Breaks automation scripts

DevOps scripts that trigger AL-Go workflows programmatically must hardcode the leading space:

# Fragile - space is invisible in code
gh workflow run " Publish To Environment" --ref epic/hotfix `
    -f environmentName=UAT `
    -f appVersion=latest

If AL-Go later fixes the workflow names (removes spaces), all automation scripts break.

3. Inconsistent with GitHub conventions

GitHub's own workflows and examples do not use leading spaces in workflow names. AL-Go's inconsistency with platform conventions makes the framework harder to learn and use.

4. No visual indication

The leading space is invisible in:

• GitHub Actions UI
• Workflow run logs
• gh workflow list output (appears as normal indentation)
• Code editors (easy to accidentally remove during edits)

Users have no way to know the space exists without reading the YAML source files directly.

Steps to reproduce

1. Create an AL-Go for GitHub AppSource repository using v8.2 template
2. Install GitHub CLI (gh)
3. Authenticate: gh auth login
4. List workflows: gh workflow list
   • Observe output shows workflows with apparent leading spaces
5. Attempt to trigger CI/CD workflow:

   gh workflow run "CI/CD" --ref main

6. Observe error: could not find any workflows named CI/CD
7. Try with leading space:

   gh workflow run " CI/CD" --ref main

8. Observe workflow triggers successfully

Expected behavior

Workflow names should not contain leading or trailing whitespace. This aligns with:

• GitHub's workflow naming conventions
• CLI tool expectations
• Standard software naming practices

Expected workflow names:

• CI/CD (no space)
• Publish To Environment (no space)
• Create Release (no space)
• etc.

Actual behavior

Workflow YAML files define names with leading spaces:

Example from .github/workflows/CICD.yaml:

name: ' CI/CD'

Example from .github/workflows/PublishToEnvironment.yaml:

name: ' Publish To Environment'

Example from .github/workflows/CreateRelease.yaml:

name: ' Create release'

The space character is intentional in the YAML source but serves no functional purpose and breaks CLI compatibility.

Impact on users

Real-world scenario

A development team uses AL-Go for continuous deployment. Their DevOps pipeline includes:

1. Developer merges code to epic branch
2. CI/CD script automatically triggers "Publish To Environment" workflow via gh CLI
3. Script fails with "could not find any workflows named Publish To Environment"
4. Developer spends 30+ minutes debugging
5. Developer discovers leading space exists through trial and error
6. Developer updates all automation scripts to include invisible leading space
7. Future AL-Go updates may break scripts if spaces are removed

This wastes developer time and reduces confidence in AL-Go automation.

Affected use cases

• CI/CD pipelines: Automated workflow triggering via GitHub CLI
• Release automation: Scripts that orchestrate multi-step release processes
• Environment management: Scripts that deploy to multiple environments sequentially
• Integration testing: Workflows that trigger AL-Go builds from external systems

Additional context

Comparison with standard GitHub workflows

GitHub's own workflow examples:

name: CI
name: Deploy to Production
name: Release

AL-Go workflows:

name: ' CI/CD'
name: ' Publish To Environment'
name: ' Create release'

GitHub does not use leading spaces in any official examples or documentation.

Why leading spaces may have been added

Possible original intent:

• Visual separation in GitHub UI workflow list (but this doesn't work - spaces are invisible)
• Sorting/grouping workflows alphabetically (but this is fragile and doesn't work as intended)

Neither use case justifies breaking CLI compatibility.

Suggested fix

Remove leading spaces from all AL-Go workflow names:

Before:

name: ' CI/CD'

After:

name: 'CI/CD'

This change should be applied to:

• AL-Go for GitHub AppSource template
• AL-Go for GitHub PTE template
• All AL-Go system workflow files

Breaking change considerations

This is technically a breaking change for users who have hardcoded the leading space in automation scripts. However:

1. The current behavior is already broken (doesn't work with CLI)
2. Most users likely don't use CLI triggering due to this bug
3. The fix aligns with platform conventions
4. Users can easily update scripts (remove space from workflow name string)

Recommended migration:

1. Document the change in AL-Go release notes
2. Provide clear before/after examples
3. Update AL-Go documentation to show correct workflow names
4. Consider adding workflow name validation to AL-Go template linter

Verification after fix

After removing leading spaces, verify:

gh workflow list
# Should show: CI/CD, Publish To Environment, etc. (no leading spaces)

gh workflow run "CI/CD" --ref main
# Should succeed without requiring leading space

Related issues

This issue is separate from but related to:

• Workflow input logging (separate issue filed)
• False positive SUCCESS when EnvironmentCount=0 (issue [Bug]: Publish To Environment workflow does not log user inputs and reports false success when environments are skipped #2147)

All three issues stem from AL-Go workflows not following standard GitHub/PowerShell/CLI conventions and best practices.

[spetersenms]

Hi @SteveKrisjanovsD365, thanks for your concern.

The reason we have spaces in some workflow names is for sorting, to make important workflows appear first in the list, so this is an intended design choice.

Regarding running these programmatically, I just did a test and running
gh workflow run "CI/CD" --ref main
Worked for me. Could you perhaps test again? If that does not work for you, please provide the full error message you see.

[SteveKrisjanovsD365]

Thank you for the update.

This issue (and my other issues I recently posted, plus one more I'm creating today) are the result of anthropic Claude identifying these edge cases (I'm currently piloting an agentic-driven DevOps workflow and Claude noticed the peculiar inconsistent naming of the workflows).

Algo as I learned over the past two years scales very poorly as our saas repo footprint grows in both size and complexity, and the whole thing is just unmanageable to handle manually when everything is in constant flux (version changes, environments constantly being added and removed, stale secrets etc etc).

I will record into Claude's memory "this is by design" and it will handle this edge case and not chew on it again and again. It won't like it (lmao) but I understand your need to do that if string characters are the only way to sort workflow actions (weird decision on github's part - a dedicated sequence numeric would be better than using string sorts)

[SteveKrisjanovsD365]

@spetersenms To follow up -- my previous comment didn't fully convey the big picture. For teams running automated DevOps workflows, programmatic \ calls are the norm, not the exception. An AI agent or CI script has no awareness that leading spaces exist in workflow names unless it first runs \ and dynamically parses the output on every invocation. That's non-trivial overhead that compounds across every workflow in every repo. The broader documentation gap this represents -- alongside the related ghTokenWorkflow SHA bypass and the Publish To Environment false positive success -- is covered in my comment on #2151. The common thread across all three is that the behaviour is intentional but undocumented anywhere a developer or automated tool would think to look first.

[SteveKrisjanovsD365]

@spetersenms

If the algo system files contained a named map list of what the real action names are (kind of like a dictionary) it would be extremely helpful for agentic DevOps.

Understood that GitHub doesn't allow specifying actions by sequence #, but I think there are solutions to this problem you're not exploring

[aholstrup1]

@SteveKrisjanovsD365

Could you share again how you repro this issue? Running gh workflow run "CI/CD" --ref main works just fine for me. Both if I run it manually, or if I tell GH Copilot CLI or Claude Code to trigger a CI/CD for me.

[SteveKrisjanovsD365]

@aholstrup1 The repro is version-dependent, which is why it works on a fresh test. The leading space appears in the workflow `name:` field of repos whose AL-Go system files haven't been updated to the latest version. On those repos, `gh workflow list` shows ` CI/CD` (with a leading space) -- not `CI/CD`. Running `gh workflow run "CI/CD"` fails with "could not find any workflows named CI/CD". Running `gh workflow run " CI/CD"` (with the space) succeeds.

It doesn't affect the GitHub Actions UI because the UI sorts and displays by workflow ID, not by name. It only bites programmatic tooling -- `gh` CLI, scripts, and AI agents that invoke workflows by name. An agent that was working fine against a fresh repo will silently fail against a repo one AL-Go version behind.

The ask isn't a bug fix since you've confirmed this is by design. It's a docs update. The AL-Go CLI usage examples and self-hosted runner documentation should note that workflow names may contain leading spaces depending on the AL-Go system file version installed, and that `gh workflow list` (or the workflow ID) is more reliable than the name for programmatic invocation.

[SteveKrisjanovsD365]

@aholstrup1 this was one of my suggestions to make everyone happy (in addition to the ALGO team fixing up the docuementation)

#2150 (comment)