chore(action/PR): Use pull_request_target workflow

[amithm7]

pull_request_target workflow would be correct workflow from the base repo to run on a PR.

[ignoramous]

thanks. minor comments only.

[amithm7]

fixed.

Now, another issue has emerged. Action is not able to run git push to this repo or it's fork(s).

remote: Permission to ***/serverless-dns.git denied to github-actions[bot].

This has worked in past: GitHub Action run created a commit by github-actions[bot]: 415d654 (#43) and also in a private repository I tested (3 days ago).

Did some repository security(?) settings change?

Maybe Workflow permission are blocking?: ad-m/github-push-action#96 (comment)

Workflow permission from my test repo, in which git push worked:

[ignoramous]

Hm... The permissions haven't changed, and they look like they do in the screenshot you shared (rw permission).

[ignoramous]

Does the current PR have "allow changes from maintainers" disabled?

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork#enabling-repository-maintainer-permissions-on-existing-pull-requests

[amithm7]

Does the current PR have "allow changes from maintainers" disabled?

No, that is enabled.

What I find unexpected here is that the workflow file being run is from the HEAD of this PR (since 2nd commit of this PR).

No action was run on the first commit. Where I expected the use workflow file from base repo (main).

Maybe it is a quirk of running the PR's workflow file? (different GitHub Token?)

---

Deno-deploy's action also pushes code commited by action bot:

https://github.com/serverless-dns/serverless-dns/blob/6b9a2e9f3c043a80edbddf0665877da974052c7e/.github/workflows/deno-deploy.yml#L111-L120

[amithm7]

So,

pull_request event does run workflow file from the PR's head.

If PR is from fork:

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories

The GITHUB_TOKEN has read-only permissions in forked repositories.

Maybe it is a quirk of running the PR's workflow file? (different GitHub Token?)

Close enough. Different GitHub Token if PR comes from fork vs. origin.

There is also pull_request_target which runs workflow from origin repo, but that comes with a warning of checking out fork repo.

[ignoramous]

Well, this is a bit too over the head for me (: github-actions has always been quite a bit complicated due to the nature of the scenarios it runs in...

What's the course of action for us here (I'd imagine pull_request_target, but that comes with scary warnings, I see...) Would a simpler thing be to run the linter and formatter on commits rather than on PRs (but the fork may have actions disabled, so that's there too)?

[amithm7]

Would a simpler thing be to run the linter and formatter on commits rather than on PRs

Actions on fork repo are disabled (default). If run on this repo, it may add unnecessary commits to the main branch.

pull_request_target would be what we want. I think the only insecure thing we are doing here is npm install, for eslint. So, instead we could get eslint from base repo -> checkout PR's HEAD -> run linter -> commit to PR's HEAD.

[amithm7]

Have changed the workflow to pull_request_target workflow. Which would run the correct workflow from base repo, instead of a PR's (possibly modified) workflow.

Push to fork is still broken as GITHUB_TOKEN owned by github-actions[bot] can't as a repository maintainer, to push to fork. This probably requires creating PAT to act as a maintainer.