Support large test result files - #134
Conversation
This is a temporary test to see if this setting will fix the test result publication failures we consistently see in Corvus.JsonSchema
Test Results1 tests 1 ✅ 0s ⏱️ Results for commit e61d7ed. ♻️ This comment has been updated with latest results. |
JamesDawson
left a comment
There was a problem hiding this comment.
Looks good - have you tried testing it with the Corvus.JsonSchema repo to see if it has the desired affected? You can point its build to use the workflow from this branch instead of main.
The CI checks here are all green so it looks fine from a backwards-compatibility perspective.
For completeness, can we also add the new largeTestResultFiles input to the 'single job' flavour of workflow.
# Conflicts: # .github/workflows/scripted-build-matrix-pipeline.yml # .github/workflows/scripted-build-pipeline.yml # actions/run-build-process/action.yml
Main restructured the publish-unit-test-result-action steps (single `files:`
input, action bumped to v2.24.0) so the original hunks no longer applied.
Reapplied `large_files: ${{ inputs.largeTestResultFiles }}` to the Linux and
Windows publish steps in both the standard and matrix scripted-build pipelines
and in the run-build-process composite action.
Also addresses the review feedback: the new `largeTestResultFiles` input is now
plumbed through the single-job workflow to the run-build-process action.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVkgD5WPoviz5LwSjNN4ge
|
Picking this up. Pushed two commits:
Default remains Still outstanding: validating against |
Code Coverage Summary Report - Linux (net8.0)Summary
CoverageTestLib - 100%
TestLib.Tests - 100%
|
Code Coverage Summary Report - Linux (No TFM)Summary
CoverageTestLib - 100%
TestLib.Tests - 100%
|
Code Coverage Summary Report - Windows (net8.0)Summary
CoverageTestLib - 100%
TestLib.Tests - 100%
|
In
Corvus.JsonSchemawe routinely saw test result publication fail because of the large.trxfiles produced in that project.The GitHub Action we're using has a
large_filessetting that avoids this problem.This change enables the use of that by default, but provides a new setting that enables the old behaviour to be reinstated. We have made the new behaviour the default because as far as we can tell, there is no behaviour change, and if there is a performance cost, it is too small for us to detect in the overall cost of a build.