Run any Skill in Manus with one click

ci-cd-delivery

Stars2

Forks1

UpdatedJune 29, 2026 at 15:10

Standardise the application-repo Continuous Delivery side of Meaningfy systems — the deploy trigger, the reusable deploy mechanism, and the release/image standard. Use to set up a CD/deploy workflow, release and push a versioned Docker image to a registry (recommended GHCR, tagged by semver + git sha), standardise or migrate the deploy trigger, kill the duplicated SSH/bastion/rsync/.env deploy block by consuming the canonical reusable workflow, or understand the three-repo deploy model. CI (build, test, lint, coverage, architecture, docs publish) is NOT here — that is owned by project-setup; this skill owns only CD + release + the delivery contract. Trigger on "set up CD / deploy workflow", "release and push a versioned image", "GHCR image build", "standardise the deploy trigger", "migrate the duplicated deploy block", "how do we deploy this repo".

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

meaningfy-ws

meaningfy-ws/skillery

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

6 files

SKILL.md

readonly

More from this repository

same repository

meaningfy-git-workflow

meaningfy-ws/skillery

Meaningfy git and GitHub conventions — Conventional Commits (imperative, no trailing punctuation), branch naming, rebase/merge etiquette, the pull-request workflow, free-tier GitHub constraints, and dev-environment hygiene. Use when committing, branching, opening or maintaining a PR, or setting up a development environment for a Meaningfy project.

2026-07-102

architecture

meaningfy-ws/skillery

System-level solution architecture — C4 levels (Context, Container, Component, Code), ArchiMate and UML notations, ADRs, and contracts (OpenAPI/AsyncAPI/LinkML). Use for system and solution design, architecture documentation, and architectural decision-making. Distinct from code structure inside a service (see the cosmic-python skill).

2026-07-102

bdd-gherkin

meaningfy-ws/skillery

Write BDD Gherkin feature files and fabricate test data from a specification. Use to project a use case catalogue (Cockburn White/Blue) or turn acceptance criteria or an EPIC into business-language `.feature` scenarios — Scenario Outline with Examples, explicit edge cases, no implementation detail, traced back to use cases. Trigger on "write Gherkin", "write feature files", "BDD scenarios for this acceptance criterion", "derive scenarios from use cases", "fabricate test data".

2026-07-102

conceptual-modelling

meaningfy-ws/skillery

Build and evolve a living, representation-agnostic conceptual model for a product (programming) project — the domain's entities, attributes, relationships, and meaning — and choose how it is rendered. Use to model the domain, do conceptual data modelling in UML, run ontology-engineering at the concept level (stable-IRI policy, vocabulary reuse), decide the model *source* (LinkML directly vs model2owl-first), set up a conceptual model, or run terminology/definitions/glossary management. Trigger on "model the domain", "conceptual/UML data model", "set up conceptual model", "which model source", "ontology/terminology management", "ubiquitous language glossary". For the LinkML craft itself (authoring, generation, gates) see linkml-engineering; for generic modelling conventions see modelling-conventions. Conditional: applies to product-development repos that build software; a doc-only/non-product repo does not need it.

2026-07-102

cosmic-python

meaningfy-ws/skillery

Clean Architecture and Cosmic Python guidance for well-tested, layered Python systems. Use for designing Python projects with layered architecture (models, adapters, services, entrypoints), enforcing Clean Code and SOLID principles, testing strategies (unit tests, BDD, Gherkin), CI/CD setup (pytest, tox, importlinter), and architectural decision-making (ADRs). Applicable to systems requiring strict boundary enforcement, clean separation of concerns, and comprehensive test coverage.

2026-07-102

linkml-engineering

meaningfy-ws/skillery

