GitHub Actions — Labeler vs Github-script

Hi guys!

I’m writing this blog to continue the previous blog on GitHub Actions. As I previously mentioned, I was involved in the ProgramEquity, joining the DevOps team. One of the tickets I was working on with ProgramEquity involved creating a labeler action. This action assigns ‘new contributor’ label to individuals who are new to the repository. The logic behind this action starts with checking if the user never created a pull request or an issue, in a specific repository, under their account. If there is none found, then the action will label the user as new contributor. Otherwise, it does nothing.

Several individuals, including myself and Satoshi, contributed to resolving this ticket. In this blog, I will focus on Satoshi’s solution, because as a team, we decided to merge his code into the main branch of the Amplify App. After I briefly discuss about Satoshi’s Github Actions workflow, I will talk about why my solution is not the best. You can read and follow Satoshi’s blog here.

Satoshi decided to use GitHub Actions from the marketplace, called `github-script` action. This action proves handy for quickly incorporating a script into your workflow. This Github action provides various objects such as github, context, core, glob, io, exec, and require, which often helpful to obtain information on each api call.

There were two objects that were used in this Github Action workflow: ‘github’ and ‘context’. Github was used to obtain information of a specific user (let’s call the user “A”), such as all issues or pull request listed under each repository that is created by user A. You can see the illustration below.

Information contained in github object under Github Labeler Action

Additionally, the context object was used to access detail information in the repository where the GitHub Action is running, such as the user that is logged in and issues number of this repository. The content of context object is obtained from the github action toolkits. Based on the code here, context object contains information such as payload, eventName, sha ref, worfklow, action, actor, job, runAttempt, runNumber, runId, apiUrl, serverUrl, and graphqlUrl. The payload variable contains Webhook payload object that triggered the workflow. Webhook payload object itself contains several other information such as repository, issue, pull_request, sender, action, etc. You can see the connection between context and WebhookPayload object below:

Context object has a variable called payload, which is a WebhookPayload object.

I will let Satoshi to explain about the action he created, in his blog. You could also learn more by looking into the actual code here (I have asked his permission to share his code).

On the other hand, I used Github Actions from the market place called labeler. The way you use this action is very simple. You need to create a file called labeler.yml under ‘.github/workflows’ folder, while at the same time, you need to create a configuration file called ‘labeler.yml’ under root folder.

The labeler action starts from line 17. By default, configuration path doesn’t need to be declared as it already points to ‘.github/labeler.yml’

There is limitation for this labeler action. After testing couple times, I realize that this action only labels the events based on file changes that is specified in the configuration file, the ‘labeler.yml’ file in the root folder.

Configuration file contains which label will be attached to the specific event, based on file change

You can read about the details on how to create the configuration file based on the original repo here. You can also look into my commit history and the code here, to see how it results in different label, for pull request event. However, creating issues doesn’t trigger the GitHub Actions as the action only detects changes in the repo file, through ‘git push’ command to the pull-request.

In conclusion, github-script is the closest github action solution to be able to label contributor based on user’s activities. Github labeler action only detects the file changes, but it is not able to check on the user information. It is possible to create github action labeler workflow through GitHub CLI. Ethan, one of the ProgramEquity mentor, suggested to use if condition, as you can see in the snapshot below, as well as the ticket here.

Suggestion on how to create github action workflow for labeler action

In conclusion, there are many Github Actions available in the marketplace, however, you might need to test them one by one, to check if they are the right action for the purpose you are looking for. Otherwise, another suggestion will be to create your own Github Actions. You can also post your created github actions into the marketplace, to be used by others.