Name: Make your first contribution to a GitHub Action!
Rating: 3.4 (9141 reviews)
Author: blackgirlbytes

Why edit a GitHub Action?

There are many reasons to edit a GitHub Action. Perhaps, you found an Action suited to your use case. It's almost perfect, but there's just one minor feature missing. Maybe you noticed a bug or edge case, or you have an idea to take the Action to the next level.

One solution is to recreate the Action, make it your own, and add all the improvements you desire. The second and my preferred solution is to make a pull request for the Action you are already using. The latter encourages you to treat the Action as an open source project. In return, the benefits include:

Expanding your developer network - This is a potential opportunity to interact with the creator of the Action.
Technical Exposure - Editing an Action used by multiple developers means you have to think about how your edits will affect other users, which may expose you to new technological problems.

Caution: Make sure you get the author's approval to add changes to their Action. The easiest way to do this is by opening an issue and starting a discussion with the author and/or other contributors. You don't want to spend time opening a pull request that the author doesn't want, and will eventually reject.

My reason

Not to sound too nerdy, but I feel a rush of excitement and anticipation when I pick up an open source issue. I probably feel that way because I'm still relatively new to open source, and I've transitioned from writing production code every day to not writing production code at all.

I picked up an issue earlier this month, but I didn't work on it immediately because of the holidays. When I returned a week later, a contributor reassigned the issue to themselves and opened a pull request.

While I was impressed by the contributor's eagerness, speed, and clever solution, I felt disappointed for a brief moment. Until a friend and frequent contributor, @mtfoley, helped me realize the root cause of the problem: the Contributor Take Action had a minor bug.

The TLDR: The Contributor Take Action allows contributors to self-assign issues by typing ".take" in a comment. However, if another contributor comments ".take" after the initial contributor self-assigns the issue, the Action will assign that issue to the subsequent contributor as well.

Matthew helped me transform my disappointment into opportunity: I could fix the bug in Contributor Take Action. I will still get to push code, and I could reduce the chance of miscommunicated reassigned issues in open source projects that use this Action.

How to Test and Edit

Contributing code to a GitHub Action is similar to contributing to any open source project.

The Setup

Step 1: Locate the Action on GitHub’s Marketplace

Step 2: Find the repository for the Action. The URL for the repository is underneath the "Links" section. Once you click that link, it should lead you to the repository.

Step 3: Fork the repository by pressing the fork button on the top right.

Step 4: Once the project is forked, you should have a copy of the repository. Head over to your copy and clone the repository or open it up in Codespaces.

Step 5: Set up a repository for testing and follow the directions written in the Action’s ReadMe.

In my case, I used a repository I made for sandboxing and playing around with actions called deploy-with-actions. Inside of my deploy-with-actions repository, I created a .github/workflows directory. Inside that directory, I created a take.yml file, and I pasted the workflow written in YAML from the take-action repository's README into that file.


# .github/workflows/take.yml 

name: Assign issue to contributor

on: 

  issue_comment:

jobs:

  assign:

    name: Take an issue

    runs-on: ubuntu-latest

    steps:

    - name: take the issue

      uses: bdougie/take-action@main

      env:

        GITHUB_TOKEN: ${{ github.token }}

      with:

        message: Thanks for taking this issue! Let us know if you have any questions!

Step 6: Point the workflow to your forked Action. You can even point it to a different branch or commit. It should look like:

uses: {username}/{repo_name}@{branch_name}

For instance, I changed


 uses: bdougie/take-action@main


 uses: blackgirlbytes/take-action@handle-if-assigned

Actually Testing

Step 6: First, let's check that the Action is working as expected by triggering the Action. After I committed and pushed all the files from the set up above, in my case, I opened up an issue and commented ".take" from a GitHub user account I created for testing. To be clear, I did this in my repository that is using the Action called deploy-with-actions, not the repository for the Action. As expected, I received a message that said, "Thanks for taking this on! If you have not already, join the conversation in our Discord."

Step 7: Time to debug! Try editing your Action and adding a few log statements. You can read the documentation here to learn more about debugging logs. Here’s an example of some edits I made to blackgirlbytes/take-action/action.yml on the handle-if-assigned branch.


name: contributor-takes-action

description: This is an action to assign yourself to an issue for a repo you are not a contributor to.

author: Brian Douglas

branding:

  icon: 'thumbs-up'

  color: 'white'

inputs:

  message:

    description: 'Message to prospective contributor'

    required: false

    default: ''

runs:

  using: "composite"

  steps:

    -

      run: |

        BODY="$(jq '.comment.body' $GITHUB_EVENT_PATH)"

        ISSUE_NUMBER="$(jq '.issue.number' $GITHUB_EVENT_PATH)"

        LOGIN="$(jq '.comment.user.login' $GITHUB_EVENT_PATH | tr -d \")"

        REPO="$(jq '.repository.full_name' $GITHUB_EVENT_PATH | tr -d \")"

        ISSUE_JSON="$(jq '.issue' $GITHUB_EVENT_PATH)"

        ISSUE_CURRENTLY_ASSIGNED=`echo $ISSUE_JSON | jq '.assignees | length == 0'`

        if [[ $BODY == *".take"* ]]; then

          if [[ "$ISSUE_CURRENTLY_ASSIGNED" == true ]]; then

            echo "$ISSUE_CURRENTLY_ASSIGNED"

            echo "Assigning issue $ISSUE_NUMBER to $LOGIN"

            echo "Using the link: https://api.github.com/repos/$REPO/issues/$ISSUE_NUMBER/assignees"

            curl -H "Authorization: token $GITHUB_TOKEN" -d '{"assignees":["'"$LOGIN"'"]}' https://api.github.com/repos/$REPO/issues/$ISSUE_NUMBER/assignees

            if [[ ! -z $INPUT_MESSAGE ]]; then

              jq -n -r --arg body "$INPUT_MESSAGE" '{body: $body}' > payload.json

              curl -X POST -H "Authorization: token $GITHUB_TOKEN" --data @payload.json https://api.github.com/repos/$REPO/issues/$ISSUE_NUMBER/comments

            fi

          else

            echo "This issue is currently assigned to a different user"

          fi

        fi

      shell: bash

      env:

        INPUT_MESSAGE: "${{ inputs.message }}"

Step 8: Check the results by reading the Actions logs and continue to modify the code until you get your desired results. I found my Actions logs by heading to the deploy-with-actions repository and clicking on the Actions tab.

Step 9: Once you have a working solution, commit and push your changes, and create a pull request. Make a pull request comparing forks instead of branches.

You can find my PR here. In this PR, I made a pull request comparing my branch to the author’s branch.

Although this solution was successfully merged, I have more to add. My initial implementation doesn’t comment or assign the subsequent contributors, but now I’m working on adding a response or feedback for contributors to understand why they weren’t assigned if the issue was already assigned to another contributor. You can check out my work in progress pull request here.

If you like this content, give me a follow or comment below!