CtrlK
BlogDocsLog inGet started
Tessl Logo

uinaf/gh-setup

Set up or align GitHub repo settings, branch/ruleset policy, templates, Actions hardening, Environments, release workflows, and deploy workflows for continuously publishable or deployable repositories.

97

1.35x
Quality

100%

Does it follow best practices?

Impact

96%

1.35x

Average score across 7 eval scenarios

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

task.mdevals/scenario-6/

Reliable GitHub Actions Deploy Pipeline for a React SPA

Problem/Feature Description

A product team runs a React SPA (built with Vite) that is currently deployed by hand: a developer runs npm run build locally and uploads the dist/ folder through the provider dashboard. This works when there is only one developer, but the team has grown to seven engineers and two of them broke production last week by shipping untested local builds. The team wants a GitHub Actions pipeline that enforces the rule "what was tested is exactly what gets deployed" — no exceptions.

The pipeline should build the app once, run end-to-end tests against that exact build output, and only then promote it through the production GitHub Environment using the provider's OIDC-backed deploy identity. If the build produces no output (which happened silently twice this month due to a misconfigured Vite output path), the pipeline must catch it immediately. The app uses a Vite-based framework with a non-standard output structure. After every successful deployment, on-call engineers must be able to see which monitoring dashboard, alert policy, synthetic check, deploy marker, and rollback runbook cover the live site — right now deploys go green in CI but incident handoff depends on tribal knowledge.

Output Specification

Produce a working GitHub Actions workflow at .github/workflows/main.yml that triggers on push to main and implements the full build -> test -> deploy flow described above. Use a repo-owned provider-thin deploy script or local action that accepts artifact path and environment; do not write a provider cookbook.

The deploy job must declare the production GitHub Environment, use id-token: write, and keep provider identifiers in environment vars rather than hardcoded workflow values.

Include a brief deploy-summary.md file explaining the pipeline shape you chose — what runs in each job, what gets passed between jobs, what identity boundary the deploy uses, and why.

evals

SKILL.md

tile.json