junit: switch time to zero instead of timestamp#278
Conversation
|
Warning Review limit reached
More reviews will be available in 55 minutes and 19 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Repository: openshift/coderabbit/.coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (2)
WalkthroughThis PR standardizes JUnit XML duration handling by introducing a ChangesJUnit XML Duration and Timing Standardization
🎯 2 (Simple) | ⏱️ ~8 minutes 🚥 Pre-merge checks | ✅ 14 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (14 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
The JUnit format expects the time attribute to represent the duration of a test, not the timestamp. The JUnit output from kube-compare already correctly adds the timestamp attribute as a timestamp, but then sets time to be the same. For tools which are stricter about the JUnit schema, this causes errors parsing the kube-compare output. This commit switches to always setting `time="0"` in the `testsuites`, `testsuite`, and `testcase` tags. Since the duration would not be relevant, `"0"` is chosen as a default. Alternatively, the attribute could be removed since it is optional, but since it is already present, setting it to zero works as well. Assisted-by: Cursor Signed-off-by: Kirsten Laskoski <klaskosk@redhat.com>
9fdbb71 to
5068536
Compare
|
@klaskosk: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
The JUnit format expects the time attribute to represent the duration of a test, not the timestamp. The JUnit output from kube-compare already correctly adds the timestamp attribute as a timestamp, but then sets time to be the same. For tools which are stricter about the JUnit schema, this causes errors parsing the kube-compare output.
This commit switches to always setting
time="0"in thetestsuites,testsuite, andtestcasetags. Since the duration would not be relevant,"0"is chosen as a default. Alternatively, the attribute could be removed since it is optional, but since it is already present, setting it to zero works as well.Assisted-by: Cursor
Summary by CodeRabbit
Bug Fixes