Skip to content
back to achievements

Case study · LookSuite

Client project · AugmentProject period2025 – Present

Pull-request quality gate

Built automated pull-request quality and performance validation, including API load testing, application tests, and video-pipeline telemetry comparison against the main branch.

01

Why

main is protected, so every change reaches it through a pull request. That pull request has to be solid enough to catch problems first. The gate is a precaution so nothing breaks the system. It also saves developer time and improves productivity, because problems surface on the pull request instead of after the merge.

02

Decision

Every pull request starts GitHub Actions, which runs grouped checks in parallel. File-based filtering picks the checks that fit the files changed, and caching keeps repeat runs fast. A merge gate allows the merge only if the required checks pass.

  • Builds (4): frontend, web app, backend and the QR shortener.
  • Tests: Vitest for the frontend, Supertest for the Node.js backend, Playwright for end-to-end, and a Storybook regression test.
  • Static analysis (6): frontend, backend, web, end-to-end tests, repo root and the QR shortener.
  • Security: a secret scan on the changes.
  • Guards (4): Breaking Change, Documentation, Deployment Workflow and Public Web.
  • Performance: a k6 API load test, plus the video pipeline run with the pull request's changes. Its telemetry is compared with main's and summarized as "perf vs main".

How it fits

Hover or focus a box for the story behind it.

GitHub Actions runs grouped checks in parallel on every pull request: builds, tests, static analysis, secret detection, guard checks and performance checks. A merge gate lets the pull request merge only if the required checks pass. The performance check runs the video pipeline for the pull request, compares its telemetry with main, and produces a summary.Runs on every pull requestChecks run in parallelInside the performance checkBlocked: fix and push againGitHub Actions starts every check automatically on each pull request.Actions GitHubVite build checks for the frontend and the web app, plus build checks for the backend and the QR shortener.Builds 4 checksUnit tests for the frontend and the backend, and a Storybook regression test.Tests Unit, StorybookStatic code analysis for each part of the repo: frontend, backend, web, end-to-end tests, the repo root and the QR shortener.Analysis 6 checksSecret detection scans the changes for leaked secrets.Security Secret scanFour guard checks: Breaking Change Guard, Documentation Guard, Deployment Workflow Check and Public Web Check.Guards 4 checksThe video pipeline performance summary and an API load test. The third view shows how the video check works.Performance Video, API loadThe merge gate: the required checks have to pass.Merge gate Required checksOnly a pull request that passes can merge.Merge AllowedThe video pipeline runs with the pull request's changes and records telemetry.PR build TelemetryThe two sets of telemetry are compared, so slowdowns against main stand out.Compare PR against mainTelemetry from the main branch serves as the baseline.Main branch BaselineA performance summary of the pull request compared with main.Summary Perf vs main

Every pull request starts GitHub Actions, which runs the checks in parallel: builds, tests, static analysis for each part of the repo, secret detection, guard checks and the performance checks. If the required checks pass, the pull request can merge.

03

Alternatives considered

Husky pre-commit hooks run the checks locally and cost no runner time. Each folder has its own script, and a single Husky setup in the repo root can reach all of them, so the hook runs the same scripts the pipeline does. The catch is that a developer can skip a hook. So Husky stays as a free early check, and the pull request remains the check nobody can bypass.

04

What I built

Designed and maintained automated pull-request validation workflows using GitHub Actions to detect code-quality, application-performance, and video-processing regressions before changes are merged.

The PR validation process includes checks such as:

  • Linting and formatting validation
  • Documentation validation
  • API load/performance testing
  • Automated application tests
  • Video-pipeline telemetry validation

Implemented video-pipeline telemetry comparison between the main branch and pull-request builds, surfacing performance differences to identify potential improvements or regressions introduced by a change.

05

Trade-offs

  • Runner cost can be high, because many checks run on every pull request.
  • To reduce it, only the checks that fit the changed files run, caching is on, and some test cases move into the Husky hooks.
  • Moving checks into Husky saves runner time, but Husky can be overridden. The pull-request checks stay required before merge for that reason.

06

Outcome

From GitHub Actions usage metrics over the last 30 days:

  • Average job runtime: 1 minute 47 seconds.
  • Average queue time: 2 seconds.
  • Job failure rate: 2%.
  • Failed-job usage: under 100 minutes.

Technologies