The action was originally designed for a use case where there will only be a single sketches reports workflow artifact. Due to a change in the "actions/upload-artifact" GitHub Actions action, it became necessary to add the capability for the "arduino/report-size-deltas" action to be able to consume reports from multiple artifacts (https://github.com/arduino/report-size-deltas/pull/78).
The "Upload test sketches report artifact" GitHub Actions workflow is here updated to produce multiple test data artifacts in order to allow the "Run integration tests" workflow to provide coverage for the new capability.
As was previously the case, one of the artifacts uploaded by the workflow contains multiple sketches report files in order to provide test data necessary to continue providing coverage for the <=actions/upload-artifact@v3 single artifact system. Even though the produced test data (multiple artifacts, with multiple reports in a single artifact) would not occur under real world usage, it is the cleanest way (the alternative being to create and maintain separate copies of the system implemented in the report-target-pr branch for each use pattern) to provide effective integration test coverage.
The action was originally designed for a use case where there will only be a single sketches reports workflow artifact. Due to a change in the "actions/upload-artifact" GitHub Actions action, it became necessary to add the capability for the "arduino/report-size-deltas" action to be able to consume reports from multiple artifacts (https://github.com/arduino/report-size-deltas/pull/78).
The "Upload test sketches report artifact" GitHub Actions workflow is here updated to produce multiple test data artifacts in order to allow the "Run integration tests" workflow to provide coverage for the new capability.
As was previously the case, one of the artifacts uploaded by the workflow contains multiple sketches report files in order to provide test data necessary to continue providing coverage for the <=
actions/upload-artifact@v3
single artifact system. Even though the produced test data (multiple artifacts, with multiple reports in a single artifact) would not occur under real world usage, it is the cleanest way (the alternative being to create and maintain separate copies of the system implemented in thereport-target-pr
branch for each use pattern) to provide effective integration test coverage.