-
Notifications
You must be signed in to change notification settings - Fork 770
[CI] Run SYCL-CTS with the latest nightly #12811
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
Add a new workflow to run SYCL-CTS when new nightly build is available. This should help us to handle new failures in advance, monitor new suites and so on. To start with running only reduced scope of tests (cts_exclude_filter is big enough) on unused "debug" runner (linux+cpu).
@@ -290,6 +291,12 @@ jobs: | |||
if: inputs.tests_selector == 'cts' | |||
env: | |||
ONEAPI_DEVICE_SELECTOR: ${{ inputs.target_devices }} | |||
# FIXME: For some reason the "sub_group api" test-case is failing with | |||
# SIGSEGV while running test_all, so running each binary separately. | |||
# BTW test_all requires a lot of resources to build it, so probably it'll |
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.
Should we try per-source kernel splitting maybe?
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.
Will this improve compilation time for test_all
?
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 can't imagine other reasons for the slowdown...
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.
per-source
splitting is a default mode of splitting
target_devices: opencl:cpu | ||
tests_selector: cts | ||
install_drivers: false | ||
ref: ${{ github.sha }} |
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.
nit: isn't it the default?
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.
Looks like no, see https://github.com/intel/llvm/actions/runs/8007137309
on: | ||
push: | ||
tags: | ||
- nightly-* |
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.
Can we add manual workflow_dispatch as well? Possibly with a selectable runner/target devices.
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.
As discussed offline we can just run sycl-linux-run-tests.yml
as it has workflow_dispatch
.
.github/workflows/sycl-nightly.yml
Outdated
@@ -107,6 +107,22 @@ jobs: | |||
runner: '["Windows","gen12"]' | |||
sycl_toolchain_archive: ${{ needs.build-win.outputs.artifact_archive_name }} | |||
|
|||
sycl-cts: |
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 think we can actually merge that into the e2e matrix.
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.
441647a
Not sure what will be matrix.tests_selector
for the rest
Being tested in https://github.com/intel/llvm/actions/runs/8024711118. |
Recent intel#12811 uses generic `.github/workflows/sycl-linux-run-tests.yml` and the old implementation isn't necessary.
Recent #12811 uses generic `.github/workflows/sycl-linux-run-tests.yml` and the old implementation isn't necessary.
Add a new workflow to run SYCL-CTS when new nightly build is available. This should help us to handle new failures in advance, monitor new suites and so on.
To start with running only reduced scope of tests (cts_exclude_filter is big enough) on unused "debug" runner (linux+cpu).