go-tfe
go-tfe copied to clipboard
hashicorp
Update workflow to include pull_request_target
Description
Add pull_request_target to the ci workflow so forks from this repository will also be able to run the ci integration tests.
Testing plan
- We could create a fork from this branch and see if the tests run.
- Do we tests workflows any other way? (I was reading about act
External links
- Related article
Output from tests
Including output from tests may require access to a TFE instance. Ignore this section if you have no environment to test against.
$ TFE_ADDRESS="https://example" TFE_TOKEN="example" TF_ACC="1" go test ./... -v -tags=integration -run TestFunctionsAffectedByChange
...
Feels gif
Re-reading through the docs, it looks like there is no way a fork can access Github secrets (I assumed manual approval would be sufficient). I think our solution here is to either create a local branch with the fork's changes manually or introduce some automated way to do it.
Re-reading through the docs, it looks like there is no way a fork can access Github secrets (I assumed manual approval would be sufficient). I think our solution here is to either create a local branch with the fork's changes manually or introduce some automated way to do it.
Hm... It sounded like we could based on this post 🤔
My understanding is pull_request_target was introduced because the pull_request event prevents write permissions and secrets access to the target repository. Thus, workflows triggered via pull_request_target have write permissions to the target repository. Additionally, workflows triggered by pull_request_target events are run in the context of the base branch, and the base branch is considered trusted, so those workflows will always run.
On the contrary, I've come across a few warnings regarding the pull_request_target event.
Security Lab @ GitHub noted:
You may ask yourself: if the pull_request_target workflow only checks out and builds the
PR, i.e. runs untrusted code but doesn’t reference any secrets, is it still vulnerable?
Yes it is, because a workflow triggered on pull_request_target still has the read/write repository
token in memory that is potentially available to any running program.
