Mayank Kumar - Nov 1 - For my fourth Hacktoberfest PR, I was determined to work on something related to CI/CD, Docker, or perhaps something DevOps-oriented. After hunting through several repositories, I found some promising CI/CD issues, but they often required touching multiple workflows or were deeply embedded in existing configurations. Given the potential risk of disrupting the projects with complex changes, I decided to keep looking until I found a better fit. That’s when I came across valid-gtin - a lightweight JavaScript library designed to validate GTINs (Global Trade Item Numbers).
0xflotus
/
valid-gtin
A zero cost lightweight validator function in native javascript for GTINs
const validate = require("valid-gtin")
if (validate(GTIN)) {
console.log(":)")
}
valid_gtin <gtin>
To run the tests please checkout this repository and run:
npm run test
At first glance, it was a straightforward repository with only a few files and a single function responsible for GTIN validation. But that’s what made it perfect: it was clean, lightweight, and, best of all, the issue at hand was exactly what I was looking for.
The issue was focused on improving the test.yml GitHub Actions workflow file by adding path filtering to make testing more efficient by only running tests on specific file changes and thus reducing unnecessary runs. Earlier, every commit to the main branch or new pull requests, triggered tests, regardless of whether relevant files had changed. My goal was to update the workflow so that tests would only run when certain files (like .js, .ts, or GitHub workflow files) were modified. This was an ideal opportunity to learn about workflow filtering while keeping things relatively low-risk.
Tests should only run if some special files were edited
#109
To reduce the costs, the tests should only run, if one of the following files was touched:
After forking the repository and cloning it locally, I created a new feature branch and started by researching GitHub Actions path filtering options. I had never actually set up path-specific filters in a workflow before, so I spent some time experimenting with different configurations to get a better understanding of how to target files accurately and found relevant documentation on GitHub Docs.
In the test.yml file, I updated the workflow to be more efficient by modifying the on event so it would listen only to changes in specific file types, hence making the CI/CD process lighter and more efficient. The updated workflow configuration included path filters which looked like this:
on:
push:
branches:
- main
paths:
- '*.mjs'
- '*.js'
- '*.ts'
- '.github/workflows/*.yml'
- 'package.json'
- 'tsconfig.json'
After configuring the workflow, I committed my changes, pushed the branch, and opened a pull request. Setting up CI/CD filters sounds straightforward, but it was surprisingly fun digging into the specifics and understanding how path filters could optimize workflows. I liked the idea of improving the efficiency of a smaller project, where every little optimization could streamline contributions and keep the repository agile. The repository owner reviewed the pull request fairly quickly and the PR was successfully merged.
Optimize Test Workflow to Run Only on Relevant File Changes
#113
Fixes #109
This PR modifies the GitHub Actions workflow to trigger tests only when specific files are changed, reducing unnecessary test runs and saving CI resources. With this update, the tests will only run if any of the following files or patterns are modified:
.mjs, .js, .ts
.github/workflows/*.ymlpackage.jsontsconfig.json.github/workflow/test.yml by adding paths filtering under push and pull_request triggers, specifying the relevant files to watch.
paths:
- '*.mjs'
- '*.js'
- '*.ts'
- '.github/workflows/*.yml'
- 'package.json'
- 'tsconfig.json'
This PR marked a significant step for me in Hacktoberfest, allowing me to contribute to CI/CD workflows, which I’ve been interested in for a while. Working on a smaller repository was also refreshing, as it gave me space to try new configurations without the pressure of handling a huge codebase. I enjoyed this contribution for the balance it struck between learning something new and enhancing the project in a meaningful way.
