GitLab CI Integration (workflow)
Operating mode (token-efficient)
- •Treat
gitlab-cias a router + governor. - •Do not load multiple procedures. Select exactly one procedure below and follow the chosen procedure end-to-end.
Routing (pick one procedure)
| Task | Open the procedure | Optional templates |
|---|---|---|
| Enable/adjust test jobs (web/api/mobile/perf) | reference/procedures/enable-test-jobs.md | reference/templates/gitlab-ci/ |
| Standardize artifacts + reporting | reference/procedures/artifacts-and-reporting.md | — |
| Troubleshoot CI failures | reference/procedures/troubleshoot.md | — |
Shared non-negotiables (apply to all procedures)
- •
Test command contract
- •Each suite must have a single deterministic command runnable in CI.
- •Template repo baseline commands:
- •
node .ai/scripts/lint-skills.mjs --strict - •
node .ai/scripts/lint-docs.mjs - •
node .ai/tests/run.mjs --suite <suite>
- •
- •For project test suites, define equivalent deterministic commands (examples):
- •API (Newman):
pnpm test:api/npm run test:api - •Web (Playwright):
pnpm test:e2e:playwright/npm run test:e2e:playwright - •Web (Cypress):
pnpm test:e2e:cypress/npm run test:e2e:cypress - •Perf (k6):
k6 run ...(or containerized runner) - •Mobile:
pnpm test:mobile:<detox|maestro|appium>/ custom runner script
- •API (Newman):
- •Commands must:
- •exit non-zero on test failures
- •write evidence/artifacts to a predictable directory (e.g.
.ai/.tmp/test-evidence/for the template repo, orartifacts/<suite>/for app suites)
- •
Artifacts are mandatory
- •Always upload artifacts/evidence even on failure:
artifacts/or.ai/.tmp/test-evidence/ - •Keep artifacts size-bounded (videos/traces on failure only when possible).
- •Always upload artifacts/evidence even on failure:
- •
Secrets management
- •Use GitLab CI variables (masked/protected).
- •Never echo secrets in logs.
- •
Gating policy
- •MR gating should run only fast, stable suites.
- •Heavy suites (mobile, load/stress) should be scheduled or manually triggered.
Minimal inputs before changing CI
- •Whether
.gitlab-ci.ymlalready exists and how the file is structured (includes, stages) - •Which suites are MR-gated vs scheduled
- •Required CI variables and how they map to env vars
- •Runner constraints (Docker executor, macOS runners for iOS, etc.)
Verification
- •
If you changed skills:
- •
node .ai/scripts/lint-skills.mjs --strict - •
node .ai/skills/features/ci/gitlab-ci/scripts/validate-skill.mjs
- •
- •
If you changed .gitlab-ci.yml:
- •Trigger a pipeline and confirm:
- •correct suite execution
- •artifacts retained
- •failures show clear signals
- •Trigger a pipeline and confirm:
Boundaries
- •Do not hardcode secrets or base URLs in
.gitlab-ci.yml. - •Do not make MR gating flaky; move unstable suites to scheduled runs.