Closed chmouel closed 5 months ago
Attention: Patch coverage is 61.53846%
with 5 lines
in your changes are missing coverage. Please review.
Project coverage is 64.13%. Comparing base (
28178ab
) to head (cf35b5f
). Report is 1 commits behind head on main.
Files | Patch % | Lines |
---|---|---|
pkg/pipelineascode/match.go | 58.33% | 4 Missing and 1 partial :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
/lgtm
/lgtm
We were always getting the first one of the pipelinerun, i thought the filtering was already done and it would always be only one PipelineRun but we re-fetch everything on resolve.Resolve, so redoing the filtering properly.
Improve e2e to make sure it handles this properly to explicit test the proper PipelineRun.
Refactor a bit the gitea tests for GitOPS commands to be in its own file. g# 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).