The operational LinkML craft, downstream of an existing model or spec — never greenfield. Use to derive a LinkML schema from a UML model, a text spec, a model2owl output, or another existing model; to author/refine it (reusable slots, the URI-as-datatype artifice, implicit class_uri/slot_uri, enums, schema-level constraints); to generate the full target set (Pydantic/JSON Schema/OWL/SHACL/TS/SQL) with custom templates and make-target automation including diagrams; and to establish LinkML quality gates. Trigger on "write/derive a LinkML schema", "generate models/OWL/SHACL from LinkML", "custom Pydantic template", "LinkML quality gates", "per-module generation", "make generate-models". Reuses modelling-conventions for generic craft; defers the model concept to conceptual-modelling. Not an ontology-authoring skill.

2026-07-102

name	ci-cd-delivery
description	Standardise the application-repo Continuous Delivery side of Meaningfy systems — the deploy trigger, the reusable deploy mechanism, and the release/image standard. Use to set up a CD/deploy workflow, release and push a versioned Docker image to a registry (recommended GHCR, tagged by semver + git sha), standardise or migrate the deploy trigger, kill the duplicated SSH/bastion/rsync/.env deploy block by consuming the canonical reusable workflow, or understand the three-repo deploy model. CI (build, test, lint, coverage, architecture, docs publish) is NOT here — that is owned by project-setup; this skill owns only CD + release + the delivery contract. Trigger on "set up CD / deploy workflow", "release and push a versioned image", "GHCR image build", "standardise the deploy trigger", "migrate the duplicated deploy block", "how do we deploy this repo".
license	Apache 2.0
metadata	{"category":"engineering"}

CI/CD Delivery

Overview

Meaningfy's deploy architecture is decoupled across three repos. This skill standardises the application-repo side of Continuous Delivery — the only side teams own day to day — and documents the contract to the two infrastructure repos without restating their runbooks.

It carries the delivery contract (how an app repo asks for a deploy and ships a release), a reusable-mechanism pointer + illustrative template, and a release/image standard. It owns CD only. Everything CI — build, unit/integration tests, lint, coverage, architecture guardrails, docs publish — is owned by project-setup. The two never overlap.

C1 — review with DevOps before adoption. The §6 decisions below are DevOps's to ratify. Do not contradict cloud-infrastructure / infrastructure-stacks runbooks, Vaultwarden, or the bastion procedure — treat them as the authoritative boundary. C2 — never put secrets in the repo or this skill. Every template carries placeholders only.

The three-repo model

Full detail in references/delivery-model.md. The mental model:

Repo	What it does	Automation	This skill
`cloud-infrastructure`	Terraform (Hetzner fleet, AWS sandbox) + Ansible (VM config, bastion users). Provisions/configures VMs once.	DevOps-manual (`terraform apply`, `ansible-playbook`)	Documents the boundary only — out of automation scope
`infrastructure-stacks`	Docker Compose stacks (one dir per stack), deployed to VMs by GitHub Actions: assemble `.env` from Secrets, rsync to the VM, `docker compose up -d`.	GitHub Actions	Documents the contract the app repo calls into
Application repos (e.g. `ted-rdf-conversion-pipeline`, `entity-resolution-service`)	Build/test the app and trigger its deployment.	GitHub Actions	OWNS and standardises this side

Routine deploys use rsync, not git-pull and not interactive SSH. The deploy workflow is the single auditable place where .env is assembled and the stack is brought up.

The secrets model

Full flow, rotation, and break-glass in references/secrets-model.md. The invariants:

Secrets never live in the repo (C2) — not in code, not in this skill, not in committed files.
Vaultwarden is the source of truth. GitHub Secrets are the deployment copy of those values, scoped to the repo/environment that deploys.
The deploy workflow is the only place .env is assembled (from GitHub Secrets) and rsync'd to the VM. Explicit, auditable, no git-pull, no secret-bearing files in the repo.
Rotation: rotate in Vaultwarden → update the matching GitHub Secret → re-trigger the deploy.
Break-glass (bastion / SSH) is owned by the DevOps runbook — referenced, never duplicated here.

