ci: update publish-release workflow for release automation

[ndoschek]

What it does

Resolves GH-16314

• add is_patch_to_previous input to support patching previous release branches, with input validation
• clarify release_type input documentation
• fetch full git history to support accurate versioning
• split publish steps: separate steps for latest and previous patch publishing
• submit a pull request with the package updates using the eclipse-theia-bot account

Contributed on behalf of STMicroelectronics

Some notes:

• I saw the initial attempts to this workflow (Automated release publishing #13399)
• As we have a successful workflow to publish next versions, I would like to achieve that also for the release publishing.
• And we could benefit from the provenance attestation when publishing via the workflow (as we already have for the next builds)

How to test

• I did test runs: https://github.com/eclipse-theia/theia/actions/workflows/publish-release.yml
• The first one tests the input validation
• Final test run
  • planned to fail to avoid publishing packages)
  • Resulting package update PR: Release v1.65.3 - Package updates #16438

Follow-ups

x

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Contributed on behalf of STMicroelectronics

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[ndoschek]

Hi @jfaltermeier,
As mentioned in the description, I would like to move forward with the publish automation, ideally, I could test this workflow already publish the next path release for 1.65.x (see #16405).
Would be great if you could have a look if you can spot anything critical (especially the part with the PR vs. commit I mentioned in the description).
Thanks in advance!

[msujew]

As of yesterday, npm changed their auth token policy. Instead of rotating the tokens every 90 days (which is very annoying, since we always need to create a helpdesk issue for that), shouldn't we just enable this repo as an OIDC token provider?

[ndoschek]

Thanks, I totally agree! As discussed in today's dev meeting, I've created a follow up: #16434

[jfaltermeier]

Hi @ndoschek, first of all this looks very good and I believe it should work.

Regarding the commit vs PR approach:

Using
https://api.eclipse.org/git/eca/status/91f7ee68fc1931687ce38fbaf5d703f9/ui
for [email protected]
does not return a user account, so I think the ECA validation will fail for these commits.

I understand that we will have to force-push some more changes anyway, but the first commit core: update re-exports for v${VERSION} is probably fine already.
I guess it would be easy to forget about this commit and leave it unchanged.

With a PR, the ECA validation would at least downvote if anything is wrong.

I don’t know if it would also be possible to sign an ECA for a bot user, which might be the nicest solution.

[ndoschek]

Thanks @jfaltermeier, I hadn't considered the ECA validation, but that makes total sense and as we use a similar flow for ide-snap publishing I think this is a good solution!

I've updated the workflow to create a PR again.
(In the meantime, I accidentally tested the NPM publishing step with the provenance flag, seems to work fine: https://www.npmjs.com/package/@theia/core?activeTab=versions 😉)

I also did another test run for the workflow, and the resulting PR looks good from my point of view. This should already help streamline the release process a bit, and now we have NPM provenance enabled as well.

Here’s the test run and the corresponding PR:

• Test run: https://github.com/eclipse-theia/theia/actions/runs/18502369171/job/52722352117 (planned to fail to avoid publishing packages)
• Resulting test PR: Release v1.65.3 - Package updates #16438

[jfaltermeier]

Thanks, LGTM