feat: add release PR workflow

[pichlermarc]

Part of the series of PRs to automate the release process.

This PR:

• adds a workflow to create release PRs using the @opentelemetrybot user
• the workflow will also update an existing PR if run so no need to check if a PR is open before running it
• the user has to choose a scope (sdk = all SDK packages, experimental and stable, experimental = all packages in experimental, all = all release packages, including API) and type (patch = bump patch version for the selected scope, minor = bump minor version for the selected scope). major is not included right now as it's not a regular enough occurrence to spend time on it.

Still missing:

• The https://github.com/open-telemetry/opentelemetry-js repo still needs to be forked @opentelemetrybot. This is tracked at REQUEST: Repository maintenance on open-telemetry/opentelemetry-js community#2188 this can actually be handled by the workflow too via gh repo fork
• automatically determining which release scope and type is required
• actually releasing the packages once the PR is merged (currently needs to be done manually via NODE_AUTH_TOKEN=<your-token-here> npm run release:publish)
• automatically creating the releases once the PR is merged (currently needs to be done by running npm run _github:draft_release:stable, _github:draft_release:experimental, _github:draft_release:api) and then publishing the created draft release

[pichlermarc]

Reviewer note: I've had trouble publishing without limiting concurrency in the past. Sometimes, it tries to publish a package while a dependency is not available yet and exits with an error. Having --concurrency 1 will take slightly longer but will avoid running into a state where only a portion of the packages are published.

[pichlermarc]

Reviewer note: If we don't have a fork on @opentelemetrybot yet and we need to release, the way to create a PR would be to set all these env vars and locally and running the npm run github:create_or_update_release_pr script above (gh CLI needs to be logged in).

For me this would be:

RELEASE_SCOPE: [any one of these values]
RELEASE_KIND: $RELEASE_SCOPE: [any one of these values]
RELEASE_PR_REMOTE: origin (the name of the remote that I usually push to)
RELEASE_PR_OWNER: dynatrace-oss-contrib (the organization that owns my fork of the repo)

You can adjust these values and run the script locally to get the same result as you'd get from running the workflow. The only dfference: instead of @opentelemetrybot it will then be your user that's opening the PR (but that still beats doing everything manually). 🙂

[trentm]

Thanks for working on automatic and documenting this!

[pichlermarc]

I just figured out we can actually use gh repo fork open-telemetry/opentelemetry-js to fork the repo to the @opentelemetrybot user, so no manual intervention by the TC is necessary for this to work. 🙂 Didn't occur to me to try for some reason when I was working on this a few weeks back.

Edit: see afb0d23, fea0e64

[trentm]

Do we only need to do this fork once, and then change this workflow? I would have thought the forking would be a one-time thing.

[pichlermarc]

We can just run the forking step every time we run the workflow, as it's just a single API call. Since the gh binary is already available, it does only add about a second to the workflow run. If the fork already exists, then this command will exit with a success code, logging that the fork already exists, effectively becoming a no-op. 🙂

Here's an example where I tested that: https://github.com/pichlermarc-sample-organization/test-release-pr/actions/runs/10147085271/job/28056647373 🙂