fix: improve user feedback #1875
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1875 +/- ##
=======================================
Coverage 65.74% 65.74%
=======================================
Files 178 178
Lines 13836 13836
=======================================
Hits 9097 9097
Misses 4124 4124
Partials 615 615 ☔ View full report in Codecov by Sentry. |
When PaC is used with other CIs (eg openshift-ci), it can happen that a `ok-to-test` label managed by the other CI is present. That label may persist after a change, but PaC will report the need for the latest content to be approved. This state is likely to confuse the user. In order to improve the UX, the required action is now explicitely stated in the message in the UI.
Roming22
force-pushed
the
fix/ok-to-test
branch
from
daf3002 to
0253490
Compare
|
SGTM but we probably want to have this for gitlab (at least) as well |
To be fair, I basically did a search&replace assuming the string would be consistent. I had a quick look in Let me know if I incorrectly parsed the code. |
|
yeah i checked the code and it indeend doesn't show a comment on webhook based provided when queued so we good to merge, tks |
Changes
When PaC is used with other CIs (eg openshift-ci), it can happen that a
ok-to-testlabel managed by the other CI is present. That label may persist after a change, but PaC will report the need for the latest content to be approved. This state is likely to confuse the user.In order to improve the UX, the required action is now explicitely stated in the message in the UI.
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).
If you are adding a provider feature, please fill up the following details which provider this feature supports:
(make sure to update the documentation accordingly)