This only happens when the label workflow runs in pull_request context
*and* from within nixpkgs (not a fork). This is the case for dependabot
updates.
(cherry picked from commit 979687958f)
Since all github-scripts need to be written in commonjs, we now default
to it by not setting package.json. Support from editors for .js files is
slightly better than .cjs. To still allow using module imports in the
test runner script, we trick node into loading the script itself as a
module again via `--import ./run`.
(cherry picked from commit d11eba1e1d)
This just moves things around to use less specific naming - `labels` is
only *one* script that can potentially be run locally while still being
written in github-script. Later, we can add more.
(cherry picked from commit 6f6c625026)
Pagination via cursor is required above 10k items. To do so, we store
the current cursor as an artifact and read it back in in the next
scheduled run.
(cherry picked from commit 06a88df620)
We already tried to fix this case earlier, but didn't account for all
cases: A scheduled workflow can also encounter a pull request with
failed PR workflow. This failure doesn't need to be in the Eval part, so
artifacts could *still* be available. To make sure PRs always get
rebuild labels, just ignore the status condition. Either the artifact is
there, or it is not.
(cherry picked from commit 3be9e2afc1)
The `page` number is 1-based, but the remainder might very well be 0.
This lead to not looking at the 100 oldest PRs, ever.
(cherry picked from commit 10c63e5117)
The previous implementation had two problems:
- When switching from /search to /pulls, we disabled the additional GET
on each single pull request - which causes no test merge commit creation
for all PRs. This means, merge conflicts will not actually be detected.
- By using `item` in the pull-request triggered case, this goes back to
`context.payload.pull_request`, which is the state *at the beginning* of
the workflow run. But this renders our "let's wait 3 minutes before
checking merge_commit_sha" logic void. While we wait for 3 minutes, we
still use the *old* value afterwards...
Just making the extra request every time simplifies the logic and solves
both problems.
(cherry picked from commit 59ac9479e4)
It's necessary to use a combination of different endpoints here, because
the /search endpoint only allows fetching the first 1000 items and will
fail with a higher page number (11+). On the flip side, the /pulls
endpoint doesn't allow counting the total number of results, so we can't
calculate the required page number with its response.
Putting both together should work, though.
(cherry picked from commit 579bfd48da)
This should make sure that the timer is cleaned up, no matter what. This
didn't seem to be the case before, where it would still be stuck
sometimes, when throwing an error somewhere.
(cherry picked from commit ddf3480d49)
When running in a pull_request context, the labels job is part of the
currently running workflow - which will never have succeeded, yet.
Apparently it could be failed already, so in this case we take *any*
workflow run, no matter its state.
(cherry picked from commit ed1fc4c6b3)
To set the stale label properly, we need to consider the right timeline
events only - and their respective relevant timestamps.
(cherry picked from commit d5072dd344)
Instead of approximating how many requests we can still make and hoping
the best that concurrent jobs won't break the bank, we can just work
with the actual limits. By updating regularly, we make sure that
concurrent jobs are taken into account. We always keep a reserve of 1000
requests to make sure *any* non-labeling jobs using this app will always
succeed.
This will allow us to easily backfill labels across multiple days,
especially taking the increased rate limit for the app into account.
With this, we should get up to 11.5k requests per hour in.
(cherry picked from commit 24e7e47c91)
This gives us a much higher rate limit of 12.5k requests per hour. If
the app is not available, we fallback to the regular `github.token`.
This can happen when testing in forks without setting up an app.
(cherry picked from commit acc1c0ae59)
Some jobs purposefully only run on certain base or head branches. By
centralizing the logic, parts of it can easily be re-used later. Also,
this gives them an explicit name and thus makes them easier to
understand.
(cherry picked from commit 7763be5a80)
This will give us a better idea about:
- Which jobs use the most API calls and can possibly be made more
efficient.
- Which rate limits apply exactly to which tokens.
(cherry picked from commit 356bf98a32)
Instead of deleting each label separately and then making another call
to add new labels, this replaces all labels at once, thus saving API
calls in some cases. Also, the labels are now managed in object-style
compared to the array-style before. This allows putting all the
knowledge about each label into a single place instead of in multiple
places. For example, the rebuild labels had to be special cased in the
workflow before - and the nix code to compare had to match that. Also,
the approval labels had to be considered in the `before` and `after`
phases.
The next commit shows how easy it is to add a new label now.
(cherry picked from commit 5b5b18c875)
When we made the switch from eval.yml to pr.yml we adjusted the labels
job as well - but didn't take into account that we also need to deal
with old PRs at the same time.
Here, we fallback to another API request to get a run for eval.yml when
we can't find one for pr.yml.
(cherry picked from commit d00d3190d6)
First data shows, that we're unlikely to need more than 250 within an
hour of regular activity. Once this is empty, we'll need to wait until
the next hourly refill - thus, we'll rather set this a bit higher to be
on the safe side.
The hourly limit is at 5000 and we peaked around 3500, so far. We'll
certainly have to look into reducing API calls, but this should still
work out for now.
(cherry picked from commit 8e1f869261)
When we switched to a scheduled workflow, we also changed these lines to
take the labels directly from the pull request list we iterate over. At
the time it saved us an API request. Meanwhile, we have introduced
throttling to the workflow and this causes a potential race condition:
When the scheduled or manually triggered workflow is kicked off and
empties its reservoir of API requests it might be blocked to wait up
to.. an hour! If this happens, the labels taken from the pull request
list might already be outdated at the time the workflow continues. This
would cause some labels to be reset to their original state, which could
be wrong if, for example, another push has happened in the meantime.
This will have a much bigger impact after the next commit, where *all*
labels are set every time, thus the `before` part must be accurate.
Fetching the current labels right before managing them reduces this risk
significantly.
(cherry picked from commit 9581b0c55b)
When the job is run with the pull_request trigger for validation of
changes to the workflow itself, we need to run everything that can be
run without privileges - but not more.
We tried to do so for the three actions/labeler steps, but failed to set
up the condition correctly. We also need to exit early for our
JavaScript based labeler, just before making the mutation requests.
(cherry picked from commit 8ab44fec37)
The overall idea is to use names short enough to fit into the status
checks list without shortening. This change mostly happened in the
commits before, here we just follow the same pattern for the remaining
workflows.
(cherry picked from commit c08b86e962)
Those two workflows bundle all the main jobs in two event-specific
wrapper workflows. This enables us to do two things later on:
- Synchronize the merge commits between most of the jobs run in a PR.
- Create a single "required" job to be targeted by GitHub's "required
status checks to pass" feature.
(cherry picked from commit 959eed1f2a)
This should prevent us from hitting API rate limits, even when we run
huge manual jobs. It just takes a bit longer.
(cherry picked from commit 114b4fcf48)
This will give us much quicker approval labeling, but still need much
less resources than before, when we ran on every PR comment.
(cherry picked from commit 656b53b0dd)
This can still be manually dispatched for testing in forks, but it's
entirely useless to keep running it on schedule.
Also removing the "skip treewide" condition, which was a left-over and
removed everywhere else already. We don't want to skip any jobs,
especially not when considering required status checks.
(cherry picked from commit 075dc097a3)
Due to a type mismatch, maintainer approvals were never counted as such.
The API returns integers for the user IDs, but the JSON file has strings
as object keys.
(cherry picked from commit 25a0ee0817)
We don't need to handle the differently named artifacts in a special
way, because they have been expired anyway. But, we must handle the case
to not cause the job to fail.
(cherry picked from commit 5343c50acd)
Printing the URL to the PR in the logs allows clicking on it directly in
the GitHub runner logs for easy reference.
(cherry picked from commit 022bbfd663)
