We now use a `long build` label to identify PRs that need the
`CI-long-timeout` label but don't have it because other PRs are
currently using it.
Let's save some CI time by failing CI whenever a PR has the `long build`
label but not the `CI-long-timeout` label.
I've also updated `triage.yml` to add the `long build` label where
appropriate. The criterion I used here was whether a CI run that skips
dependent testing will still exceed the short timeout of 60 minutes.
This leaves out formulae that regularly take a long time only due to
having a large number of dependents (e.g. `python@3.*`, `go`). I think
this is the correct thing to do to avoid having to manually remove the
`long build` label every time the `triage` workflow is run in cases
where the CI run will not actually need `CI-long-timeout` (e.g. when we
use `CI-skip-dependents`).
This is based on the suggestion from #94792.
These don't need the outcome of the dependent tests, so let's show them
earlier. It'll also make the formulae step easier to distinguish from
the dependents step in the CI log.
* autobump: track more formulae
Signed-off-by: Rui Chen <rui@chenrui.dev>
* remove dups and add more rust formulae
Signed-off-by: Rui Chen <rui@chenrui.dev>
* fix case issue for `MeiliSearch` name
* autobump: remove `dwarfutils`
Co-authored-by: Sam Ford <1584702+samford@users.noreply.github.com>
* autobump: remove `fst`
Co-authored-by: Sam Ford <1584702+samford@users.noreply.github.com>
* autobump: remove `rover`
Co-authored-by: Sam Ford <1584702+samford@users.noreply.github.com>
Co-authored-by: Sam Ford <1584702+samford@users.noreply.github.com>
This is the same change as in #94067.
In particular, I need this in order to diagnose a bottling failure for
`libxslt` which I can't reproduce locally.
I got in touch with GitHub Support about our constantly failing GraphQL
queries. They requested for the `x-github-request-id` in the response
header of any of our failed queries, so I'm adding this to try to
generate one.
I suspect this query is failing all the time these days, but can't
confirm because the query fails silently. Let's at least set a warning
when it fails so what we can check whether it did or didn't.
Creating this directory produces a `File exists` error on the
self-hosted Linux runner (cf. #90611).
There ought to be a better solution, but I have no idea what it is, so
let's unblock PRs that need the self-hosted runner for now.
* workflows/tests: limit use of `CI-long-timeout` label
The `CI-long-timeout` label is currently overused: it is almost always
added to every PR that takes longer than an hour to run, and we suffer
from long CI queues as a consequence. This defeats the purpose of having
the label in the first place.
Let's try to mitigate this by automatically removing the
`CI-long-timeout` label whenever there are at least two open PRs that
already have the label applied.
I employ a little hack to be able to use our `label-pull-requests`
action, since trying to do this with `actions/github-script` is a little
involved. An alternative to this is to use an external action such as
`andymckay/labeler`. [1] I can also look at adapting our action
properly, but this might take a while since I don't know JavaScript.
[1] https://github.com/andymckay/labeler
* Consolidate timeout label jobs
* Fail long-timeout PRs when there are too many of them
This gets around the issue of requiring a token with write permissions
to pull requests.
* Integrate long PR count into `tap_syntax` job
* Improve error message
Also, extract the maximum number of long-timeout PRs to a variable for
clarity.
sqlite is quite good at maintaining API/ABI compatibility, so there
isn't really much of a need to spend an extra two days on CI testing
recursive dependents.
Let's also fix the incorrect reference to `openssl.rb` since it's also
on the same line, and remove sqlite and rust from having the
`CI-linux-self-hosted` label automatically applied.
Submitting bug reports hasn't worked for a while because of the missing
`label`.
My editor complained about `labels` needing to be an array, so I've made
that one too. It was also complaining about the missing label property
for the checkboxes, so I guess it knows what it's talking about here.
See https://github.com/Homebrew/discussions/discussions/2526#discussioncomment-1731168
We're not particularly constrained (yet?) in our use of GitHub runners,
so we probably don't need to cut jobs short when using them. This would
be useful for PRs such as #89617 where the macOS runners finish in under
an hour, but the Linux runner requires more than an hour to complete.
Carlo Cabrera
Thierry Moisan
rui
Dawid Dziurla
Rui Chen
Bo Anderson
Issy Long
fn ⌃ ⌥
BrewTestBot