Ruff dependabot is too noisy and pollutes search results

[electric-coder]

I was looking for <details> and <summary> in the closed pull requests and I think dependabot reports for Ruff might be polluting the search results too much:

• Example 1: is:pr is:closed summary
• Example 2: is:pr is:closed details

When I try to open a Ruff post that's listed, there aren't actually any search results for "summary" or "details". Is it really necessary to quote&paste the "Sourced from ruff's releases" part in those posts? In the long run it will make it very hard to efficiently search for closed pull requests.

[jdillard]

@danieleades recently changed them from weekly to daily: 3190c3f

[danieleades]

Let's unpack this

I was looking for <details> and <summary> in the closed pull requests and I think dependabot reports for Ruff might be polluting the search results too much

This is an XY problem. What is it you're trying to find by filtering on <details> and <summary>?

@danieleades recently changed them from weekly to daily: 3190c3f

That's for GitHub action updates only, not for ruff. And that's the not the rate at which PRs are created, that's the rate at which dependabot checks for new releases. That would only result in more PRs if a particular GitHub action was routinely released at a rate faster than once a week. Slower than that, it results in getting PRs sooner, not more frequently.

Is it really necessary to quote&paste the "Sourced from ruff's releases" part in those posts?

to answer your actual question here- that behaviour is entirely configurable (as is the frequency and number of open dependabot PRs allowed). But it might be instructive to drill down into why you're using those tags to search and whether there's a better way to solve the underlying problem before we strip out release notes from dependabot PRs

[electric-coder]

This is an XY problem. What is it you're trying to find by filtering on <details> and <summary>?

I was trying to look for previous issues about cross-references that have targets inside closed details not opening them. Turns out it's a Firefox bug see bugzilla 1820528 and bugzilla 1873542 notice the whatwg (W3C) issue linked in the last report - apparently Chrome at one point implemented the behavior (I haven't tested it). Example of a related issue.

But it might be instructive to drill down into why you're using those tags to search

As I previously explained (see sideshowbarker's 2 answers in the whatwg post) I had to write my own JS script for Sphinx to handle this. So trying to avoid that extra work, at one point I was searching the repository for any shread of previous reports and a solution.

That's for GitHub action updates only, not for ruff. And that's the not the rate at which PRs are created, that's the rate at which dependabot checks for new releases.

This explains it! I'm still wondering if users looking at Sphinx's closed PRs might find the dependabot posts an hinderance.

whether there's a better way to solve the underlying problem before we strip out release notes from dependabot PRs

After originally posting this I realized the solution would have been to filter dependabot posts - but that didn't occur to me at the time (this whole shenanigan had taken me past the point of thinking clearly).

@danieleades recently changed them from weekly to daily:

Really 😮 ?! He did?! OK, lets spam the repository's closed PRs section 😂

@danieleades looking at it again, there are only 68 such PRs so slightly more than 1% of the closed PRs. I was just unlucky to find them all at the same time.