ci: do dry-run releases in CI #1725
Conversation
0f750ad to
82beb63
Compare
|
Won't this break down when we have changes that involve multiple crates? |
|
Yes, which is why I will set these all to "allow failure". When we do an actual release we can make sure that the relevant green checkmarks appear on release PRs. (And prior to releases, we will notice if we mess up Cargo.toml metadata.) |
82beb63 to
17cd946
Compare
|
So, currently all the CI checks are "allow failure" in the sense that Github won't stop us from merging stuff as long as there are two ACKs. But I can't figure out how to make these checks "allow failure" in the sense that the won't give us angry red Xs. |
|
Hah you had a classic Tobin brain fail, the two red x's are actually from failing CI caused by rustfmt (PR fix merged already). The release jobs are green :) |
|
@tcharding oh, cool, I'll rebase to fix that -- but I was referring to the indeteminate future, when we have dependencies set as git tags, etc., and when we get to that point in the upcoming release, we'll have red Xs related to |
17cd946 to
f2e52a4
Compare
|
Oh i get you. For me personally having red sucks because I'm inclined to start ignoring red on other PRs thinking its the same reason - I've done this before and it makes me get sloppy pretty fast. |
|
Agreed. I'm sure there's some way I can make certain checks have a yellow ! or something, but I can't find it.. |
.github/workflows/release.yml
Outdated
| @@ -0,0 +1,35 @@ | |||
| name: Release | |||
|
|
|||
| on: [push, pull_request] | |||
There was a problem hiding this comment.
Do we need this on both push and pull_request?
There was a problem hiding this comment.
Ah, no, good call. I think I should copy the on: field from #1733
|
In automation spirit of other ongoing PRs, I think we can have a script check if this PR is a release PR. There are a couple ways of doing this.
For non release PRs, it should return green mark, and for release PRs, it should fail with error. |
f2e52a4 to
829b8a1
Compare
I dunno about this. In our last release we had a hiccup because we moved the If we had a check like this, we would've noticed the mistake at the time that we made it, rather than noticing it when we opened the release PR. Obviously either case is better than noticing it after typing |
829b8a1 to
99cb83c
Compare
Will set this to "allow failure" since I think it'll fail during large parts of development, but this will be useful to avoid last-minute problems with releases.