Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release drafter pulls tag number from package.json automatically #5085

Merged
merged 14 commits into from
May 10, 2024

Conversation

jmuzina
Copy link
Member

@jmuzina jmuzina commented May 7, 2024

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.

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
Copy link

@jmuzina jmuzina force-pushed the release-drafter-auto-tag-number branch from 72aafa0 to e92d85a Compare May 7, 2024 18:59
@jmuzina jmuzina changed the title WIP: Release drafter pulls tag numberr from package.json automatically WIP: Release drafter pulls tag number from package.json automatically May 7, 2024
@jmuzina jmuzina self-assigned this May 7, 2024
@jmuzina
Copy link
Member Author

jmuzina commented May 8, 2024

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 jmuzina marked this pull request as ready for review May 8, 2024 15:13
@jmuzina
Copy link
Member Author

jmuzina commented May 8, 2024

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.

@jmuzina jmuzina requested a review from bartaz May 8, 2024 15:19
@jmuzina jmuzina changed the title WIP: Release drafter pulls tag number from package.json automatically Release drafter pulls tag number from package.json automatically May 8, 2024
shell: bash
run: |
set -e
echo "version_number=$(jq -r '.version' package.json)" >> $GITHUB_OUTPUT
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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/

# See https://github.com/release-drafter/release-drafter?tab=readme-ov-file#action-inputs for more
tag: "v${{ steps.get_version.outputs.version_number }}"
name: "v${{ steps.get_version.outputs.version_number }}"
version: "v${{ steps.get_version.outputs.version_number }}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)?

Copy link
Member Author

@jmuzina jmuzina May 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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:

Screenshot 2024-05-08 at 1 39 52 PM

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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 }}"

Copy link
Member Author

@jmuzina jmuzina May 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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 :)

Screenshot 2024-05-08 at 3 03 30 PM

Copy link
Contributor

@bartaz bartaz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@bartaz bartaz merged commit 4109529 into canonical:main May 10, 2024
5 checks passed
@jmuzina jmuzina deleted the release-drafter-auto-tag-number branch June 5, 2024 16:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants