improve changelog/release handling#321
Conversation
…kips on skip-release label
|
also it doesn't seem to work, at least not when re-running it after adding the label. |
|
I think we've now hit my "not actually worth the trouble" threshold, let's stick with the status quo? |
|
The status quo definitely needs changing. I just realized that I forgot to undo the temporary changelog edit in #316 when releasing #317 (and I realized that... as I forgot to update the changelog in #323 before pushing (although that was a different problem of not updating the changelog at all, lel)). But I could look at making a simpler solution |
|
okay yeah there's a pretty simple way forward. Let's skip the label, and either have CI always allow Will keep pre-commit, and fix |
move changelog&version check to pre-commit and to a separate CI job that skips on skip-release label
Remaining quirks:
--allow-futureif it triggers onpush.The test file is kind of ugly now in that it both looks like a pytest file and doesn't. I should probably add some comments at the very least.
EDIT: actually, I shouldn't skip the CI job with the skip-release label - I should just make that pass
--allow-futureas well.(also the flag is somewhat opaquely named, probs time to do a proper argparse solution).
It's also not great that skip-release doesn't actually skip a release attempt, afair we just rely on pushing-the-same-version-again to twine to not do anything.