The application-repo CD standard

This is what the skill prescribes for the app-repo side. Three parts: the trigger contract, the reusable mechanism, and the release/image standard.

1. Deploy-trigger contract (R3)

Today three divergent patterns exist across repos (push-on-path to shared stacks; an in-repo self-hosted runner; cross-repo workflow_dispatch). One standard, the rest are legacy-to-migrate.

Recommended default (pending DevOps §6 ratification): an app repo triggers a deploy by a cross-repo workflow_dispatch / repository_dispatch into infrastructure-stacks, or by consuming the devops-toolkit reusable workflow. It does not carry its own bespoke deploy glue.
Legacy to migrate: push-on-path against shared stacks, and the in-repo self-hosted runner. Both are named in references/delivery-model.md with their migration target.

2. Reusable deploy mechanism (R4)

The SSH/bastion/rsync/.env block is currently copy-pasted ~7× across repos. A devops-toolkit reusable op-delivery.yml already exists and ted-rdf-conversion-pipeline uses it — proof the pattern works.

The single runnable source of truth is the devops-toolkit reusable workflow. App repos uses: it. Skillery never hosts a second runnable copy — that is exactly the duplication this skill exists to kill.
The template in references/deploy-workflow-template.md is illustrative / teaching only: it shows the shape of the caller and how inputs/secrets map, and points at the canonical devops-toolkit source.

3. Release + image standard (R5)

Today no repo pushes a versioned image to a registry — all build on the VM from source, so there is no pinned, rollback-able artifact. The standard (template in references/release-image-template.md):

Build a Docker image, tag by semver + git sha, push to a registry (recommended GHCR).
Version source = git tag / GitHub release → image tag → optional changelog.
Stacks then pull a pinned versioned image instead of building on the VM — giving repeatable, rollback-able deploys.

§6 — DevOps decisions to confirm (NOT yet ratified)

These are recommendations to present to DevOps, not settled policy. Mark them as such wherever you act on them.

Deploy-trigger standard — recommended: the devops-toolkit reusable workflow (already exists; removes the duplication centrally).
Registry-pushed versioned images — recommended: adopt GHCR + semver/sha. Biggest current gap; it is what makes deploys rollback-able.
Home of the reusable deploy mechanism — recommended: centralise in devops-toolkit; all repos uses: it.

Until DevOps ratifies these, treat the recommendations as proposals: a deployable repo gets a clearly-marked TODO stub plus the boundary docs, not a rendered runnable deploy workflow.

Migration runbook

A concrete per-repo PR recipe lives in references/migration-runbook.md: replace the inline ~7× rsync/bastion block with uses: the reusable mechanism, map inputs/secrets, verify. A team can execute it without re-deriving the pattern.

Projection seam (→ project-setup, EPIC-09)

project-setup scaffolds these CD/release templates only for a deployable project, and only renders the chosen template after DevOps ratifies §6. Until then a deployable repo receives a clearly-marked TODO stub plus the boundary docs — never a half-guessed runnable deploy workflow. This skill owns the content of those templates; project-setup owns when and into what repo they are projected.

Boundary & Related Skills

Owns: the application-repo CD side — the deploy-trigger contract, the reusable-mechanism pointer + illustrative template, the release/image standard (semver + git sha → GHCR), and the per-repo migration runbook. Delegates: CI (build, test, lint, coverage, architecture guardrails, docs publish) → project-setup; code layering / structure → cosmic-python. Documents-only (authoritative boundary, never automated or duplicated here): cloud-infrastructure (Terraform/Ansible), infrastructure-stacks (Compose stacks + deploy Actions), Vaultwarden (secret source of truth), and the bastion/SSH break-glass procedure. Related: project-setup, cosmic-python, meaningfy-release — the release lifecycle (versioning, release notes, PyPI publish, the release/hotfix runbook); it cites this skill for the GHCR image path and does not restate it.