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

V1.2.1 release notes #161

Merged
merged 2 commits into from
Feb 22, 2022
Merged

V1.2.1 release notes #161

merged 2 commits into from
Feb 22, 2022

Conversation

brrygrdn
Copy link
Contributor

@brrygrdn brrygrdn commented Feb 21, 2022

Highlights:

  • Check the PR author instead of the Action Actor so failed fetch-metadata workflows can be retried, thanks @mwaddell!
  • Catch up on our dependency updates 😅

What's Changed

Full Changelog: v1.2.0...v1.2.1

@brrygrdn brrygrdn requested a review from a team as a code owner February 21, 2022 21:13
@@ -1,6 +1,6 @@
{
"name": "dependabot-pull-request-action",
"version": "1.1.1",
"version": "1.2.1",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

v1.2.0 does exist, the package.json just didn't get bumped as our versioning is done via Releases.

I added a script wrapper for npm version we use on another action to make this a little smoother.

Copy link
Member

Choose a reason for hiding this comment

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

Oops that was my bad. Nice catch!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I only caught it as I'd left updater-action at v0.0.0 through about six releases 😬

@brrygrdn brrygrdn force-pushed the v1.2.1-release-notes branch from 686a140 to cf742d5 Compare February 22, 2022 12:50
@brrygrdn
Copy link
Contributor Author

Updated to include #150 which I missed in yesterday's pass.

Copy link
Member

@landongrindheim landongrindheim left a comment

Choose a reason for hiding this comment

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

Looks good to me! I had a question about an implementation detail, but I think this is shippable 😄

case "${o}" in
p)
patch_level=${OPTARG}
(( patch_level == 'major' || patch_level == 'minor' || patch_level == 'patch'))
Copy link
Member

Choose a reason for hiding this comment

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

I wasn't familiar with the double parentheses construct before this 😄

Could you explain to me what effect this has on the script? It look like a check to see whether the patch_level is supported, but I'm having a hard time reasoning about the impact of the check on the script.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is really just a defensive catch on avoiding passing a garbage argument into NPM. It also acts as a filter on arguments we don't use/permit, like prepatch.

It does mean we also prevent you actually specifying the version number to use by hand, but I consider that kind of YAGNI as in that scenario you are kind of off-script on how we work so the rest of the automated steps maybe don't help.

new_version=$(npm version "${patch_level}" --no-git-tag-version)
git checkout -b "${new_version}"-release-notes
git add package.json package-lock.json
git commit -m "${new_version}"
Copy link
Member

Choose a reason for hiding this comment

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

usually we have commit as a separate step when bumping versions to double check for errors.
I notice you don't push the branch here, but maybe we should keep the existing no-commit behavior?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, that's a good point. My reasoning for going ahead with the commit here is that we're essentially just augmenting npm version patch which goes the commit and adds a tag, where we'd prefer a release branch for review first.

Since the package changes are explicitly checked in without anything else added, this feels like a safe assumption where little can go wrong. In dependabot-core, we hold the actual checkin as there's always the chance the Changelog script we wrote ourselves misfires for example 🤔

fi

new_version=$(npm version "${patch_level}" --no-git-tag-version)
git checkout -b "${new_version}"-release-notes
Copy link
Member

Choose a reason for hiding this comment

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

should we first checkout/fetch main?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good question, I went back and forth on that.

I decided to punt on it on the assuming that the user could be releasing from a release/vX branch in future and if something went wrong with the checkout/fetch we'd have to be careful to catch it which felt like scope creep.

Copy link
Member

@Nishnha Nishnha left a comment

Choose a reason for hiding this comment

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

Left some comments about the bump-version script, but the release notes LGTM

@brrygrdn brrygrdn merged commit 2354b3f into main Feb 22, 2022
@brrygrdn brrygrdn deleted the v1.2.1-release-notes branch February 22, 2022 19:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants