-
-
Notifications
You must be signed in to change notification settings - Fork 2
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
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 |
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.
lgtm
move changelog&version check to pre-commit and to a separate CI job that skips on skip-release label
Remaining quirks:
--allow-future
if 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-future
as 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.