Skip to content
This repository was archived by the owner on May 9, 2026. It is now read-only.

Testing and Continuous Integration

Jump to bottom
NathanGrenier edited this page Nov 17, 2025 · 12 revisions

Code Reviews and Pull Request Acceptance Process

This section outlines the process and rules for submitting and merging Pull Requests (PRs). All code changes must go through this process to ensure quality and stability.

The specifics of this process are specified and enforced using GitHub's Ruleset feature.

General Rules for All Branches

The following rules apply to PRs targeting both the develop and main branches:

  • PRs are Mandatory: All commits must be made on a feature branch and submitted via a pull request. Direct pushes to develop and main are blocked.
  • Resolve All Conversations: Before a PR can be merged, all comments and requested changes must be addressed and resolved.
  • No Force Pushing: Force pushes are disabled on develop and main to protect the commit history.
  • Status Checks: In the future, all required status checks (like automated tests and builds) must pass before a PR can be merged.

Branch-Specific Requirements

Merging into develop

The develop branch is our primary integration branch for new features and bugfixes.

  • Required Approvals: 1 approving review from another team member is required.

Merging into main

The main branch contains stable, production-ready code. PRs to main typically come from the develop branch.

  • Required Approvals: 2 approving reviews from other team members are required.

Version Numbering

Our project will follow the semantic versioning number format.

image

Tagging Strategy

To track iterations and releases, we use Git tags as follows:

  • Tags on develop: We apply tags to the develop branch for each iteration (e.g., v0.1.0, v1.3.0) to mark significant milestones or completion of development cycles. Iterations will bump the minor version number by 1.
  • Tags on main: We apply tags to the main branch for official releases (e.g., v1.0.0, v2.1.0) to denote stable versions ready for production. Releases will bump the major version number by 1.

Testing

Tools Used

Coverage Reporting

Continuous Integration Strategy

This project uses GitHub Actions to automate our Continuous Integration pipeline. The goal of our CI setup is to ensure code quality, prevent regressions, and verify build integrity automatically whenever code is contributed.

Overview

Our CI strategy is designed for a monorepo structure. We utilize a "Smart Change Detection" system to only run workflows relevant to the modified files.

Key Features:

  • Set up a CI/CD pipeline (GitHub Actions): Automated workflows trigger on specific events.
  • Automated Verification: Runs tests and linters automatically on each push or PR.
  • Quality Gates: The pipeline is configured to fail builds on test/lint failures, preventing broken code from merging.
  • Change Detection: Saves resources by only testing the backend, frontend, or n8n services if files in those directories have changed.

Triggers

The pipelines are triggered on:

  • pull_request: Targeted at main or develop branches.
  • push: To main or develop branches.
  • workflow_dispatch: Manual triggers via the GitHub UI.

Local Pre-Commit Hooks (Husky)

Before code even reaches GitHub, we use Husky to enforce quality standards locally. A pre-commit hook runs lint-staged to ensure that:

  1. Frontend: runs linting, formatting checks, and related tests.
  2. Backend: runs linting, formatting checks, and related tests.

If these checks fail locally, the commit is aborted.

Workflow Structure

The CI pipelines generally follow a two-stage process:

  1. Detect Changes: Checks which directories (backend/, frontend/, n8n/) have been modified.
  2. Execute Jobs: Runs the specific CI jobs for the modified components.

Workflow Dependency Visualization:

image

1. Change Detection

This job checks out the code and identifies modified files. If no changes are detected in a specific module, the subsequent heavy jobs for that module are skipped to save build time.

Detect Changes Job (Backend):

image

Backend Pipeline

Configuration File: .github/workflows/backend_ci.yaml

The Backend CI runs on our self-hosted runners (arc-runner-set) using Node.js 22.

Workflow Steps:

  1. Checkout: Retrives the codebase.
  2. Setup Node: Configures Node 22 and caches npm dependencies.
  3. Install Dependencies: Runs npm ci for a clean install.
  4. Format Check: Verifies code formatting using Prettier (npm run format:check).
  5. Lint: Static analysis using ESLint (npm run lint).
  6. Unit Test: Runs Vitest with coverage (npm run coverage).
  7. Build: Verifies the project compiles using TypeScript (npm run build).
  8. Codecov: Uploads coverage reports to Codecov for analysis.

Backend CI:

image

Frontend Pipeline

Configuration File: .github/workflows/frontend_ci.yaml

The Frontend CI handles React Native/Expo verification and build previews for Web and Android.

Job: frontend_ci (Quality Checks)

  • Setup: Node 22 environment.
  • Format & Lint: Checks formatting (Prettier) and runs Expo Lint.
  • Unit Tests: Runs Jest tests (npm run coverage).
  • Coverage: Uploads reports to Codecov.

Job: build_web

  • Expo Doctor: Validates the Expo environment.
  • Build: Exports the web version of the app (npm run build:web-dev).

Job: build_android

  • Setup: Installs Java 17, Android SDK, and EAS CLI.
  • Caching: Caches Gradle dependencies to speed up future builds.
  • Build: Generates an Android preview build via EAS (npm run build:android-prev).

Frontend CI:

image

n8n Pipeline

Configuration File: .github/workflows/n8n_ci.yaml

Currently, the n8n pipeline serves as a placeholder for future automation regarding our workflow automation service.

  • Current Status: Checks for file changes in the n8n/ directory.
  • Future Roadmap: Will include dependency installation and workflow testing.

n8n CI:

image

Clone this wiki locally