Implement the Performance API (v2/performance/metrics)

[diemol]

Description

PerformanceEndpoint was previously an empty stub (no methods at all, annotated @Unfinished). This PR fills it in with all 11 endpoints documented for the Performance API:

• getPerformanceResults(GetPerformanceMetricsParameter) — GET /v2/performance/metrics/
• getPerformanceResults(jobID) / getPerformanceResults(jobID, full) — GET /v2/performance/metrics/{job_id}/
• getTestAssertions(jobID, metricNames, orderIndex) — GET /v2/performance/metrics/{job_id}/assert/
• getTestBaseline(jobID, BaselineParameter) — GET /v2/performance/metrics/{job_id}/baseline/
• getBaselineResetHistory(jobID) — GET /v2/performance/metrics/{job_id}/baseline/reset/
• resetBaseline(jobID) — POST /v2/performance/metrics/{job_id}/baseline/reset/
• getDiscardedTests(jobID, orderIndex[, limit]) — GET /v2/performance/metrics/{job_id}/discarded/
• discardOutliers(jobID, orderIndex) — POST /v2/performance/metrics/{job_id}/discarded/
• getTestHistory(jobID, orderIndex[, limit]) — GET /v2/performance/metrics/{job_id}/history/
• getMetricRegimes(jobID, metricNames, orderIndex[, includeBaseline]) — GET /v2/performance/metrics/{job_id}/regimes/
• acknowledgeRegimes(jobID, orderIndex) — POST /v2/performance/metrics/{job_id}/regimes/acknowledge/

Since this covers every documented endpoint in the Performance API, the @Unfinished annotation has been removed from PerformanceEndpoint.

Response models live under com.saucelabs.saucerest.model.performance, and follow the field-naming/parameter-builder conventions established in #629 (the Insights endpoints). Two endpoints (GET /v2/performance/metrics/ and GET .../baseline/) have dedicated parameter builders since they combine required and optional filters; the rest take their (few, mostly required) parameters directly as method arguments, matching the pattern used elsewhere in the codebase (e.g. BuildsEndpoint.getSpecificBuild) for calls with no real optional filtering.

Motivation and Context

Closes #150 — the library exposed a PerformanceEndpoint class with zero methods, despite the Performance API being explicitly requested.

How Has This Been Tested?

• mvn test-compile — full compile of main and test sources.
• mvn test -Dtest=com.saucelabs.saucerest.unit.** — full unit suite, including new tests for both parameter builders (GetPerformanceMetricsParameterTest, BaselineParameterTest) covering toMap() serialization.
• Added a live-API integration test (PerformanceEndpointTest) for the account-wide getPerformanceResults call, following the existing pattern (InsightsEndpointTest) of exercising real endpoints against live credentials. The other 10 endpoints are scoped to a specific job_id with performance/Lighthouse data already recorded against it, which isn't something this environment can reliably provision, so I did not add live integration tests for those — happy to add them if maintainers have a fixture job available in CI.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (change which improves current code base; please describe the change)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

Screenshots (if appropriate):

N/A

Checklist

• I have read the CONTRIBUTING doc
• I have added tests that prove my fix is effective or that my feature works
• All new and existing tests passed locally
• I have added necessary documentation (if appropriate)

Further comments

Unlike the Insights API (#629), the documented Performance API surface is small and self-contained (one path prefix, 11 endpoints), so this PR implements it in full rather than a scoped subset.

🤖 Generated with Claude Code

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 33 complexity · 3 duplication

Metric	Results
Complexity	33
Duplication	3

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[diemol]

CI status: Unit Tests, Codacy, CodeQL, dependency-review, and the demo-app uploads all pass. Integration Tests currently fails, but not because of this PR — the only failing test is InsightsEndpointTest.getTestTrendsTest, which is unrelated to the Performance work here (it exercises GET /v1/analytics/trends/tests from #629). This PR's own new PerformanceEndpointTest.getPerformanceResultsTest passes.

Root cause: the live API requires interval on that endpoint and returns a 422 when it's omitted, despite the docs listing it as optional. Fix and root-cause writeup are in #631. Once that merges, rebasing this branch on main should clear the Integration Tests failure here too.