CI: Prevent duplicate CI runs #1733
Conversation
For what it's worth, we never do this in this repo (without going through a PR, anyway). But we do sometimes have long-lived branches or experimental forks, and it would be nice to avoid CI churn on those. |
| on: | ||
| push: | ||
| branches: | ||
| - master |
There was a problem hiding this comment.
We might also want 0.29.x (and other version branches), what do you think @apoelstra?
There was a problem hiding this comment.
On those branches, can we run regular CI except the 1.41 tests, because those typically break soon after release, and it's annoying to backport cargo update commands. Similarly we'd want to disable clippy and fmt, which drift over time.
I think this'll be a bit more complicated, so I'll move to merge this PR and we can do that stuff in a later one.
There was a problem hiding this comment.
I also think that such a change wouldn't actually take effect unless we backport it to the release branches.
There was a problem hiding this comment.
Yes, that is correct. We would need to backport to any branches that want these changes applied.
There was a problem hiding this comment.
I think we could just run with locked dependencies, so not cargo update commands need to be backported. fmt and clippy could be tested with pinned versions.
|
Ah, I think I understand now where the duplication is -- when we do pull requests, this triggers a CI run both on the tip of the PR branch (the "push" job) and on the merge commit (the "pull request" job). We don't want to do this. If we wanted to CI-check individual commits, we could do that, but we should do it on purpose (and not do the full CI matrix, just whatever we want for bisection) (and actually do it on all the commits, not just the tip). |
Closes #1726
This will prevent duplicate CI runs when merging an internal branch into master.
You can opt-in to a non-master branch CI by using the prefix given.