Release drafter pulls tag number from package.json automatically

[jmuzina]

Done

Release drafter reads the version number from package.json and automatically populates tag and release name.

Closes WD-11112

QA

Due to the release drafter action being run on pushes to main, I tested this in my fork to avoid unnecessarily cluttering our draft releases / main commit history.

• View the release automatically created by this workflow run (ran by this action with this config)
• Verify that the version in my package.json matches the version populated into the release

Check if PR is ready for release

If this PR contains Vanilla SCSS code changes, it should contain the following changes to make sure it's ready for the release:

• PR should have one of the following labels to automatically categorise it in release notes:
  • Feature 🎁, Breaking Change 💣, Bug 🐛, Documentation 📝, Maintenance 🔨.
• Vanilla version in package.json should be updated relative to the most recent release, following semver convention:
  • if CSS class names are not changed it can be bugfix relesase (x.x.X)
  • if CSS class names are changed/added/removed it should be minor version (x.X.0)
  • see the wiki for more details
• Any changes to component class names (new patterns, variants, removed or added features) should be listed on the what's new page.

[webteam-app]

Demo

Jenkins

demos.haus

[jmuzina]

Started a PR for the upstream release-drafter to enable templating the tag number from package.json into the body of the drafted release; then I noticed by testing that the $INPUT_VERSION I was trying to implement is... already supported by release-drafter, but undocumented.

Waiting for confirmation on this, but if I'm right, then this will be good to commit to main as-is :)

[jmuzina]

Ready for review; we can use $INPUT_VERSION in the release body template without making any upstream changes. We should expect this merge to create a draft release of vanilla v4.11.0 (no SCSS updates = no version bump) that contains just this update.

[bartaz]

Sorry, I'm a bit rusty on GH actions, and they changed how to do things in the past. Is this the recommended way to store some values? Can you point me to some docs?

[jmuzina]

@bartaz Yes, this is the "new" way to set an output param for a GHA step. See some docs here: https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter

You may have seen this in the past with a slightly different syntax that was deprecated recently; maybe this looks more familiar: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

[bartaz]

Not sure if it matters, but is version expected to be a version number (just 1.0.0), or can it be anything (with v in front)?

[jmuzina]

@bartaz tag is filled into the tag field for the release. It is subject to some validation from Github (it has to be a git ref).

name is filled into the name of the release.

version is used for the body of the release (where it says "New in Vanilla v{x}").

Here's an example image where each field is different to better distinguish them:

[bartaz]

@jmuzina Thanks. So in this case v would be duplicated in the body? Because we add it both here into the version param, and then again in the template as v$INPUT_VERSION. That's why I guess we may want to put just the number of the version into version param. I also makes more sense semantically.

Suggested change

	version: "v${{ steps.get_version.outputs.version_number }}"
	version: "${{ steps.get_version.outputs.version_number }}"

[jmuzina]

@bartaz I'm glad you brought this up. It seems like release drafter is doing some sort of logic against input.tag to split off the v so that $INPUT_VERSION template has no v. Here's an example of that where you can see that inputting v4.12.1 as tag causes the tag to be resolved to v4.12.1 and $INPUT_VERSION as 4.12.1.

So, we don't need input.version at all in this case; we can just specify name for the draft release name and tag for the tag to use :)

[bartaz]

LGTM, thanks!