[Idea] Allow disabling the CheckForUpdates job

[frottke]

Idea Description

Allow organizations to disable the CheckForUpdates job when AL-Go updates are managed centrally outside of the repository.

Context:

We are using AL-Go across multiple repositories and manage AL-Go updates centrally through our own template and governance process.

In the current AL-Go templates, the CI/CD workflow includes a separate CheckForUpdates job. This job checks whether AL-Go system file updates are available. The documented behavior also states that every CI/CD pipeline checks for updates to AL-Go system files.

While reviewing the documentation and current settings, I could not find a supported setting that disables this update check completely for repositories where AL-Go updates are managed externally.

For organizations that already manage AL-Go updates through another controlled rollout process, running CheckForUpdates on every workflow execution does not provide additional value.

Proposed solution

Introduce a setting that allows repositories (or organizations) to disable the CheckForUpdates job entirely, for example:
{ "disableCheckForUpdates": true}

The default should remain unchanged, so repositories continue to check for AL-Go updates unless they explicitly opt out.

When the setting is enabled:

• CI/CD and other generated workflows should not create or run the CheckForUpdates job.
• The manual Update AL-Go System Files workflow should remain available.
• Existing default behavior should remain unchanged for repositories that do not set this option.

Benefits

Organizations with central AL-Go governance

Some organizations update AL-Go system files through a central template, internal approval process, or scheduled rollout. For these environments, the automatic per repository update check duplicates an already managed process.

Self-hosted runners

The CheckForUpdates job consumes runner capacity that could otherwise be used by other workflows. Across many repositories, this adds up and can become a noticeable resource consumer.

GitHub-hosted runners

Every execution consumes GitHub Actions minutes. When update management is already handled externally, these executions generate costs without providing additional value.

Additional thoughts

I completely understand that checking for AL-Go updates is a recommended default behavior and helps many users stay current.
This suggestion is specifically aimed at organizations that:

• manage AL-Go updates centrally,
• have their own governance process for rollouts,
• and would prefer to trade automatic update detection for reduced runner usage and lower costs.

Note: AI only helped me phrase this text. The thoughts and ideas behind it are my own.

Contribution (Optional)

• I would be open to contributing to this idea (implementation, documentation, testing, etc.)