cicd-pipeline

cicd-pipeline — generate & maintain CI/CD for Nomad/PM2 microservices

This skill builds and maintains GitHub Actions CI/CD for repos that deploy to a Nomad or PM2 host, on VPS or AWS (EC2). It is the operational companion to microservice-devops: the deploy steps follow that skill's doctrine; this skill owns the pipeline around them.

Server- and domain-agnostic. Never hardcode IPs, hostnames, domains, tokens, registries, or credentials into a workflow. Everything environment-specific is a GitHub secret or environment variable, referenced by name. The skill sets those up via gh; it never writes secret values into files.

Supported matrix (current scope)

Infra target	Orchestration	Notes
VPS	Nomad or PM2	host behind a provider firewall is common
AWS (EC2)	Nomad or PM2	EC2 instance running Nomad/PM2 — not ECS/Fargate

AWS here means Opsi 1: an EC2 host running the same Nomad/PM2 stack. The deploy mechanism is identical to VPS; only credentials/networking differ (see references/infra-targets.md). ECS/Fargate/Lambda are out of scope.

Decision tree (always run Step 0 first)

Step 0  Detect existing CI/CD + context
        ├─ .github/workflows/*.yml present?
        ├─ deploy target hints: *.nomad → Nomad, ecosystem.config.js → PM2
        └─ gh auth + repo access OK?  (gh auth status; gh repo view)
              │
   ┌──────────┴───────────┐
   │ NO CI/CD exists      │ CI/CD already exists
   ▼                      ▼
Interview (Step 1)     Ask: new business/client, or edit? (Step 2)
   │                      ├─ new client → generate one ci/clients/<name>.yml
   ▼                      │              + register its secrets via gh (no
Generate (Step 3)         │              pipeline-logic change) — see multi-client
                          └─ edit       → modify existing workflow/config

Step 1 — Interview (only when no CI/CD exists)

Ask these, in order, using structured questions (one decision per question). Do NOT assume — auto-detected values are confirmed, not taken silently. Full wording and conditional logic in references/interview-flow.md.

1. Infra target: VPS or AWS (EC2)?
2. Orchestration: Nomad or PM2? (offer the auto-detected default)
3. Environments: which of dev / staging / prod? (subset is fine)
4. Single or multi-client? (explain if unsure — see references/multi-client.md)
5. Trigger convention: offer choices, don't force one (see rule #4).

Step 2 — Existing CI/CD (when workflows already present)

Ask a single branching question: add a pipeline for a new business/client, or edit the existing pipeline? Then follow references/existing-cicd.md. Adding a client must NOT rewrite working pipeline logic (rule #5).

Step 3 — Generate

• Write workflow(s) under .github/workflows/.
• Set up GitHub Environments and secrets via gh (rule #2).
• For multi-client, emit ci/clients/<name>.yml config + matrix workflow.
• Deploy steps follow the orchestration's doctrine: generate-nomad.md / generate-pm2.md.
• Print a secrets checklist the user must populate (values are never written by the skill).

Hard rules (apply always)

1. GitHub Actions, driven by gh. Generate workflows AND create the Environments/secrets via the gh CLI. Precondition: gh auth status succeeds and the user has admin/maintain rights on the repo (verify with gh repo view / gh api repos/:owner/:repo perms). If not, stop and tell the user what access they need — do not produce a half-set-up pipeline.
2. Secrets are never hardcoded. No IP/host/domain/token/registry literal in any workflow or config file. Use ${{ secrets.NAME }} / environment vars set via gh secret set. The skill outputs a checklist of names to populate; it does not write the values.
3. Prod is gated. The prod environment gets required reviewers (an approval gate) via gh. Prod never auto-deploys without that gate. dev/staging may auto-deploy per the chosen trigger convention.
4. Triggers are a choice, not a mandate. Offer the user convention options (e.g. branch develop→dev, main→staging, tag v*→prod; OR environment-pick on manual workflow_dispatch; OR PR-merge gates). Record the chosen mapping; make it visible at the top of the workflow.
5. Multi-client is config-driven, never copy-paste. One workflow + one config file per client under ci/clients/<name>.yml, consumed by a matrix. "New business" = add one config file + its secrets; pipeline logic is untouched. See references/multi-client.md.
6. Reuse the ops doctrine. Deploy steps must match microservice-devops: Nomad = build → push image → nomad job run; PM2 = build → sync → pm2 reload. Do not invent a divergent deploy path.
7. Idempotent setup. Re-running the skill should detect what already exists (gh secret list, gh api .../environments, existing workflow files) and only add what's missing — never blindly overwrite a working pipeline without confirming (rule #2 of microservice-devops: confirm prod-affecting changes).

What to read, and when

Situation	Read
Conducting the interview	references/interview-flow.md
VPS vs AWS(EC2) credential/networking differences	references/infra-targets.md
Creating environments/secrets via gh	references/github-setup.md
Generating a Nomad-deploy workflow	references/generate-nomad.md
Generating a PM2-deploy workflow	references/generate-pm2.md
Modeling/serving multiple clients	references/multi-client.md
Repo already has CI/CD (edit vs new client)	references/existing-cicd.md