Shared Github Action workflow for `semantic-release` dry-run to preview next version on PRs

[adamstankiewicz]

Most of our JS repos use semantic-release to release to NPM, which handles semantic versioning based on commit types. While the rest of the non-JS repos have also conformed to standard commit types (e.g., feat, fix, etc.), only a small subset of commit types will actually trigger a release to NPM:

• fix
• feat
• perf

Any other commit types (e.g., chore) does not trigger an NPM release with the default semantic-release configuration. This makes sense, though, as not every commit should trigger a release.

That said, it would be helpful for our JS repos to have a way to indicate to engineers who author/review PRs which version, if any, will be released by semantic-release based on the commit type(s) used in the branch. This would give an extra sanity check to ensure merging a PR will have the intended outcome regarding NPM releases.

Some repos have attempted to include a step in their CI workflows to output the results from a dry-run of semantic-release.

1. Working example in frontend-enterprise (source), though this is a monorepo managed by Lerna, which uses semantic-release behind-the-scenes.
2. Non-working example in paragon (source), using vanilla semantic-release. Results in the following error: This run was triggered by a pull request and therefore a new version won't be published.

AC

• [ ] Add new Github Action workflow file to https://github.com/openedx/.github/blob/master/workflow-templates/ to run a dry-run of semantic-release to preview what version (if any) would be released after merging a given PR.
• [ ] Ideally, this workflow could add/update a comment to the PR with what version (if any) would be released upon merge based on the PRs commits.
• [ ] Enable the CI workflow on JS repos that release via semantic-release (intentionally not include frontend-enterprise here because it uses Lerna and has a working solution already). Sampling of repos:
  • [ ] @edx/frontend-build
  • [ ] @edx/frontend-platform
  • [ ] @edx/paragon
  • [ ] @edx/browserslist-config
  • [ ] @edx/frontend-component-header
  • [ ] @edx/frontend-component-header-edx
  • [ ] @edx/frontend-component-footer
  • [ ] @edx/frontend-component-footer-edx

[ishahroz]

Following are some of the observations I came across while working on this issue:

• By default, semantic-release gives an option to detect semantic changes on any PR and if changes detected, possibly output next package version and changelogs only in the console using the command-line parameter --dry-run (same workflow as mentioned earlier in the paragon example). But a set-back is, there is no official support or workaround that will help us in writing custom Github Action workflow template (as per our need) and thus, outputting detailed changelogs and next package-version as a comment on any PR (what is required in our case), by just alone relying on the battery-packed option (dry-run).
• To give more clarification on this point, there is an active discussion managed by semantic-release authors to introduce this use-case feature sometime (in response to request by other developers). While there has been no follow-up by maintainers for some time, other open-source contributors have gathered to provide un-official workaround that closely matches to our need. I'll be discussing 2 widely-accepted implementations below.
• As a response to this open issue, this solution provides an option to add/update comment on PR branch to preview release notes. While considering this option, we should also consider the facts there has been no activity since an year now and there is an open issue that highlights how this solution is failing to preview release notes when force-pushing on given PR branch.
• Another available option is quite simple, that will just export variables like the next release version, to be later used in the workflow. This option is a recent one, more maintained one and we can see more users vouching for this. But still, we have to combine support for create/update comments on the PR (our requirement) and also design more meaningful release messages.

Verdict: While these un-official options exist, an official support with proper inputs and outputs would be even more appreciated. Plus, official support is highly likely to be most regularly maintained by open-source community (lesser chances of bugs and improved security as well). For now, we can stick one of 2 above-discussed options. Looking forward to discuss it more.

cc: @adamstankiewicz

[adamstankiewicz]

@ishahroz Great investigation! An officially supported solution to this problem seems like its desired by the community; it'd be fantastic if there was an official solution. The primary goal of this is to help PR authors aware of the next version to be released, not so much previewing release notes, etc. I'd say the release notes preview specifically is a nice-to-have, where only the next version to be released is a must.

It seems that the last suggestion could be worth exploring to see if we could get it to work. Should we try enabling it in Paragon and/or any other repos? I'm not too concerned around the creating/updating comments on the PR with this solution because I believe we have some prior art for how to manage such behavior.

[arbrandes]

+1 for semantic-release-export-data!

@ishahroz, have you been able to test it already?

[arbrandes]

@abdullahwaheed, checking status: it looks like this was set to blocked. Care to give us a short update? What is this blocked on?

[Mashal-m]

Hey, I have explored this package, but there's no luck when it comes to triggering dry runs within PR. I have asked the owner of this package, and here is what he replied. Other than that I have implemented this package in my personal project built from scratch, but dry run is not running there as well => PR

[arbrandes]

It seems like semantic-release-export-data won't do the job, then. Thanks for looking into it, @Mashal-m.

Any objections to following this particular suggestion (the one based on @semantic-release/exec)? I feel like I've seen somebody try this in a repo, but I forget which one.

[Mashal-m]

feat: config semantic release work around openedx/frontend-component-header#341

Hey @arbrandes, I have tried this suggestion as well, but it is not helping either. You can have a look at PR.

[arbrandes]

@Mashal-m, have there been any findings since last August? Do we want to continue pursuing this?