-
Couldn't load subscription status.
- Fork 793
[CI][Benchmarks] do not build and run E2E test on benchmark only changes #20414
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
Conversation
4063e84 to
6354502
Compare
e0304a2 to
6498e08
Compare
39bbc5d to
6d60be9
Compare
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.
Pull Request Overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
|
@intel/dpcpp-devops-reviewers , please review |
|
FYI, disabling extra CI jobs, when only benchmark scripts are changed will be removed in: #20439 @lslusarczyk, pls consider removing the first commit |
This contains also the refactor. I'm ok with reverting my change once @intel/dpcpp-devops-reviewers will accept #20439. Since this change is so minimalist I'd like to have it merged ASAP to not run this long CI right now. Then we have time to work and merge #20493 without hurry.
Let's just do merge will with squash joining these two commits. |
| toolchain_artifact: sycl_linux_default | ||
| e2e_binaries_artifact: e2e_bin | ||
| e2e_binaries_preview_artifact: e2e_bin_preview | ||
| e2e_binaries_artifact: ${{ contains(needs.detect_changes.outputs.filters, 'nonbench') && 'e2e_bin' || '' }} |
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.
i don't really like the detect_changes here, i would prefer benchmarking_only was a boolean param that we could check here, and if this workflow was called with the benchmarking_only var we always skip tests regardless of the file. we could need a seperate workflow call for benchmarking (which we probably already have?)
fyi @intel/dpcpp-devops-reviewers
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.
This is a change made to be as short as possible, to ease your review of its correctness and have CI working faster right now. @lukaszstolarczuk is refactoring benchmarking CI in #20439 There is a separate workflow there so this change (if we go with this patch before #20439) will be reverted.
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.
If your team will commit to addressing my/Andrei's feedback in that PR I'm fine to merge this given it seems important to your team.
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.
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.
I would want to see if @aelovikov-intel is okay with this as well before merging
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.
Ok. I'm also OK with closing this PR without merging if we are able to review @lukaszstolarczuk change soon. @aelovikov-intel, please decide.
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.
We don't touch detect_files workflow frequently enough to be confident that '!devops/scripts/benchmarks/**' does the right thing, so let's focus on the #20439 instead.
|
Have you considered just disabling pre-commit workflows and creating a separate just for benchmarks? |
I see this is done this way in #20439. I tried to make a very short change to have it working. However if you can look at that bigger patch now/soon, then we can close this PR without merging. |
|
Decided to focus on #20439 |
Also