GitHub Actions improvements for fork and pull request workflows
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…
![](https://github.blog/wp-content/uploads/2019/03/product-social.png?resize=1201%2C630)
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 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).
Improvements for public repository forks
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.
Looking to learn more?
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.
Tags:
Written by
Related posts
![](https://github.blog/wp-content/uploads/2023/10/Collaboration-DarkMode-2.png?resize=400%2C212)
2024 is the biggest global election year in history. What’s at stake for developers?
GitHub is considering what is at stake for our users and platform, how we can take responsible action to support free and fair elections, and how developers contribute to resilient democratic processes.
![](https://github.blog/wp-content/uploads/2023/10/AI-DarkMode-2.png?resize=400%2C212)
GitHub named a Leader in the Gartner first-ever Magic Quadrant for AI Code Assistants
This year, as part of its annual Magic Quadrant series, Gartner published a first-of-its-kind report analyzing the state of play in the AI Code Assistants market–and named GitHub a Leader.
![AI in software development 2024 survey results with colorful graphics and percentages.](https://github.blog/wp-content/uploads/2024/08/ai-survey-header.png?resize=400%2C212)
Survey: The AI wave continues to grow on software development teams
We surveyed 2,000 people on software development teams at enterprises in the U.S., Brazil, India, and Germany about the use, experience, and expectations around generative AI tools in software development.