Monitor Pull Requests with the GitHub CLI

Ryan Harris
InstructorRyan Harris
Share this video with your friends

Social Share Links

Send Tweet
Published 4 years ago
Updated 3 years ago

Using the GitHub CLI and a shell script, we will automate the process of monitoring pull requests in repositories we maintain. Specifically, open PRs we have created and those awaiting our review.

Ryan Harris: [0:00] Let's start by installing the GitHub CLI from home brew using the brew install github/gh/gh command. We can confirm it's working. We'll change directory into our egghead directory, and we'll run the gh pr status command.

[0:18] In this output, you can see information about the current git repo, your current branch, PRs you've created, and PRs that are waiting for your review. While that's pretty useful, you can see that in our code directory, we have two git repos, egghead and egghead-part-2.

[0:35] To use the GitHub CLI, we would have to change directory using cd egghead into the egghead directory, run gh pr status, go back up a level, and then change directories into our egghead-part-2 repo, and run gh pr status again.

[0:56] That seems like a lot of manual work. Let's clear the screen and go back up into our code directory. What we'll want to do here is we're going to create a shell script to automate this. We'll use the touch command, or touch check-prs.zsh. Then we'll open that file with the code command.

[1:17] First, let's start with the for loop. For every directory inside of our code directory, do the following. First, we'll change directories or cd into the directory, then we'll use the pwd command to print out the working directory.

[1:38] In our terminal, we'll just run zsh check-prs.zsh. You can see we've printed out the working directory for both of the repos within our code directory, egghead-part-2 and egghead.

[1:53] Let's update the shell script to use the GitHub CLI by running a custom function, function get_pr_status(). The body of this function will be the same command we used earlier, gh pr status. Then we can update our for loop to use our new function instead of printing the working directory.

[2:14] We'll get_pr_status here. Save that. Come back into our terminal and run the same script we ran before, zsh check-prs.zsh. As you can see, we now have the GH PR status output for both egghead-part-2 and egghead. This script is coming along, but to run it right now, we need to be in our code directory because if you list out everything inside of our code directory, you can see that's where our script lives.

[2:49] We want to run this from anywhere on our system. What we're going to do is we're going to open our zshrc using the code command, code ~/.zshrc. Here, we have some ZSH configurations that you can ignore.

[3:02] What we're going to do is below that, add a new alias using the alias keyword, alias check-prs="". In between these quotes, we're going to define the command we want to run when we execute check-prs within our terminal. In this case, it's going to be zsh -/code/check-prs.zsh.

[3:26] For these changes to take effect, we have to go back into the terminal and use the source command, source ~/.zshrc, to reload our ZSH config which we just updated. If we go up a level, we can run this command outside of the code directory. If we check-prs, you can see we've iterated through the same repos we were looking at earlier, egghead-part-2 and egghead.

[3:55] In summary, by adding an alias to our shell configuration and using a shell script, which leverages the GH CLI, we were able to programmatically check the PR status of both of the repos that live within our code directory.

egghead
egghead
~ 31 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today