Do not check coverage in the Release multi-numa build

[ldorau]

Description

1. Do not check coverage in the Release multi-numa build
2. Unify the name of the coverage data file in the upload-artifact
   step and the coverage artifact file in the Check coverage step.
   A name of the coverage artifact file in the Check coverage step
   must be unique.

Checklist

• Code compiles without errors locally
• All tests pass locally
• CI workflows execute properly

[lukaszstolarczuk]

is it really a fix - was something broken? or just a cleanup in the names?

[bratpiorka]

is it really a fix - was something broken? or just a cleanup in the names?

fix for sporadic fails like here
https://github.com/oneapi-src/unified-memory-framework/actions/runs/12214905680/job/34076621998?pr=898

[ldorau]

is it really a fix - was something broken? or just a cleanup in the names?

@lukaszstolarczuk This patch fixes the regression introduced by the commits: 9d23a57 and 2a7a229.

[lukaszstolarczuk]

och, I see you updated the PR now with extra if debug in multinuma, which makes sense.

For GPU workflow it's still a name change only, right? no fix in "logic" needed?

[ldorau]

och, I see you updated the PR now with extra if debug in multinuma, which makes sense.

For GPU workflow it's still a name change only, right? no fix in "logic" needed?

No, in both cases it is a fix for the regression introduced by the commits: 9d23a57 and 2a7a229 because the name of the coverage data file in the upload-artifact step must be exactly the same like $COVERAGE_FILE_NAME in the Check coverage step where this file is generated.

[ldorau]

CI builds passed: https://github.com/oneapi-src/unified-memory-framework/actions/runs/12231973390
I have updated only the commit's description.

[ldorau]

@bratpiorka @lukaszstolarczuk please review

[lukaszstolarczuk]

No, in both cases it is a fix for the regression introduced by the commits: 9d23a57 and 2a7a229 because the name of the coverage data file in the upload-artifact step must be exactly the same like $COVERAGE_FILE_NAME in the Check coverage step where this file is generated.

heh, ok, thanks for clarification. The 2 commits you mentioned, introduced many changes, without the description it didn't tell me much.

So now:

1. why not use the actual variable COVERAGE_FILE_NAME? we already have it composed, don't compose it for the second time, perhaps?
2. (optional) why did it fail only randomly and sporadically? when the 2 commits were introduced they did not introduce lower coverage score...

[lukaszstolarczuk]

@ldorau, please change the base branch to the v0.10.x

[ldorau]

@ldorau, please change the base branch to the v0.10.x

Done

[ldorau]

1. why not use the actual variable COVERAGE_FILE_NAME? we already have it composed, don't compose it for the second time, perhaps?

@lukaszstolarczuk Done

[lukaszstolarczuk]

just one thing to confirm yet - I also added CONFIG_NAME in QEMU run_test.sh and it does not match with then name used in workflow (it contains multiple configs per 1 OS)

[ldorau]

just one thing to confirm yet - I also added CONFIG_NAME in QEMU run_test.sh and it does not match with then name used in workflow (it contains multiple configs per 1 OS)

It is OK.
I have checked it again and it turned out that in fact those names does not have to be the same - they have to be only unique and the coverage directories have to contain empty (of size equal 0) coverage data files.