ci: run publish only when the nightly check finds changes

[Danielku15]

Note

AI-authored disclosure (alphatab-ai-authored-v1)

Portions of this content were authored by an AI agent. The agent has read
AGENTS.md and the human submitter accepts responsibility for
compliance with the rules in that document.

Issues

No issue: this changes only the build and publishing setup (CI infrastructure), not alphaTab's behavior. The maintainer explicitly granted the exception to the accepted-issue rule.

Proposed changes

Problem

The scheduled Publish workflow runs every night. On days without functional commits, the build jobs are skipped, and GitHub reports skipped jobs as success. As a result the run history was mostly green, and real publish failures were easy to miss. For example, the npm token expired and publishing failed on six of seven nights from 2026-10-06 to 2026-10-12. Those failures sat between green no-op runs.

GitHub has no neutral result for a workflow run, and run-name can't change after the run starts. So the fix is to separate the runs that check for changes from the runs that publish.

New Nightly workflow (nightly.yml)

• Takes over the schedule (10 0 * * *).
• Runs nightly-check for web, dotnet and kotlin in one job. The change detection in nightly.mts is unchanged.
• Only if at least one platform has changes, it starts Publish with gh workflow run and passes which platforms to build. It uses the built-in GITHUB_TOKEN with actions: write. Runs started by GITHUB_TOKEN via workflow_dispatch are allowed to start other workflows, so no extra token is needed.

Publish workflow (publish.yml)

• Can now only be started manually or by Nightly; the schedule moved to Nightly.
• New inputs: web, dotnet and kotlin (each on by default) select the platforms, and force publishes all web packages instead of only the ones changed in the last 26 hours. dry_run still forces every selected platform to build.
• The workflow file name stays publish.yml, so the npm trusted-publisher entries still match.
• alpha <run_number> versions keep increasing, just in smaller steps, because Publish now only runs when something changes.

Reusable workflows (~publish_web.yml, ~publish_dotnet.yml, ~publish_kotlin.yml)

• Their check jobs are removed; each one is now just the build job. release.yml already passed force: true, so releases are unchanged.

Result

• Every Publish run is a real publish attempt: green means published, red means failed.
• Nights without changes appear only as short Nightly runs.

Behavior change for manual runs

When Publish is started by hand, it no longer checks for changes first. dotnet and kotlin build and publish whenever they are selected. Web still publishes only the packages changed in the last 26 hours, unless force is set.

Verification

• All five workflow files pass the GitHub Actions schema check (@action-validator/cli).
• Running npm run nightly-check -- --platform <web|dotnet|kotlin> --force false locally prints has_changes=... for each platform, which is the output Nightly reads.
• Not verified yet: the Nightly → Publish dispatch on GitHub. A workflow_dispatch workflow can only be started once it exists on the default branch, so this can only be tested after merge.

Follow-ups after merge

1. Start Nightly manually and confirm it starts Publish with the expected platforms, or ends without starting it when nothing changed.
2. Optionally start Publish manually with dry_run to check the new inputs.

Checklist

• I consent that this change becomes part of alphaTab under its current or any future open source license
• This PR is linked to an accepted issue (see above): maintainer-granted exception, infrastructure only
• Changes are implemented
• New tests were added: none. This only changes CI workflows; see Verification above.
• I have read AGENTS.md if an AI helped draft any part of this PR

AI authorship disclosure

• No AI agent authored any part of this PR (description, code, tests, or commit messages)
• An AI agent contributed to this PR. The AI-authored disclosure block
  (alphatab-ai-authored-v1) is present at the top of this body, and I have
  personally reviewed every change and can explain each one

Further details

• This is a breaking change
• This change will require update of the documentation/website