@aelovikov-intel, FYI.

@aelovikov-intel, FYI.

I somewhat doubt it's the CI because the testing in #10054 finished successfully. Is it possible the drivers are bad/incompatible?

@aelovikov-intel, FYI.

I somewhat doubt it's the CI because the testing in #10054 finished successfully. Is it possible the drivers are bad/incompatible?

From the logs:

Traceback (most recent call last):
  File "/opt/get_release.py", line 19, in <module>
    release = get_release_by_tag(repo, tag)
  File "/opt/get_release.py", line 6, in get_release_by_tag
    release = urlopen("https://api.github.com/repos/" + repo + "/releases/tags/" + tag).read()
  File "/usr/lib/python3.10/urllib/request.py", line 216, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.10/urllib/request.py", line 525, in open
    response = meth(req, response)
  File "/usr/lib/python3.10/urllib/request.py", line 634, in http_response
    response = self.parent.error(
  File "/usr/lib/python3.10/urllib/request.py", line 563, in error
    return self._call_chain(*args)
  File "/usr/lib/python3.10/urllib/request.py", line 496, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.10/urllib/request.py", line 643, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 403: rate limit exceeded

Re-run doesn't have that issue.

Re-run doesn't have that issue.

Okay, but we should think about preventive cure for urllib.error.HTTPError: HTTP Error 403: rate limit exceeded error. Just let it happen and wait + re-run, doesn't sound like a good solution.

Re-run doesn't have that issue.

Okay, but we should think about preventive cure for urllib.error.HTTPError: HTTP Error 403: rate limit exceeded error. Just let it happen and wait + re-run, doesn't sound like a good solution.

FYI: I found a bug report for that issue - #8462.

Post-commit failure:

Unexpectedly Passed Tests (1):
  SYCL :: ESIMD/hardware_dispatch.cpp

For these automated Linux GPU driver updates we could run broader scope of testing on pre-commit step automatically.

Fix: #10132

For these automated Linux GPU driver updates we could run broader scope of testing on pre-commit step automatically.

I think that could be as easy as making

Condition could probably be based on contains(needs.detect_changes.outputs.filters, 'drivers_and_configs') - see

@dm-vodopyanov, @aelovikov-intel, could you clarify what testing is missing in this PR pre-commit? Don't we run ESIMD tests on GPU in all pre-commits?

https://github.com/intel/llvm/blob/sycl/sycl/test-e2e/README.md?plain=1#L34-L44

We don't test for XFAIL in pre-commit.

https://github.com/intel/llvm/blob/sycl/sycl/test-e2e/README.md?plain=1#L34-L44

We don't test for XFAIL in pre-commit.

This text doesn't say if there is any difference in XFAIL semantics between post- and pre- commits. Why does the test fail in post-commit?

Because in pre-commit we run with

and in post-commit with

So just having additional devices in the system changes the status of the test? Do you understand how broken this system is? How are developers supposed to debug issues like this?

So just having additional devices in the system changes the status of the test?

No.