V1.2.1 release notes #161
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,28 @@ | ||
| #!/bin/bash | ||
|
|
||
| usage() { echo "Usage: $0 -p [major | minor | patch]" 1>&2; exit 1; } | ||
|
|
||
| while getopts "p:" o; do | ||
| case "${o}" in | ||
| p) | ||
| patch_level=${OPTARG} | ||
| (( patch_level == 'major' || patch_level == 'minor' || patch_level == 'patch')) | ||
| ;; | ||
| *) | ||
| usage | ||
| ;; | ||
| esac | ||
| done | ||
|
|
||
| echo "$patch_level" | ||
|
|
||
| if [[ -z "${patch_level}" ]]; then | ||
| usage | ||
| fi | ||
|
|
||
| new_version=$(npm version "${patch_level}" --no-git-tag-version) | ||
| git checkout -b "${new_version}"-release-notes | ||
|
There was a problem hiding this comment. should we first checkout/fetch main? There was a problem hiding this comment. 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 |
||
| git add package.json package-lock.json | ||
| git commit -m "${new_version}" | ||
|
There was a problem hiding this comment. usually we have commit as a separate step when bumping versions to double check for errors. There was a problem hiding this comment. Yeah, that's a good point. My reasoning for going ahead with the commit here is that we're essentially just augmenting 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 🤔 |
||
|
|
||
| echo "Branch prepared for ${new_version}" | ||
There was a problem hiding this comment.
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_levelis supported, but I'm having a hard time reasoning about the impact of the check on the script.There was a problem hiding this comment.
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.