Closed JamesMGreene closed 2 years ago
It sounds like we can actually configure these values as [duplicated] Dependabot Secrets (vs. Actions Secrets) in order to have them supplied to Actions workflow runs that are triggered by pull_request
s from Dependabot. This would be a much simpler fix, though arguably still a bit less secure than having the separate workflow. 🤔
Given the current Secrets we maintain that are all causing trouble are test API keys, just setting the Dependabot Secrets feels pretty safe to me.
I have added the TEST_CIVIC_API_KEY
and TEST_LOB_API_KEY
values to Dependabot Secrets.
That did the trick. 👍🏻
Let's proceed with this for the time being but we may need to reassess in the future if we start adding any tests for secrets that are more critical to not expose. 👌🏻
Our Dependabot PRs are currently failed on the required Check for the integration tests. That is because Dependabot is no longer allowed to receive Actions Secrets when running in a workflow triggered by the
pull_request
event.To remedy this, we can create a second alternative workflow that is specifically for Dependabot using the
pull_request_target
event instead and filtering the job based on the actor being Dependabot.More details here: https://github.com/dependabot/dependabot-core/issues/3253#issuecomment-797125425
P.S. We would also want to adjust the existing integration tests workflow is not run if the actor is Dependabot. 🙅🏻
P.P.S. I believe that this alternative workflow job will still be able to satisfy the required Check so long as the job has the same name as the job in the existing workflow. 👥