Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Learn how to use custom actions to check pull requests before they are accepted.
- Pull requests, also known as PRs, are used to facilitate conversations around code. Typicallys, a PR is generated when someone wants to merge code from one repository branch into another. But they are also widely used when one developer has made an update in a clone repository, and wants to let the original develop know about the change with the goal of merging it into the original repository. The PR features on GitHub are great for this purpose because they allow the owner of the repo to review the potential changes, make comments, and if all goes well, merge the code into the repository. However, managing pull requests can be tedious. Fortunately, we can use GitHub actions to automate just about all of the steps needed to accept and merge a pull request. In this scenario, we'll use a workflow that approves and merges pull requests based on specific criteria. First, we'll run some tests to make sure the code being submitted doesn't break anything in the project. Then, we'll see if the author is in a list of approved submitters. Once these checks have passed, we'll automatically approve the PR before merging it. Along with a merge, we'll delete the branch associated with the incoming code. Let's take a look at the workflow that implements these actions. Our workflow, which I'm calling auto-merge-owner-pr, will get triggered whenever a pull request is created against our repo. In addition to limiting the workflow trigger to pull requests, we're also filtering to two types of pull requests: PRs that have just been opened, and any PR that is reopened. This will keep the workflow from running on any other type of pull request events like when a PR gets assigned, for example. Our workflow's first job is linting and testing. After checking out the code for the repository, it sets up python and then runs flake8 and pylint before running a suite of unit tests. If any of these steps fail, the job would also fail, and the workflow would stop here. If all the linting checks pass, the merge job starts. On the merge job, we're doing another set of filtering. This time, we're filtering on the GitHub actor that started the workflow. Specifically, we're filtering on automate6500 and octocat. For the sake of this example, we're assuming that these are the owners of the workflow, and we want to automatically merge in their requests. First, we use an auto-approve action to approve the pull request, and then we use the merge pull request action to merge the pull request into the master branch before deleting the branch that was merged in. Let's create a pull request and see the effects of this workflow. I've created a pull request and let all the checks run. Now that the workflow has been completed, we can see that all of our actions were successful. The main things that confirmed this are messages from the GitHub actions bot. There's the approval next to the green check mark icon and there's the merge next to the purple branch icon, and finally, next to the gray branch icon, we can see the message where the branch was deleted. And to think, all of this was done without us having to do anything. Of course, there's more that we could do to validate PRs before merging them into the master branch, but this workflow is a good example of automating PR management with GitHub actions.
- Creating an action
- Creating a workflow
- Adding actions to a workflow
- Using an action from a repository
- Developing a CI/CD pipeline with GitHub Actions
- Building custom actions
- Publishing an action to the GitHub Marketplace