Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
Today GitHub Actions shipped a series of features designed to improve your workflows when working with PRs from repository forks. New settings for private repository forks Many GitHub customers choose…
Today GitHub Actions shipped a series of features designed to improve your workflows when working with PRs from repository forks.
Many GitHub customers choose to work in a forking model instead of a branching model with their private repositories. Until now, users were not able to run workflows on pull request events due to potential avenues of privilege escalation, even with a read-only token that we provide for pull requests from forks in public repositories
However, many of those working in a forking model also noted that they are already comfortable controlling who has access to their repository forks, and that they have the proper permissions in place. To enable these users to run workflows on fork pull requests, we’ve introduced three new settings at the enterprise, organization, and repository level for private repositories only.
Each of these settings exists at enterprise, organization, and repository levels (so turning it on at the enterprise level enables it for all repositories in all organizations).
GitHub Actions has always been about more than just continuous integration. Our goal is to enable repository maintainers to automate a variety of workflows and reduce manual effort. In order to protect public repositories for malicious users we run all pull request workflows raised from repository forks with a read-only token and no access to secrets. This makes common workflows like labeling or commenting on pull requests very difficult.
In order to solve this, we’ve added a new pull_request_target event, which behaves in an almost identical way to the pull_request event with the same set of filters and payload. However, instead of running against the workflow and code from the merge commit, the event runs against the workflow and code from the base of the pull request. This means the workflow is running from a trusted source and is given access to a read/write token as well as secrets enabling the maintainer to safely comment on or label a pull request. This event can be used in combination with the private repository settings as well.
Another frequently-requested feature for Actions is a way to trigger one workflow based on the completion of another workflow. For example, you may want to take the results of a CI workflow and run some further analysis.
The new workflow_run event enables you to trigger a new workflow when one or more workflows are requested or completed. Runs triggered by the workflow_run event always use the default branch for the repository, and have access to a read/write token as well as secrets. As an example, as a maintainer you could set up a workflow that takes the artifacts generated by the pull request workflow, do some analysis, and post comments back to the pull request. This event is also available as a web hook and works all repos.
Head over to the documentation for information on the new events and how to manage actions for your repository, organization, or enterprise. For questions, visit our awesome GitHub Actions community.
