automatically prevent infinite loops

[maxheld83]

currently we're relying on people setting sensible filter actions before, but it'd be nice to avoid infinite loop armageddon out of the box.

Might happen if people deploy to gh-pages, and that deploy itself (which happens via PAT, not the usual GITHUB_TOKEN which prevents that sort of thing!) might trigger other builds, and so forth.

In simpler projects there shouldn't be any diff to commit on the >1st round, but if there is random stuff in the build such as the build time or something, this might get ugly.

[maxheld83]

again, waiting for word back from github:

Because GitHub Pages builds (sadly) cannot be triggered when authorised just via GITHUB_TOKEN, users of my ghpages action have to provide a separate PAT (issue tracked here: #1).

I understand that stuff done via GITHUB_TOKEN cannot trigger new workflows to be run, which makes a lot of sense.
I worry though, that this might not apply to stuff done via bespoke PATs.

In particular, I’m worried that if people deploy via my action to their gh-pages branch, that this very deploy (via PAT!) might trigger the workflew anew, ad infinitum.
This infinite loop is currently unlikely (though possible) because the >1st run will usually error out because there’s no diff to deploy. But it could happen if, e.g. the build artefacts are polluted by the build time or whatever.

I currently warn users to always add a filter action before, which can avoid this problem, but I’m not 100% comfortable with this.

This issue is tracked here: #11

What’s your guidance here?

Obviously, I don’t want to be the guy causing infinite loops on github actions.

My (probably nonsensical) suggestion for a solution: Allow GitHub pages builds from events authorised via GITHUB_TOKEN. I can then kill the PAT alltogether and the usual (safe) behavior by which a GITHUB_TOKEN-authorised event couldn’T trigger a workflow anew would be reinstated.

[maxheld83]

response from 2019-02-23:

Hi Maximilian,

Thanks for reaching out and asking us about this!

Allow GitHub pages builds from events authorised via GITHUB_TOKEN. I can then kill the PAT
alltogether and the usual (safe) behavior by which a GITHUB_TOKEN-authorised
event couldn’T trigger a workflow anew would be reinstated.

This is something other integrators have written in about. We're tracking this internally and I've added your +1 for it so the Actions team is aware.

As far as guidance goes, I don't have any immediate workarounds to offer, though I've raised a separate issue for this asking our engineers for advice! Once I hear more from them, one of us will reach out and share our findings with you.

[maxheld83]

and 2019-03-05:

Our team reviewed this and they let me know that they're aware of this challenge at the moment. They agree this experience should be improved, though they don't have any near-term plans to address this. For now, they recommend sticking with the identified workaround (or mitigation) of using the filter action.

Please let us know how else we can be of help!