-
Notifications
You must be signed in to change notification settings - Fork 27.7k
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] implement job skipping for doc-only PRs #8826
Conversation
That's a great idea! |
Btw this is why GitHub Actions are so cool: this is built-in |
ok, this is good now. |
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, thanks @stas00!
This among others :) the only pain point is the lack of anchors, which would be a godsend given our current YAML files. |
There is a problem with the test, which seems to skip the tests as soon as there is at least one doc file, even if code files have also been modified. #8852 gives an example of this happening. |
@sgugger, can you show me a a specific example of this behavior? Looking at PR you linked and other commits since the skip rule has been merged I don't see this happening. For example, 75f8100 has both docs and code files and it has the skip rule activated - and none of the jobs were skipped, e.g. here is one job from that PR: Thank you! p.s. while we are sorting this new one out, you don't need to comment out all the invocation of the command, just the 'circleci halt' line in the command. |
Arg, I force-pushed my rebase so we lost the commit where the problem was happening. I assure you that PR had all tests skipped except |
I totally believe you what you saw, but this must have been some edge case that I haven't accounted for and I need to see what it was. As I have shown in the 2 links in the comment above yours the rule did work correctly for a PR with 2 docs and one py file, so what you suggested that it skips as soon as there is at least one doc doesn't seem to be the case. Do you know at least what files were involved in that commit where the undesired skip has occurred? or perhaps it's still in your local branch? The logic is simple:
|
I've deleted that branch but there was only one commit with the 9 files you see in the PR. |
OK, I created a PR #8853 with the exact same files by just reverting your commit 5530299 for the sake of the test (not intending to merge it) - plus Moreover, you said:
but your commit had no doc files. Do you want to try to re-enable the rule and monitor to catch a potential edge case that you saw but we no longer know what it was? And if you run into it and I will monitor too, let's make sure to save the branch so that we could reproduce the problem. To quickly disable the skip just this line needs to be commented out: transformers/.circleci/config.yml Line 19 in dfec84d
The only tricky part with monitoring is that it won't affect older branches that weren't rebased or created after the skip was enabled. Oh and I apologize if this causes a temporary potential hurdle in normal PR process - hopefully we will sort it out quickly and overall things will be better in the long run. |
Ah, great! That helped a lot, @sgugger - Thank you for finding it! It appears to be a bug in circleCI (https://app.circleci.com/pipelines/github/huggingface/transformers/16541/workflows/17b20230-8d7c-4b36-813c-2681f2c8a977/jobs/128232) It's missing
resulting in:
and hence fails the test. (it's missing the first hash before Back to the drawing board. |
Can you think of why these few commits could be missing |
I have no idea, but if CircleCI is flaky like this, I guess we won't be able to use this to determine whether the commit contains only doc files or not... |
We still can, by checking whether But let me research first why is it not defined at times. |
Workaround: #8853 |
* implement job skipping for doc-only PRs * silent grep is crucial * wip * wip * wip * wip * wip * wip * wip * wip * let's add doc * let's add code * revert test commits * restore * Better name * Better name * Better name * some more testing * some more testing * some more testing * finish testing
Let's save some time and money. This PR:
\.(md|rst)$
files.I tested this with various types of files and it seems to do the right thing. But if we merge let's monitor that I didn't miss some use case and we end up with broken master if some CI jobs didn't run.
how it was done:
git merge-base --fork-point master
to get the commit range didn't work at all, even though that's what we use for thefixup
Makefile
target.Other suggestions I found didn't work either.
At the end I found https://circleci.com/docs/2.0/pipeline-variables/ to get the correct commit range:
and now all is good.
credits: the
circle step halt
idea comes from this blog https://yu-ishikawa.medium.com/reusable-a-circleci-command-to-halt-if-no-changed-target-files-e87c6b0af82b@LysandreJik, @sgugger