search

openshift-helm-charts / development

0 stars 17 forks source link

Allow token access to redhat OWNERS file metadata check automation #338

Closed komish closed 4 months ago

komish commented 4 months ago

Fixes #337

In testing this workflow used exactly these tokens (GITHUB_TOKEN and BOT_TOKEN) throughout without issue, as written. E.g. https://github.com/komish/openshift-helm-charts/actions/runs/7935140662/job/21667629787#step:6:19

I think, because I'm the repository owner in that case, that there may have been special access to secrets that I don't have in the openshift-helm-charts/charts repository.

This PR changes the trigger to pull_request_target. Remember that we have to be conscious on what code we run when we do that, particularly if we pull the PR branch itself.

Here, I pull the PR branch after all scripts have been installed from the main branch, just so I have access to the OWNERS file, and so I can assert metadata on it. Nothing is executed from the pulled PR branch. This is similar to what we do in other workflows where we both need the content and also need secrets.

mgoerens commented 4 months ago

@komish The issue is, if I understand correctly, that the GITHUB_TOKEN secret is not available (though we are unsure why exactly) I don't understand how changing to pull_request_target is solving that ?

komish commented 4 months ago

Hey @mgoerens, great question - I sorted this out. In my test repositories, this worked with pull_request as the event trigger because the PR came from the a different branch of the same repository. When I originally wrote this PR, I had forgotten that semantic and thought it had something to do with my access as the owners of the originating repository, which was incorrect.

If the PR comes from an external fork, secrets are restricted (as expected) with the pull_request event as a safeguard to repository maintainers.

You should be able to see the confirmation here:

This PR comes from an external fork, https://github.com/komish/actions-workflow-call-test/actions/runs/8636877427/job/23677774543?pr=39

This PR comes from a branch in the same repository, and has access to the secret: https://github.com/komish/actions-workflow-call-test/actions/runs/8636853269/job/23677697900?pr=38

The pull_request_target event allows access to secrets. This is why it's important to make sure nothing is executed from the content downloaded from a PR in a pull_request_target-triggered workflow. In our workflows, I've added comments whenever we've pulled content from a pull request to ensure it happens after we've already installed what's necessary from the main branch (and not the PR source).