Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly improves the Allure report integration by enabling the extraction and upload of run-level failure logs from Allure container files. This ensures that critical setup and teardown failures, which are not associated with specific test cases, are properly captured and reported. Additionally, the internal API client has been refined for better extensibility and request identification, and the codebase has undergone minor refactoring for improved structure. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces support for run-level failure logs from Allure reports by parsing *-container.json files, which is a valuable addition for capturing setup and teardown failures. The implementation is robust, including comprehensive new tests that cover various scenarios and edge cases. The pull request also includes helpful refactorings, such as generalizing the API header utility and making the CLI version a pre-computed constant. Documentation in both README.md and CLAUDE.md has been updated accordingly. Overall, this is a high-quality contribution with no issues found.
| withHttpRetry( | ||
| withHeaders(withBaseUrl(fetch, baseUrl), { | ||
| Authorization: `ApiKey ${apiKey}`, | ||
| 'User-Agent': `qas-cli/${CLI_VERSION}`, |
There was a problem hiding this comment.
Added qas-cli/<version> user-agent header, which might help in debugging future issues
| { | ||
| "name": "qas-cli", | ||
| "version": "0.5.0", | ||
| "version": "0.6.0", |
There was a problem hiding this comment.
Bumped version for run level logs support
| 3. **Test case marker in name** - Marker in `name` field (same `PROJECT-SEQUENCE` format as JUnit XML) | ||
|
|
||
| Only Allure 2 JSON (`*-result.json`) is supported. Legacy Allure 1 XML files are ignored. | ||
| Only Allure JSON result files (`*-result.json`) are supported. Legacy Allure 1 XML files are ignored. |
There was a problem hiding this comment.
There is also Allure 3, so we shouldn't specifically mention Allure 2
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4db32dc4e6
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| const fixtures = [...(container.befores || []), ...(container.afters || [])] | ||
| for (const fixture of fixtures) { |
There was a problem hiding this comment.
Skip test-scoped containers when building run-level logs
Allure container files are not run-global by default: the format describes a fixture container that points back to the affected test result(s) via children. This loop promotes every failed/broken before/after to runFailureLogs without checking whether the container belongs to one or more concrete tests, so a normal pytest function-scoped fixture failure will now be uploaded both on the testcase (from the matching *-result.json) and again as a run-level log. In suites that use per-test fixtures, that makes a single-test failure look like a run-wide outage.
Useful? React with 👍 / 👎.
| if (includeStdout && statusDetails.message) { | ||
| message += `<pre><code>${escapeHtml(stripAnsi(statusDetails.message))}</code></pre>` | ||
| message += `<p>${escapeHtml(stripAnsi(statusDetails.message))}</p>` |
There was a problem hiding this comment.
Preserve preformatted Allure failure messages
This changes statusDetails.message rendering for every Allure testcase from a preformatted code block to a paragraph. Multiline assertion messages and diff-style output are common in Allure reports; wrapping them in <p> collapses newlines and indentation, so failed tests that only populate message now lose most of their structure in QA Sphere. Keeping the previous <pre><code> formatting avoids that regression in debuggability.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Message should be a small text summary, ideal for <p>. The documentation also confirms the same - the short text message to display in the test details, such as a name of the exception that led to a failure. The error detail should be in trace, which already uses <pre><code>
| if (includeStdout && statusDetails.message) { | ||
| message += `<pre><code>${escapeHtml(stripAnsi(statusDetails.message))}</code></pre>` | ||
| message += `<p>${escapeHtml(stripAnsi(statusDetails.message))}</p>` |
This fixes https://github.com/Hypersequent/tms-issues/issues/2340