ci(response): use pagination for timeline events
GitHub paginates responses with many results, which needs to be taken
into account as the number of events in an issue can be large.
(cherry picked from commit b5a8b6b16d)
Co-authored-by: dundargoc <gocdundar@gmail.com>
ci: replace stale bot with custom implementation
The stale action has a bug where it won't close an issue/PR if it has
comments after the stale label.
(cherry picked from commit 5a97c0b0b9)
Co-authored-by: dundargoc <gocdundar@gmail.com>
Team reviewers is a nice feature that comes with a severe drawback: it
makes testing the workflows incredibly difficult as they won't work
without a similar token by the tester.
ci: use a set instead of array for team reviewers
Adding the same team multiple times will fails the review job.
(cherry picked from commit 4cb2b747c0)
Co-authored-by: dundargoc <gocdundar@gmail.com>
This catches downstream consumers of neovim off-guard when trying to use
neovim in an esoteric environment not tested in our own CI.
Closes https://github.com/neovim/neovim/issues/22932
(cherry picked from commit 0256b67e89)
Having to specify CI_BUILD for every CI job requires boilerplate. More
importantly, it's easy to forget to enable CI_BUILD, as seen by
8a20f9f98a. It's simpler to remember to
turn CI_BUILD off when a job errors instead of remembering that every
new job should have CI_BUILD on.
libtool, autoconf, automake and perl are no longer dependencies of
neovim and doesn't need to be installed in CI anymore. The dependencies
and the commit that removed them as dependencies are the following:
libtool: b05100a9ea
perl: 20a932cb72
autoconf+automake: e23c5fda0a
The universal macos release is particularly sensitive to build system
changes. Adding a job that builds a universal binary whenever a cmake
file is changed will help prevent future release breaks.
ci: remove "needs:response" label if author responds
The default behavior of the stale action is to indiscriminately remove
the `needs:response` label for any activity whatsoever, from anyone. The
other option is to turn it off completely, meaning the maintainers needs
to manually remove the label themselves when the author responds for an
issue to not close automatically. Neither of these behaviors are useful
to us.
Using team reviewers when possible reduces the churn on the git history
as we'll be able to add or remove reviewers without needing to change
the workflow files.
This requires using Github fine-grained personal access tokens with Pull
Requests set to "Read and write" and Members to "Read-only".
