Skip to content

Conversation

alex-ter
Copy link
Contributor

@alex-ter alex-ter commented Aug 3, 2025

If we hit the fuzzing timeout, it means no crashes happenened, therefore it makes no sense to treat it as a workflow failure.

"timeout" returns an exit code 124 when this happens, and by default the Github runners treat non-zero ones as a failure.

Change the logic to convert the exit code 124 to 0 (success) and pass everything else (legitimate failures) through.

Tested via GH actions in my fork:

Closes #5244.

If we hit the fuzzing timeout, it means no crashes happenened,
therefore it makes no sense to treat it as a workflow failure.

"timeout" returns an exit code 124 when this happens,
and by default the Github runners treat non-zero ones as a failure.

Change the logic to convert the exit code 124 to 0 (success)
and pass everything else (legitimate failures) through.

Closes intel#5244.

Signed-off-by: Alex T. <[email protected]>
@alex-ter alex-ter force-pushed the alex-ter/gh5244-fuzz-better-timeout-handling branch from 0b05c7a to fe3b9ab Compare August 5, 2025 19:07
@alex-ter
Copy link
Contributor Author

alex-ter commented Aug 5, 2025

Rebased onto main to fix the mypy and black check failures.

@alex-ter
Copy link
Contributor Author

alex-ter commented Aug 5, 2025

The Linux test failure looks like something spurious, doesn't it? The same thing happens in my other PR #5257, but in the "3.10" check.

[...]
FAILED test/test_source_epss.py::TestSourceEPSS::test_parse_epss - sqlite3.OperationalError: database is locked
FAILED test/test_parsers.py::TestParsers::test_parser_env_test_0001 - sqlite3.OperationalError: database is locked
FAILED test/test_helper_script.py::TestHelperScript::test_parse_filename[libsndfile-1.0.25-12.el7.x86_64.rpm-libsndfile-1.0.25] - sqlite3.OperationalError: database is locked
[...]

@terriko
Copy link
Contributor

terriko commented Aug 7, 2025

This might be related to me having re-run the cache job and it maybe hadn't been finished before I started these tests. I'm going to re-run the failing ones and see. But I agree that it's not related to this PR.

@alex-ter
Copy link
Contributor Author

alex-ter commented Aug 8, 2025

Thank you. Passing now, could you please re-run those on #5257 too?

Copy link
Contributor

@terriko terriko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's get this merged. thank you!

@terriko terriko merged commit 3639196 into intel:main Aug 20, 2025
31 of 35 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ci: tweak fuzzing config to report success when interrupted by timeout
2 participants