Code scanning filters doesn't offer a drop down to filter by PR #148816
Replies: 1 comment
-
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
Product Feedback
Body
My tooling often generates code scanning alerts to PRs as opposed to branches.
Code scanning results
has a report page:There's a link that says:
View all branch alerts.
But, it isn't actually a link to a branch filter.
Instead, it's to a
pr:1 tool:check-spelling is:open
filter:That filter is wonderful. But if you visit https://github.com/check-spelling-sandbox/opentelemetry-collector-contrib/security/code-scanning directly, you'd never be able to generate that link on your own using the ui:
default search:
is:open branch:placeholder
(note that clicking the field actually leaves you with a blank field, not the visible default query which is problematic).That includes this text:
If check-spelling were run against the product that produced this page, it would say:
Anyway, there's a language filter:
There's a tool filter:
There's a branch filter (as demonstrated by the default search):
There's a rule filter:
There's a severity filter:
There's a sort thing:
And the open/closed items at the beginning also act as filters.
The
branch
filter is actually not solely a branch filter as it also offers filtering on tags. It's the logical place to put the PR list to allow filtering by PR. Especially given that filtering by PR is more or less mutually exclusive to filtering by Branch or Tag.Beta Was this translation helpful? Give feedback.
All reactions