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. Program Equity is a non-profit organization that connects tech workers to skill-based volunteering workflows on open-source climate tech projects. The organization works on the social impact through building the web app called Amplify. Furthermore, this project digitally transforms how Advocacy nonprofits onboard volunteers, fundraise and automate civic engagement. To learn more about Program Equity, visit their LinkedIn page.
ProgramEquity has three teams: Front-End, Back-End, and DevOps, where each team is responsible for solving tickets. 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 starts with checking if users 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 a 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 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 a GitHub Action from the marketplace called [github-script](https://github.com/marketplace/actions/github-script). 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 are 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 (eg. user “A”), such as all issues or pull requests listed under each repository that is created by user A.
Img. 1: Illustration on how information contained in github object under Labeler Action
Additionally, the context object was used to access detailed information in the repository where the GitHub Action is running, such as the user that is logged in and issue number of this repository. The content of the context object is obtained from the github action toolkits. Based on the code here, context object contains information such as payload, eventName, sha ref, workflow, action, actor, job, runAttempt, runNumber, runId, apiUrl, serverUrl, and graphqlUrl. The payload variable contains a Webhook payload object that triggered the workflow. Webhook payload object itself contains several other information such as repository, issue, pull_request, sender, action, etc.
Img 2: Context object has a variable called payload, which is a WebhookPayload object.
I will let Satoshi explain about the action he created, in his blog. You could also learn more by looking into the actual code here.
On the other hand, I used Github Actions from the marketplace called labeler. The way you use this action is very simple. You need to create a file called labeler.yml in the ‘.github/workflows’ folder, while at the same time, you need to create a configuration file called ‘labeler.yml’ under the root folder.
Img 3: 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 a limitation for this labeler action. After testing a couple times, I realized that this action only labels the events based on file changes specified in the configuration file, the ‘labeler.yml’ file in the root folder.
Img 4: 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. You can also look into my commit history and the code here, to see how it results in different labels, for pull request events. 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 apply the contributor label based on a 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 a GitHub action labeler workflow through GitHub CLI. Ethan, one of the ProgramEquity mentors, suggested using the if condition, as you can see in the snapshot below, as well as the ticket here.
Img 5: 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.
Top comments (0)