Add a workflow for creating release PR's. This way we don't have to do
it locally, and we guarantee the `npm` version used to generate the
version bump is consistent and stays in-sync with the repo instead of
whatever the dev happened to have on their local computer.
Over in
https://github.com/dependabot/fetch-metadata/pull/360#discussion_r1196155497,
I noticed that bash was complaining about this script:
```bash
bin/bump-version: line 9: ((: patch_level == 'major' || patch_level == 'minor' || patch_level == 'patch': syntax error: operand expected (error token is "'major' || patch_level == 'minor' || patch_level == 'patch'")
```
I started to dig into it, but the `while` loop isn't needed, the `case`
statement felt unecessarily complex so I simplified it to use an `if`
statement.
I also changed the argument from a flag-based argument to simple ordered
argument, as again it seemed simpler and it matches the style of the
bump version script over in `dependabot-core` so it's easier for
engineers working across repos. If we later have additional flags, we
can always switch it back later.
Lastly, I found `patch_version` confusing given that `patch` is a
specific value that can be used, so I renamed it to `version_type`.
There's a chicken-and-egg scenario where we don't have the release notes
to include in the version bump PR until we create a GitHub release...
but we don't want to publish the release until the commit bumping the
version actually lands.
The last few times I've cut a `fetch-metadata` release, I've been
surprised how I always forget the intricate dance to navigate this
chicken-and-egg.
I don't think the juice is worth the squeeze... no one really looks at
the changelog notes in the PR, and if in fact having the release notes
two different places introduces a risk of drift because both the PR
description and the git tag for the release can be edited later on...
only the commit history is actually immutable. So if either is edited
w/o editing the other, they're out of sync.
The odds of that are low--we rarely edit release notes--but still life
is simpler if we merely point the commit/PR description at the URL for
the release notes and manage those in a single place.
This also lets us script creating the PR, which is one less thing to do
manually.
Add a `skip-verification` (boolean) option:
- If `true`, the action will not validate the user or the commit verification status
- Defaults to `false`
Allows for scenarios where users want to add or amend commits on the Dependabot PR, and those commits will not come from the :dependabot: user.
There's a fair bit of discussion on this use case and also why this isn't the default behavior, see:
* https://github.com/dependabot/fetch-metadata/pull/336
* https://github.com/dependabot/fetch-metadata/issues/332
While running a release, at this point in the instructions I was on the `v1.3.5-release-notes` branch.
So `git pull` isn't guaranteed to pull updates on `main` etc.
Since we're going to checkout the release tag, a `fetch` is all we need here.
I saw "locally" and thought I had to do this on my laptop and couldn't do this in a codespace for some reason...
But I tested and turns out a codespace is just fine, so remove mention of "locally"
Hi, and thanks for this action! :)
Just some changes in the documentation, at the beginning we use `dependabot-metadata` id on `use: dependabot/fetch-metatada` step, but then it changes to `metatadata` only.
