Thank you for your answer, let me clarify our flow. Each developer has his own fork of the repo Commits in master branch requires a pull request review Ideally we would have 3 workflows: prod: this would be triggered by push in master branch, or upon a new release dev: this would be triggered by push in develop branch pr: this would be triggered by pull request creation to develop branch From your feedback it seems the pr workflow will not be able to make any deployment since in this case the secrets will not be available, I guess my confusion come from that, I was expecting to access secrets upon pull request creation. You mentioned in your comment, that I should provide to develoopers a copy of the secrets needed in order to let the pr workflow work, so I've created a secrets with the same name in the forked repo, but also in this case the secret is not accessible from the upstream pr workflow. Having an action, on the forked repo would not be a solution in our case, because the PR number is used to create a path on the test environment, for allowing testers to perform test omn that specific code change, and having a number which changes in each fork, is not a good solution in our case. Do you have any suggestion for how to cover this scenario? A potential solution I was thinking of, is to create a custom action, which contains all the secrets and the code to build and deploy. It may also enforce the use of a specific branch, so that when a production deployment is triggered, it forces to use the code from master branch. Do you think this approach make sense? Do you see any side effects? Would it be possible for the calling workflow to see the logs of the invoked custom action? I would also like to highlight a couple of things I've noticed: since there is no actions-level settings, when somebody creates a pull request to a public repo, any users may introduce custom workflow to execute arbitrary code based on previous point, would those runs increase the repo's owner costs?
... View more
I'm evaluting GitHub actions for my project, and I'm currently having some question about security. This is our current working mode: each developer has his own fork of the repo, and once his code is ready for testing, a new pull request to develop branch is created, which triggers an automatic deployment on test environment, under a specific path with the pull request id. when the code review is done and the single feature is approved, the pull request is merged to develop together with the other features waiting for be released all together. when ready to release, a new pull request is created from develop to master branch, and once merged, this triggers the automatic deployment to production. Developers have access to test and dev environments, but not to production, neither to the server used to build/deploy. We are currently evaluating the idea of switching to GitHub actions, and get rid of the server, but now the problem come: in order to sobstitute the current server, we need to be able to deploy to test/dev/prod to do so, we need to move some secrets to access test/dev/prod configuration (or extra secrets) in the repo even tho, developers have no access to the secrets in the repo, they can potentially create a new workflow (or change the content in their branch) which can trigger a deployment to prod instead of test/dev even tho they work on their own fork (which do not contains the secrets), when a new PR is created, this can still trigger a deployment, and their workflow can have a different content then the one in master Is there a way to avoid this?
... View more