Introduction

This week, I delved into setting up a Continuous Integration (CI) pipeline using GitHub Actions while also expanding my suite of unit tests for my project, VShell. The process has enhanced my understanding of CI principles, automated testing, and the tools that help developers ensure reliable code delivery.

What is Continuous Integration?

Continuous Integration is a development practice where code changes are automatically tested and integrated into a shared repository frequently. By leveraging a CI pipeline, developers can detect and address issues early in the development cycle, improving code quality and reducing integration risks. A CI/CD pipeline allows us to build, test, and deploy applications automatically, accelerating development and increasing reliability.

Setting Up the CI Pipeline with GitHub Actions

There are numerous CI tools available—Jenkins, CircleCI, TravisCI, and GitLab CI, among others—but for this week, I focused on GitHub Actions to implement CI/CD for my application. GitHub Actions offers an integrated, straightforward setup directly in GitHub, making it a great choice for my project.

Configuring GitHub Actions for My Project To set up a CI pipeline, I navigated to the Actions tab of my GitHub repository and selected the Node.js template, as my application is JavaScript-based and runs on Node.js. This generated a .yml configuration file that defines the CI pipeline’s behavior.

Understanding the YAML Configuration For those new to CI, the .yml file might seem intimidating. Here’s a breakdown of how it works:

Triggering the Pipeline: The pipeline is set to run whenever a push or pull request is made to the main branch, using the on keyword to define these triggers.

Defining Jobs: The configuration includes a series of jobs that execute when the CI pipeline is triggered. These jobs specify an Ubuntu OS build environment, test across different Node.js versions, and contain steps to set up and execute the runtime environment. Finally, the tests are automatically run to validate the code.

My experience

Environment Variable Configuration During my initial pipeline setup, I encountered an error related to the GROQ_API_KEY, which is essential for certain tests and defined in my local .env file. While tests ran smoothly locally, GitHub Actions couldn't access the variable, leading to failed runs.

Solution: Setting Up GitHub Secrets To address this, I configured a secret variable for the API key in my GitHub repository settings. Here’s a quick summary of the fix:

• I navigated to the repository’s settings and added GROQ_API_KEY as a secret under Settings > Secrets.
• In the .yml file, I added the env keyword to instruct the pipeline to retrieve this key, ensuring the tests could access it without hardcoding sensitive data in the configuration file.