Closed zakisk closed 1 month ago
Attention: Patch coverage is 72.13115%
with 17 lines
in your changes missing coverage. Please review.
Project coverage is 65.16%. Comparing base (
d87fe97
) to head (528f8ed
). Report is 5 commits behind head on main.
Files with missing lines | Patch % | Lines |
---|---|---|
pkg/metrics/metrics.go | 62.85% | 9 Missing and 4 partials :warning: |
pkg/reconciler/emit_metrics.go | 84.61% | 4 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
/test
/test
/test
Thank you @zakisk Few comments and also can you add e2e to test both the metrics
@savitaashture about adding E2E tests, I will need to do some extra work, like adding an ingress to access metrics endpoint in tests, metrics endpoint doesn't return response in JSON so need to figure out a consistent way to find metrics values in response so that it will be reusable across all PAC metrics E2E tests, so I am thinking doing that in a separate SRVKP. CC: @chmouel
/lgtm
Thank you
added new metric to show sum of durations all pipelineruns have taken in seconds. added docs and adjusted test accordingly
https://issues.redhat.com/browse/SRVKP-6226
Changes
Submitter Checklist
[ ] ๐ Please ensure your commit message is clear and informative. For guidance on crafting effective commit messages, refer to the How to write a git commit message guide. We prefer the commit message to be included in the PR body itself rather than a link to an external website (ie: Jira ticket).
[ ] โฝ Before submitting a PR, run make test lint to avoid unnecessary CI processing. For an even more efficient workflow, consider installing pre-commit and running pre-commit install in the root of this repository.
[ ] โจ We use linters to maintain clean and consistent code. Please ensure you've run make lint before submitting a PR. Some linters offer a --fix mode, which can be executed with the command make fix-linters (ensure markdownlint and golangci-lint tools are installed first).
[ ] ๐ If you're introducing a user-facing feature or changing existing behavior, please ensure it's properly documented.
[ ] ๐งช While 100% coverage isn't a requirement, we encourage unit tests for any code changes where possible.
[ ] ๐ If feasible, please check if an end-to-end test can be added. See README for more details.
[ ] ๐ If there's any flakiness in the CI tests, don't necessarily ignore it. It's better to address the issue before merging, or provide a valid reason to bypass it if fixing isn't possible (e.g., token rate limitations).