Add workflow for updating release used by start-proxy

[mbg]

This PR adds a new workflow which automates the creation of PRs that update which release is used by the start-proxy action to pull binaries of the update-job-proxy from.

Previously, I manually created PRs such as this one for that. The new workflow here creates similar ones, such as this example.

This PR currently contains a commit that adds a push trigger (limited to this branch) for testing, which should be removed before merging this PR.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Confirm the readme has been updated if necessary.
• Confirm the changelog has been updated if necessary.

[Copilot]

Pull Request Overview

This PR introduces a new GitHub Actions workflow to automate updating the start-proxy action’s release assets and opening draft PRs.

• Adds a workflow dispatch and temporary push trigger for testing
• Defines steps to replace URLs and versions in code, build, and open a PR
• Configures branch naming and GitHub permissions for the bot

Comments suppressed due to low confidence (3)

.github/workflows/update-proxy-release.yml:5

• Remove the temporary push trigger on the mbg/update-proxy-binaries branch before merging, as this is only needed for testing.

      - mbg/update-proxy-binaries # for testing

.github/workflows/update-proxy-release.yml:55

• [nitpick] Trim the leading spaces in the heredoc for pr_body so the PR description renders as normal text instead of a code block.

            This PR updates the \`start-proxy\` action to use the private registry proxy binaries that

.github/workflows/update-proxy-release.yml:44

• [nitpick] Avoid hard-coding the v2.0 prefix; derive the full release version from the RELEASE_TAG input so that future major/minor bumps don’t require patching this script.

          sed -i '' "s/\"v2.0.[0-9]*\"/\"v2.0.$NOW\"/g" ./src/start-proxy-action.ts

[esbena]

Is there prior art for doing releases like this?

I'm not a huge fan of doing text replacements in typescript files with workflow inputs...

[esbena]

What is the plan for this default value moving forward?

[mbg]

That's part of the test commit, which I noted in the PR description will be removed. So there will be no default value, and the tag input is required for the workflow_dispatch event.

[mbg]

I'm not a huge fan of doing text replacements in typescript files with workflow inputs...

Agreed, perhaps a check that the tag is in the expected format before proceeding would be good?

Is there prior art for doing releases like this?

Depends on what you are asking about specifically. This PR just automates a few steps we'd have to perform manually otherwise. The whole arrangement with how the update-job-proxy binaries are made available to the action has always been a bit temporary, but we haven't prioritised improvements here (see the linked epic).

[esbena]

Agreed, perhaps a check that the tag is in the expected format before proceeding would be good?

Yes. Let's add that in. It's also nice to have to prevent silly bugs.

Depends on what you are asking about specifically.

NP. Thanks for the extra context.

[mbg]

Yes. Let's add that in. It's also nice to have to prevent silly bugs.

Done, along with an additional check to make sure that the release actually exists. We could take this further to check that the release assets include the three expected files, but this is probably enough sanity checking in the workflow for now -- I am not expecting this to be used much. I'd only expect an increase in usage if we automate the process end-to-end, but we may well choose to store the proxy binaries elsewhere then.