Experimenting with GitHub Actions

Today, I would like to talk about my latest project: a GitHub Action that helps check for non-inclusive language in code. This is a topic that really resonates with me because I co-lead the Diversity, Equity, and Inclusion group at Cisco Norway. The idea came from an initiative where we reviewed and updated all our documentation for non-inclusive terms. It made me think… why not create a tool that brings inclusivity into our code too? Responsible and ethical tech from the inside out.

Language Matters

The words we choose can significantly impact our reality. In a field that relies heavily on collaboration and diverse perspectives, using inclusive language is crucial for fostering an environment where everyone can contribute and thrive. I wanted to create a simple tool that helps developers identify non-inclusive terms in their code and suggests more respectful alternatives.

Creating the Project

For this project, I set up a new GitHub repository called InclusiveLanguageChecker. Here’s a quick look at what’s inside:

InclusiveLanguageChecker/
├── .github/workflows/
│   └── test.yml
├── README.md
├── action.yml
├── index.js
├── nonInclusiveWords.json
├── package.json
└── test.js

• index.js: This is where the magic happens. A Python script that checks for non-inclusive terms in the code. You can check the entire code in my GitHub repo here.
• nonInclusiveWords.json: A JSON file that lists terms to check along with their inclusive alternatives.

{
  "terms": {
    "master": ["primary", "main"],
    "slave": ["replica", "secondary"],
    "whitelist": ["allowlist", "inclusion list"],
    "blacklist": ["denylist", "exclusion list"],
    "grandfathered": ["legacy", "exempted"],
    "dummy": ["placeholder", "sample", "example"],
    "sanity check": ["validity check", "confidence check", "quick check"],
    "cripple": ["restrict", "limit"],
    "he": ["they", "user", "caller", "developer"],
    "him": ["them", "user", "caller", "developer"],
    "his": ["their", "user's", "caller’s", "developer's"],
    "she": ["they", "user", "caller", "developer"],
    "her": ["their", "user's", "caller’s", "developer's"],
    "man hours": ["person hours", "work hours"],
    "manpower": ["workforce", "staff", "personnel"],
    "blacklist/whitelist": ["blocklist/allowlist", "denylist/allowlist"],
    "dummy value": ["placeholder value", "test value"],
    "kill process": ["terminate process", "stop process"],
    "abort": ["cancel", "stop"],
    "crippled": ["limited", "restricted"],
    "crazy": ["unexpected", "problematic"],
    "native": ["built-in", "default"]
  }
}

• action.yml: This file tells GitHub about the action—what it does and how to use it, as shown below.

name: "Inclusive Language Checker"
description: "Checks code for non-inclusive language and suggests replacements"
icon: "heart"
color: "purple"
inputs:
  files:
    description: "Comma-separated list of file patterns to check for non-inclusive language"
    required: true
runs:
  using: "node12"
  main: "index.js"

Let’s look at the anatomy of an Action:

• name: This is the name of your action as it will appear in the GitHub Marketplace.
• description: A brief explanation of what the action does.
• icon: An icon to represent the action visually.
• color: The color used in the action’s representation in the GitHub Marketplace.
• inputs: This section defines the inputs your action can accept. In this case, it requires a list of file patterns to check for non-inclusive language.
• runs: This specifies how the action runs. It uses Node.js and points to index.js as the entry point for the action's code.

How It Works

Here’s a simple breakdown of how the Inclusive Language Checker works:

1. Load Terms: The action reads a list of non-inclusive words from a file. This list includes terms that may be considered outdated or disrespectful along with suggestions for more inclusive alternatives.
2. Check Files: When a developer submits a pull request, the action automatically scans the specified code files to see if any of the non-inclusive terms are present.
3. Comment on Pull Requests: If it finds any of these terms, it will comment directly on the pull request, highlighting the non-inclusive words and providing suggestions for what to use instead.

Setting It Up

To get everything running, I created a workflow in .github/workflows/test.yml that kicks in under two scenarios: whenever a push is made to the main branch or when a pull request is opened, edited, reopened, or synchronized.

name: Test Inclusive Language Checker

on:
  push:
    branches:
      - main
  pull_request:
    types: [opened, edited, reopened, synchronize]

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      issues: write
      pull-requests: write

    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '16'

      - name: Install Dependencies
        run: |
          npm install

      - name: List files in current directory
        run: ls -R

      - name: Run Inclusive Language Checker
        uses: ./
        with:
          files: test.js
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Testing the Action

I created a test file, test.js, with some non-inclusive terms to see if the action would catch them:

let master = "main branch";
let slave = "secondary branch";

When I submitted a pull request with this code, the action kicked in and left a comment like this:

🔍 Non-inclusive language found:
In `test.js`:
For the term: "master", consider replacing it with: **primary, main**.
For the term: "slave", consider replacing it with: **replica, secondary**.

Why This Matters

Building this Inclusive Language Checker is a practical way to take a small step toward creating a more respectful coding culture. Just like at Cisco, where we worked to clean up our documentation, I hope this tool helps others think about the words they use in their code.

Get Míriam Sánchez’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

You can check out my Inclusive Language Checker in the GitHub Marketplace and many others for the same purpose.

Thoughts on GitHub Actions

Experimenting with GitHub Actions has shown me how powerful automation can be and how much easier it makes life for developers. You can automate testing, deploying, checking for issues… and much more. Actions can handle all that. It’s also flexible enough that you can set it up exactly how you want, and it works right in your repo.

But the best part is that it’s not just about saving time. With GitHub Actions, you can build workflows that support bigger goals, like making sure code is accessible, secure, or even promoting inclusive practices like I did in this example. It’s a tool that helps teams of any size work faster and with fewer headaches.

If you haven’t tried it yet, give it a go! It’s a game-changer for keeping projects organized and running smoothly :)