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
[CI/CD] allow execution of CI/CD steps for PRs conditioned to PR title #12172
base: master
Are you sure you want to change the base?
Conversation
ha that's a lot of pressure Sorry, i know this is a bit of a step backwards, but are we sure that the additional complexity this introduces is worth the benefit? |
Sometimes, you really want to just check that your branch is fine on Windows (because you have weird stuff). But in general, all Ubuntu checks are done beforehand... but you know that they will be fine... so you don't want to wait them to complete. Technically, this workflow would simply be triggered to synchronize the windows-testing branch but otherwise I can keep doing it manually. EDIT: In general, we gain 2 minutes on the tests. |
@picnixz I wonder whether we could do this by matching on the source-name branch instead? (that would indirectly also ensure that people (such as me, for example) trying to fix/identify Windows-specific bugs using CI would be less likely to accidentally write into their normal development branches) |
I think that the However, we may be able to achieve the same effect by using an sphinx/.github/workflows/main.yml Line 146 in 982679e
For fairness I'd suggest adding both |
Perhaps those should be (pseudocode again): |
I'm not sure that my suggestion is feasible; I think that when a commit is pushed to a pull request branch, it is the The
( |
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.
Although my suggested alternative doesn't seem valid, I think that maintaining and additional branch for the purposes of continuous integration filtering could produce unintended confusion and complexity.
I'll continue to try to think of and feasibility-check an alternative. Could labels be used to selectively disable workflows on-next-push?
This can be done with an
I checked and every commit triggers a pull_request event. So I could have a job that conditionally run the whole matrix if the pull request branch has a specific title.
Not a good idea since not everyone can put labels. |
I think it's OK, and it might even be preferable: it's a hint to the reviewer that not all tests were run for the latest commit. That could be relevant before deciding to merge or not, for example.
It's a fairly rare use-case at the moment though, so I think that requesting triager/maintainer involvement could make sense, before using our CI to run a lot of test compute. |
Then I'll take that approach instead. Not sure if it'll be working as expected but we could always revert the commit (I mean, this one won't break master for sure !). I'll work on it today. |
I think I will try to create a real branch on Sphinx and do some PRs to check what happens. Then I will merge this branch into the real master (but first, time to eat). |
What do you think of this approach @danieleades ? |
windows-testing
branch
Possibly related (and blocking): actions/typescript-action#27 |
I also would like to know how I can have a required step that checks that the PR title does not contain any '[ci-skip-*]' strings. |
Related: #12115.