It's actually as simple as adding:
timeout-minutes: xyz
to workflows.
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes
I use it elsewhere for jobs on Windows because they tend to hang sometimes
(for reasons unknown to me).
Dawid
On Mon, Oct 16, 2023 at 4:53 PM Robert Muir <rcm...@gmail.com> wrote:
> I think running the builds with a timeout is a good thing to do
> anyway, for any CI build. I'm sure github actions has some fancy yaml
> for that, but you can just do "timeout -k 1m 1h ./gradlew..." instead
> of "./gradlew" too.
>
> On Mon, Oct 16, 2023 at 9:58 AM Michael McCandless
> <luc...@mikemccandless.com> wrote:
> >
> > When a non-committer (I think?) opens a PR, one of the committers must
> notice it and click Approve & Run so the contributor can find out if
> something broke in our automated tests/precommit/linting.
> >
> > This seems like a waste, and a friction in the worst possible place for
> our community: new contributor onboarding experience.
> >
> > I think we have it to prevent e.g. a crypto mining bot of a PR sneaking
> in and taking tons of resources to mine dogecoin or so?
> >
> > But 1) that doesn't seem to be happening so far, 2) when I hit "Approve
> & Run" I never look closely to see if there is in fact a hidden crypto
> miner in there, and 3) can't we just put some reasonable timeout on the
> GitHub actions to block such abuse?
> >
> > Is this some sort of requirement by GitHub, or did we choose to turn on
> this silly step?
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
