test: Fix test failure due to .coverage changing during tar creation. #557
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
smoser
force-pushed
the
fix/ignore-coverage
branch
from
cda61c5
to
9d6f453
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #557 +/- ##
==========================================
- Coverage 54.24% 5.72% -48.53%
==========================================
Files 64 64
Lines 7473 7473
==========================================
- Hits 4054 428 -3626
- Misses 2728 6982 +4254
+ Partials 691 63 -628 ☔ View full report in Codecov by Sentry. |
hallyn
approved these changes
Nov 20, 2023
rchincha
approved these changes
Nov 20, 2023
rchincha
reviewed
Nov 20, 2023
This seems to be a transient failure, but is legitimate issue.
When coverage binary is being used, this test case could fail with:
# + mkdir /output
# + tar -cf /output/installer-iso.tar -C /stacker .
# tar: ./.coverage: file changed as we read it
The /stacker/.coverage file was being updated by the stacker binary
itself. This is just a race condition based on when the file gets
written to and when it was being collected by tar.
The change is just to only have tar collect the .cpio files.
Signed-off-by: Scott Moser <smoser@brickies.net>
smoser
force-pushed
the
fix/ignore-coverage
branch
from
9d6f453
to
045d32a
Compare
smoser
added a commit
to smoser/stacker
that referenced
this pull request
Nov 20, 2023
I had a pull request (project-stacker#557) that changed a single line in a single integration test. c-i reported that coverage changed: 5.72% (-48.53%) compared to a34ebfa Where a34ebfa was the previous commit. That doesn't sound right. I think what is happening is that we have multiple uploads of the coverage workflow and they're fighting. There isn't any reason to upload both anyway. Signed-off-by: Scott Moser <smoser@brickies.net>
This was referenced Nov 20, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This seems to be a transient failure, but is legitimate issue.
When coverage binary is being used, this test case could fail with:
The /stacker/.coverage file was being updated by the stacker binary itself. This is just a race condition based on when the file gets written to and when it was being collected by tar.
The change is just to only have tar collect the .cpio files.
What type of PR is this?
Which issue does this PR fix:
What does this PR do / Why do we need it:
If an issue # is not available please add repro steps and logs showing the issue:
Testing done on this change:
Automation added to e2e:
Will this break upgrades or downgrades?
Does this PR introduce any user-facing change?:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.