CircleCI-Public / trigger-circleci-pipeline-action

Trigger a CircleCI pipeline from any GitHub Actions event.
https://github.com/marketplace/actions/trigger-circleci-pipeline
48 stars 43 forks source link

Request: `pull_request_target` support #27

Open carmocca opened 2 years ago

carmocca commented 2 years ago

Is there an existing issue that is already proposing this?

Is your feature request related to a problem? Please describe it

This GitHub action requires access to a CCI_TOKEN. Because of GitHub's security, forks do not have access to secrets. So the CircleCI job will not trigger when the pull_request event is used:

Failed to trigger CircleCI Pipeline
  Error: Error: Request failed with status code 403
  Error: Request failed with status code 403

To resolve this, I thought of using the pull_request_target event, where CI runs with the base of the branch so secrets can be securely shared. Then checking out the HEAD of the PR to trick CircleCI into using this ref:

on:
- pull_request: 
+ pull_request_target:

jobs:
  # https://github.com/marketplace/actions/trigger-circleci-pipeline
  trigger-circleci:
    runs-on: ubuntu-latest
    steps:
+     - uses: actions/checkout@v3
+       with:
+         ref: ${{ github.event.pull_request.head.sha }}
      - uses: CircleCI-Public/trigger-circleci-pipeline-action@v1.0.5
        env:
          CCI_TOKEN: ${{ secrets.CCI_TOKEN }}

However, the triggering branch still points to master:

image

Describe the solution you'd like

Any suggestion on how to resolve this? I guess this logic would need to be adapted: https://github.com/CircleCI-Public/trigger-circleci-pipeline-action/blob/d8e1aed1a2524b8982a8557aaad544155c560d90/index.js#L17-L28

Teachability, documentation, adoption, migration strategy

An addition to the README would be sufficient.

What is the motivation / use case for changing the behavior?

It should work for forks.

KyleTryon commented 1 year ago

We have a very similar issue with Orb development, where we want people to send in PRs but we of course can not give access to secrets which publish orbs.

What we have done which seems to be the safest option, we review the PR manually and once satisfied, we checkout the branch and push it to a "local" branch on the origin.

It usually looks something like this:

gh pr checkout xx
git checkout -b test/pr-xx
git push --set-upstream origin test/pr-xx