Project Status Meeting 2

Welcome to the second project status meeting. In this session, we’ll review how our GitHub Actions workflow began impacting the production MongoDB cluster and outline the steps to isolate our test environments.

1. Issue Discovery

After completing the first four tasks, Alice was summoned to an urgent meeting. The team noticed that their production MongoDB cluster was intermittently unresponsive and slow ever since they integrated unit-testing and code-coverage into their CI pipeline.

1.1 Current Test & Coverage Steps

Both the unit-testing and code-coverage jobs are inadvertently pointing to the production database:

# Shared steps pointing at production DB
- name: Install Dependencies
  run: npm install

- name: Unit Testing
  id: nodejs-unit-testing-step
  run: npm test

- name: Archive Test Result
  if: always()
  uses: actions/upload-artifact@v3
  with:
    name: Mocha-Test-Result
    path: test.results.xml

code-coverage:
  name: Code Coverage
  runs-on: ubuntu-latest
  steps:
    - name: Checkout Repository
      uses: actions/checkout@v4

    - name: Setup NodeJS Version - 18
      uses: actions/setup-node@v3
      with:
        node-version: 18

    - name: Cache NPM dependencies
      uses: actions/cache@v3
      with:
        path: node_modules
        key: ${{ runner.os }}-node-modules-{{ hashFiles('package-lock.json') }}

    - name: Install Dependencies
      run: npm install

2. Root Cause

The workflow’s global env block defines production credentials, causing both testing jobs to connect to the live database:

name: Solar System Workflow

on:
  workflow_dispatch:
  push:
    branches:
      - main
      - feature/*

env:
  MONGO_URI: mongodb+srv://supercluster.d83ji.mongodb.net/superData
  MONGO_USERNAME: ${{ vars.MONGO_USERNAME }}
  MONGO_PASSWORD: ${{ secrets.MONGO_PASSWORD }}

jobs:
  unit-testing:
    name: Unit Testing
    strategy:
      matrix:
        nodejs_version: [18, 20]
        operating_system: [ubuntu-latest]
        exclude:
          - nodejs_version: 18
            operating_system: macos-latest
    runs-on: ${{ matrix.operating_system }}
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4
      
      - name: Setup Node.js
        run: nvm install ${{ matrix.nodejs_version }}

3. Refactoring Strategy

To prevent production downtime, Alice proposed spinning up a dedicated MongoDB service container inside the CI job. This gives each job its own ephemeral database instance, fully isolated from production.

3.1 Define a MongoDB Service in GitHub Actions

Add a services section under each job to start a MongoDB Docker container:

jobs:
  unit-testing:
    runs-on: ubuntu-latest
    services:
      mongodb:
        image: mongo:6.0
        ports:
          - 27017:27017
        env:
          MONGO_INITDB_DATABASE: testdb
    steps:
      - uses: actions/checkout@v4
      - name: Wait for MongoDB to start
        run: |
          for i in {1..10}; do
            nc -z localhost 27017 && break
            echo "Waiting for MongoDB…"
            sleep 5
          done
      - name: Install Dependencies
        run: npm install
      - name: Run Unit Tests
        env:
          MONGO_URI: mongodb://localhost:27017/testdb
        run: npm test

4. Project Tasks Overview

5. Next Steps

1. Update all testing and coverage jobs to use in-job MongoDB services.
2. Remove production credentials from the global env scope.
3. Validate workflow changes on a feature branch before merging to main.

Thank you for joining this meeting. Let’s keep our production environment healthy by isolating CI dependencies!

References

• GitHub Actions: Service containers
• MongoDB Docker Hub
• GitHub Actions Cache