Repository navigation
[QA] Rename connections report to "Meshery: Connections Lifecycle" - #83
Conversation
Rename the `connections` awesome-plugin report's display name to "Meshery: Connections Lifecycle" and decouple that display name from the testGroup filter key. Previously one constant (CONNECTION_LIFECYCLE_GROUP) drove both the reportName and the isTestGroup filter, so the two could not be renamed independently. Split out CONNECTION_REPORT_NAME for the display name; the filter still keys on the "Connection Lifecycle" testGroup value the tests emit, so the match is unchanged. The plugin key stays `connections`, so the published URL (https://qa.meshery.io/connections/) is unchanged. Nesting: the "Meshery: " prefix presents this as a Meshery report in the dashboard's report picker. Allure 3 reports are flat peer plugins (the config `plugins` map has no parent/child relation; the awesome plugin's only hierarchy is intra-report groupBy), so a name prefix is the supported way to signal that this report is a subset of the main Meshery report - documented inline. Signed-off-by: marblom007 <158522975+marblom007@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Renames the connections Allure awesome-plugin report display name to “Meshery: Connections Lifecycle” while keeping the testGroup=Connection Lifecycle filter key unchanged.
Changes:
- Introduced a new constant for the report display name (
CONNECTION_REPORT_NAME) decoupled from thetestGroupvalue constant. - Updated the
connectionspluginreportNameto use the new display-name constant. - Expanded inline documentation clarifying the filter key vs. display name and the “Meshery: ” prefix rationale.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // The connection report's DISPLAY name, decoupled from the filter key above so | ||
| // the report can be renamed without breaking the testGroup match. The | ||
| // "Meshery: " prefix presents it as a Meshery report in the dashboard's report | ||
| // picker (lightweight nesting under the main Meshery report) - Allure 3 reports | ||
| // are flat peer plugins with no parent/child nesting in the config, so the | ||
| // prefix is the supported way to signal the relationship. See the connections | ||
| // plugin block below. | ||
| const CONNECTION_REPORT_NAME = "Meshery: Connections Lifecycle"; |
There was a problem hiding this comment.
Fixed. The full nesting rationale now lives only in the connections plugin block; the CONNECTION_REPORT_NAME constant just carries a short pointer to it, so the two can no longer drift.
|
Warning Review limit reached
Next review available in: 46 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. 📝 WalkthroughWalkthroughThe connections report now uses a dedicated display-name constant. The existing lifecycle group remains the ChangesConnection report naming
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Address review (Copilot): the '"Meshery: "' prefix / flat-reports rationale was explained on the CONNECTION_REPORT_NAME constant and repeated in the connections plugin block. Keep the full rationale only in the plugin block (where reportName is used) and leave a short pointer on the constant, so the two cannot drift. Signed-off-by: marblom007 <158522975+marblom007@users.noreply.github.com>
|
@copilot review |
What
Rename the
connectionsawesome-plugin report's display name to "Meshery: Connections Lifecycle" inallurerc.mjs, and decouple that display name from thetestGroupfilter key.Why
project=Meshery) and CLI (project=mesheryctl) lanes, keyed on thetestGroup=Connection Lifecyclelabel. The captain asked to present it as a subset of the main Meshery report rather than a peer.CONNECTION_LIFECYCLE_GROUP) drove both thereportNameand theisTestGroupfilter, so the two could not be renamed independently. This splits outCONNECTION_REPORT_NAMEfor the display name; the filter still keys on the"Connection Lifecycle"testGroupvalue the tests emit, so the match is unchanged.Stable surface
connections-> the published URL https://qa.meshery.io/connections/ is unchanged.isTestGroup "Connection Lifecycle"+ the transitional epic fallback).groupBy: ["client", "suite", "subSuite"]unchanged.Nesting - investigation result
Allure 3 reports are flat peer plugins: the config
pluginsmap has no parent/child relation, and the awesome plugin's only hierarchy is intra-reportgroupBy. There is no clean, supported way to nest one report under another. The "Meshery: " name prefix is the supported way to signal that this report is a subset of the main Meshery report in the dashboard's report picker; it is implemented here and documented inline. True report-under-report nesting would require folding these results into the Meshery report and losing the standalone/connections/URL, which this PR deliberately keeps stable. Whether to go further than the prefix is a product/architecture decision left to the maintainers.Verification
node --check allurerc.mjspasses.Summary by CodeRabbit
Documentation
Bug Fixes