Keep workflow trigger after auto-commit on external contribution PR

[WarningImHack3r]

I have a workflow that checks out the repo (with a pull_request trigger), makes some pre-checks and then execute the build step etc.

My issue is the following: for a PR I make on my repo from another branch, everything works fine and I have the intended behavior.
However, when the workflow is triggered from an external member (dependabot or forks), the workflow cannot start because I use a secrets.PAT as recommended in the README to allow the workflow to be triggered from the new commits. This secret cannot be fetched from there for obvious security reasons on an unknown codebase.

A workaround could be to use the pull_request_target trigger, however in that case I can indeed access my secrets but the checkout would occur on my main branch, which is not what I want.

To sum up, is there a way to keep a workflow triggered from the auto-commit without exposing secrets to an external contribution?

[stefanzweifel]

Hey

We have a dedicated section about how to setup the Action to run for forks of public repositories here: https://github.com/stefanzweifel/git-auto-commit-action#use-in-forks-from-public-repositories

In that workflow, there is no need for a PAT, if you don't use protected branches.
Could you give that a try?

Personal access token are ususally only needed if your repository uses protected branches or you must trigger another workflow run from commits made with this action.

If you must have secrets in your workflow and they need to be run for contributors, I actually don't know how to do that either. Would also need to do some research on this.

(In a personal project of mine, I also must use secrets for an AWS account and I haven't figured out yet, how do make them safely available to contributors or dependabot. There is a special "Dependabot" section for secrets, but I don't think that works for contributors using public forks)

[WarningImHack3r]

For option 1 and the PR you linked, it maybe works but it does not trigger the workflow again from the new auto-commit, which is basically my current situation and what I want to avoid:

• A commit without workflow blocks the ability to merge the PR if you have a required workflow set up on your repo (AFAIK)
• It does not guarantee that the auto-commit fixes everything and builds successfully, a new workflow run is mandatory

So, as the "for everybody" + auto-commit + "auto-commit triggers workflow" setup does not seem possible, I'm going for option 2 unless a solution is discovered someday or GitHub addresses this feature lack.

---

For option 2, putting an if: statement on top of the job is indeed straightforward. However, as the target setup would be the following...:

• If allowed, checkout with PAT & token: and push the auto-commit which will trigger the workflow once again, all good
• If not allowed, checkout with ref: and repository:, and simply throw an error if some file is not correct, letting the user fix it manually (painful for Dependabot with lock files, but no other choice)

...what are the conditions that prevent a case scenario from being allowed? It's confusing because Dependabot creates a new branch on the original repo without needing any fork but still doesn't have permission to fetch secrets (and to be fair this whole problem is very confusing)...

At the end of the day, wouldn't the condition be if the actor is not a member of the organization/contributors? If it's the right condition, how can I write it? (A bit out of your scope I know but you're the most likely person to be able to know that)

[stefanzweifel]

I agree: it's all very confusing. Especially the differentiation between "normal" users and Dependabot.
(In past projects, I had to duplicate my secrets in the repository setting, as there are "normal secrets" and "Dependabot secrets".)

The idea of detecting if the user is in the organisation or is a contributor makes a lot of sense.
Unfortunately the github-context doesn't return that much user information. Only the username and user_id is returned. With additional API requests one could probably figure out, if the user has the right permissions.

[WarningImHack3r]

I just came back to that problem to try implementing it. However, I'm still stuck on that if allowed condition because I want the best implementation and fewer drawbacks. Did you try getting in touch with the GH team to get their advice/explanations? Should I give it a(nother) try for this specific problem I'm trying to solve?

[stefanzweifel]

Did you try getting in touch with the GH team to get their advice/explanations?

I don't have direct access to anyone of GitHub. The best place for such problems/questions is probably the community discussion board: https://github.com/orgs/community/discussions/categories/actions

Should I give it a(nother) try for this specific problem I'm trying to solve?

I can't stop you. :)
Personally, I think this is quite a hard problem to solve, as GitHub as a platform makes it hard. But if you would solve this hard problem and publish your findings/solutions somewhere, you would make many GH Actions users happy.

[WarningImHack3r]

Hi @stefanzweifel! I managed to build up a "kinda clean" solution here. The idea is simple: try to check out a first time and adapt the rest of the jobs and/or the steps depending on if it fails or not! This is the "if allowed" condition I mentioned above.
Also, note that I added the same exact secrets.WORKFLOW_PAT to both the org secrets and org dependabot's secrets.

Overall, it does the job as intended but it's not the cleanest solution on earth so I'm only half-proud of it. Anyway, thanks for your help!