Setting up CI/CD with GitHub Actions

Welcome to my reflection on CI/CD experience, where the core objective was to move beyond local testing and integrate a CI pipeline into my project using GitHub Actions. This lab was an interesting experience understanding how to manage project complexity and a fundamental concept in collaborative software development.

1. The ci.yml Blueprint
The first step was setting up the automation pipeline. Since my project is based on Python and uses Pytest for testing, I configured a workflow to automatically run tests whenever code was pushed or a Pull Request (PR) was opened.

-The GitHub Actions Workflow-
The configuration was defined in the .github/workflows/ci.yml file, ensuring a consistent testing environment.

What does the YAML file do?
This workflow automates four key steps:

1. Checkout the code
2. Set up the required Python environment
3. Install project dependencies
4. Execute all unit tests using pytest

This process guarantees that no new changes will break the existing functionality before they are merged.

2. Mastering the CI Cycle: Pass, Fail, Pass
The most important part of setting up CI was running the full test cycle. This proved that the CI system itself works as expected.

• Initial Pass (Success): I created a PR, and the CI successfully ran all existing tests, resulting in a green checkmark.
• Intentional Fail (Failure): I then committed a change that caused a test to fail. The CI automatically re-ran and immediately reported a red X.
• Final Pass (Recovery): After reverting the breaking change, the CI successfully ran again, showing a green checkmark.

This cycle confirmed that the CI is functioning properly.

3. The Cross-Project Collaboration Challenge
Afterwards, I had to find a partner and contribute a new test case to their repository. My partner's project was also Python-based, utilizing Pytest and a similar src/tests directory structure.

The experience of writing tests for external code highlighted the need for strong documentation and well-encapsulated functions. I chose to write tests for ArgParser class, focusing on its custom logic for loading TOML configuration files.

The main challenge I faced was an unexpected ModuleNotFoundError when trying to run tests locally, even though the file structure was clear. This was because Python's default import path does not automatically include the sibling src/ directory.

The solution required manually inserting the src folder's absolute path into the system's path configuration within the test file.

# The Fix for ModuleNotFoundError:
import sys
import os
src_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), '..', 'src'))
sys.path.insert(0, src_dir)
from arg_parser import ArgParser

This experience was a reminder that while CI automates testing, basic project setup is essential for any developer joining the project.

Having successfully set up CI and used it in a real-world scenario, I now strongly believe that CI is inevitable.

Before this lab, running tests felt like an optional. However, proper testing removes human error and ensures that every code change, no matter how small, is immediately validated against the entire suite of existing tests.

CI is not just about testing. It's about reducing integration friction and providing immediate feedback which is key to maintaining a stable and scalable codebase