Rizèl ScarlettWhere have I been?
I know I said I would write about automating workflows with Git and GitHub for the next 28 days, and I missed more than a few days, but I'm back! My laptop stopped working recently, but I still plan to produce 28 DEV posts about improving automation and workflow.
Anyways, we're here to talk about automation and my big plan to automate collaborator invitations on GitHub. Previously, I wrote about how I developed a GitHub App with Probot following the instructions laid out in the Probot documentation and Brian Douglas' post. The configuration process generated files that contained sample code. The sample code handles adding a comment if an actor opens an issue. Although my goal isn't to add a comment when an actor opens an issue, I leveraged the generated sample code as a template for what I wanted to build.
Designing the Workflow
First, I had to define the workflow. I knew that I wanted to add people to the G{Code} organization without my intervention. However, I was worried about a few potential situations:
- I didn't want just anyone to join the organization. I didn't want to add bots, spammers, people unfamiliar with the organization, or toxic people to the community. Essentially, I was nervous about compromising the course material or receiving an onslaught of unwarranted pull requests.
- I wanted to create an easy way for users to request to join even if they were unfamiliar with GitHub's user interface. I want to include future contributors who aren't experienced software engineers or have stronger familiarity with another platform like GitLab.
As a resolution for controlling who can join the organization, I decided to have requestors open an issue. That way, I could review the information in the issue and approve the request. It would require some effort, but I was willing to compromise if the onus to receive and accept the invitation was on the requestor.
Opening an issue if you're unfamiliar with GitHub could be difficult, so I landed on this initial workflow:
- Actor stars the repo
- Issue opens with details prompting the actor to verify their reasons for joining the org
- I (or another G{Code} owner) approve
- Actor receives an invitation to join the organization
- Actor accepts and joins the organization
Automating Issue Creation
To handle opening an issue if an actor stars the repo, I took the following steps:
I updated my GitHub App's permissions and events
In my previous post, I developed a GitHub App. I found the app at this location:https://github.com/settings/apps to edit it. In the Permissions and Events tab, I updated the user permissions and the events I wanted my app to subscribe to. In this case, I wanted my app to listen to and have access to when a user starred the repository.
In my code, I updated the webhook event that my app should listen to.
Previously, my app was listening for newly opened issues. I changed it to listen to stars by updating
app.on("issues.opened", async (context) =>
to
app.on("star", async (context) =>
I wrote some code to create an issue if the repo is starred.
To accomplish this, I leveraged the context object, which holds the context of the triggered event, including the payload and helpers. Now, I can pass the data from the context object to GitHub API calls.
I tested the application.
I tested the application's success by running npm run start. I starred the repo with my test GitHub user, and then I saw a newly created issue with the intended contents.
I changed the app to only listen to “created” stars.
I noticed starring and un-starring in the repo created two issues, but I only wanted to create an issue if the user starred the repository. I figured anyone un-starring the repository is doing this inadvertently – either they didn't want to star the repo or accidentally unstarred it. Regardless, I don't want to have duplicate issues. To fix this, I changed the line
app.on("star", async (context) =>
to
app.on("star.created", async (context) =>
I retrieved the stargazer’s GitHub handles.
I wanted to add the actor who starred the repo to the newly opened issue. That way, I'd identify the GitHub handle of the person requesting to join the organization. Fortunately, I found the information on who starred the repo in the context object as shown here:
const user = context.payload.sender.login
Now, I'm able to include information in the issue about the user.
This seems like a good stopping point because even though my project is not finished yet, I've enabled users to star my repo and open an issue to triage incoming requests. In my next post, I'll try programmatically adding a label to the open issues, so I can differentiate between issues that are requests to join the organization versus issues to improve G{Code} 's repositories.
Take a look at the repo to see the code I have so far,
Want to learn more about automating with GitHub? Follow GitHub and me (@blackgirlbytes) on DEV for more content. I'll try to post daily!
