Christopher Clendening
96b7ff9766
- Create SECURITY.md to outline security policies and practices. - Establish WORKFLOW.md detailing the project lifecycle from planning to retrospective. - Introduce decision log structure in decisions/README.md for tracking architecture decisions. - Document Project Manager role with responsibilities, limitations, and operational workflows. - Implement templates for ADRs, bugs, meetings, projects, retrospectives, RFCs, roadmaps, and sprints. - Set up memory logs for architecture and company-wide lessons learned. - Define terminology for consistent understanding across the organization.
67 lines
3.2 KiB
Markdown
67 lines
3.2 KiB
Markdown
# ACT_RUNNER.md
|
|
|
|
ACT Runner is CI for Local LLC: build, test, validation (`COMPANY.md`). It is deployed and
|
|
reachable today, with runners registered for both Linux and macOS. This document is DevOps
|
|
Engineer policy, owned per `ORGANIZATION.md`.
|
|
|
|
## Runners
|
|
|
|
| Runner | Label placeholder | Used for |
|
|
|---|---|---|
|
|
| Linux | `<RUNNER_LABEL_LINUX>` | Default for backend/ML/general builds and tests |
|
|
| macOS | `<RUNNER_LABEL_MACOS>` | Anything requiring macOS-specific toolchains (e.g. iOS builds) |
|
|
|
|
Replace the placeholders with the actual registered runner labels once confirmed; workflow
|
|
files should target a label, never assume "whichever runner picks it up first" for
|
|
platform-specific work.
|
|
|
|
## When CI runs
|
|
|
|
- On every push to a PR branch (per branch naming in `GITEA.md`).
|
|
- On merge to `main`.
|
|
- Not on pushes to `main` directly, because pushes to `main` directly shouldn't happen
|
|
(`GITEA.md`) — if CI catches one, that's itself a signal worth flagging to DevOps.
|
|
|
|
## What a passing run means
|
|
|
|
A passing ACT Runner run means the build succeeded and the automated test suite passed. It does
|
|
**not** mean QA sign-off — those are separate gates in `WORKFLOW.md`. CI passing is necessary
|
|
for a PR to merge; it is not sufficient for a Task to close. Don't let "CI is green" be
|
|
mistaken for "verified" — see `EMPLOYEE_HANDBOOK.md` on the fabrication rule; reporting a task
|
|
done because CI passed, without QA verification, is exactly the kind of shortcut that rule
|
|
exists to prevent.
|
|
|
|
## Failure policy
|
|
|
|
- A failed run blocks merge, full stop — no manual override by the PR author.
|
|
- The engineer who owns the PR is responsible for the fix, not DevOps, unless the failure is
|
|
infrastructure-level (runner offline, environment misconfiguration) rather than code-level.
|
|
- DevOps triages ambiguous failures (is this the code or the pipeline?) when the PR author can't
|
|
tell — that's a legitimate escalation, not a stall.
|
|
|
|
## Retry policy
|
|
|
|
- A CI failure is retried once automatically if the failure signature matches a known-flaky
|
|
pattern the DevOps Engineer has documented (record these in `memory/lessons-learned.md` as
|
|
they're identified, so the list doesn't live only in someone's head).
|
|
- Anything else is not auto-retried — a red run is investigated, not re-rolled until it happens
|
|
to go green. Re-running a failing job hoping for a different answer is the CI equivalent of
|
|
the fabrication rule violation in `EMPLOYEE_HANDBOOK.md`.
|
|
|
|
## Deployment policy
|
|
|
|
- ACT Runner's scope here is build/test validation, not production deployment automation —
|
|
deployment pipelines beyond CI are a DevOps Engineer responsibility to design and document
|
|
per project in that project's `PROJECT.md`, referencing this file for the CI contract they
|
|
build on top of.
|
|
- Any workflow that deploys to a real environment (not just runs tests) requires a Security
|
|
Engineer review of the workflow file itself, since CI credentials and deploy targets are a
|
|
supply-chain surface (`SECURITY.md`).
|
|
|
|
## Ownership
|
|
|
|
DevOps Engineer owns `.gitea/workflows` (or equivalent) configuration across project
|
|
repositories. Changes to shared CI configuration that affect multiple projects should be
|
|
documented as an ADR (`DECISIONS.md`) if they change how *all* projects validate code, not just
|
|
one.
|