This checks for _any_ delta in the git repo, not just the `dist/`
directory. Any change should fail CI until it's either committed or
added to `.gitignore`.
Additionally, I clarified the script name/code slightly to explain why
it's needed/handled separately from checking for uncommitted files.
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.
