chore: add manual build trigger

[SimenB]

Description

Allowing us to manually trigger a run of the update job

Motivation and Context

Staring at

due to #2341 (comment)

Testing Details

Example Output(if appropriate)

Types of changes

• Documentation
• Version change (Update, remove or add more Node.js versions)
• Variant change (Update, remove or add more variants, or versions of variants)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Other (none of the above)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING.md document.
• All new and existing tests passed.

[PeterDaveHello]

Maybe we should extend jobs.build.if to ensure the workflow only runs on main when triggered via workflow_dispatch?

This helps avoid running repo scripts + secrets from a non-main branch.
 
Currently it's if: github.repository_owner == 'nodejs', we could change it to:
 

jobs:
  build:
    if: github.repository_owner == 'nodejs' && github.ref_name == 'main'

[PeterDaveHello]

@nschonni You're right that schedule only runs on the default branch, but workflow_dispatch can be triggered on a selected ref (branch/tag). This may lead to executing repo scripts from a non-main ref in a context where secrets are available, so extending the if guard to main could be a sensible security step.

[PeterDaveHello]

By the way, with workflow_dispatch added, this workflow would also be runnable manually alongside the existing schedule. Adding concurrency could help prevent overlapping runs racing on the same updates (e.g., duplicate PRs or conflicting pushes).

concurrency:
  group: automatic-updates
  cancel-in-progress: false

[MikeMcC399]

The workflow is supposed to run every 15 minutes:

docker-node/.github/workflows/automatic-updates.yml

Lines 3 to 5 in 55e8617

	on:
	schedule:
	- cron: "*/15 * * * *"

In practice it seems that GitHub Actions is throttling the frequency or dropping queued jobs.

https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule says:

The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.

So it would be convenient to have a workflow_dispatch trigger here for occasions like now when you know there is a release pending, including musl build availability, and the the workflow has not picked it up yet.

[MikeMcC399]

Actually I just realized that isn't necessary, since you can just re-run a previous job. (I just did that.)