cicd
Skill1 starsChanged 7 months agoMITView on GitHub
CI/CD pipeline design with Harness Drone. Use when: creating .drone.yml pipelines, designing build/test/deploy stages, adding code coverage, publishing artifacts, configuring scheduled runs, applying CI/CD best practices, auditing existing pipelines for gaps, or improving pipeline efficiency and reliability. Covers linting gates, test parallelism, coverage thresholds, Docker image builds, secret management, and deployment strategies.
- Reads credentials
- Installs packages
8 other projects use a version of this.
Adopted by
Most recently taken up by
- NVIDIA-NeMo/RLtheir own version, first seen Nov 1, 2026
- nguyenquocan0101/skillstheir own version, first seen Oct 13, 2026
- NVIDIA-NeMo/Automodeltheir own version, first seen Oct 8, 2026
- NVIDIA-NeMo/Megatron-Bridgetheir own version, first seen Oct 8, 2026
- Xia-Ataraxia/craft-skillstheir own version, first seen Jul 3, 2026
- saitarrun/Devforge-aitheir own version, first seen Jun 20, 2026
Used with
Projects with it also use build-and-dependency and pr-review.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
NVIDIA-NeMoSkillbuild-and-dependency
Dev environment setup for Megatron Bridge — container-based development, uv package management, lockfile regeneration, adding dependencies, Slurm container usage, and common build pitfalls.
Also in 3 projects that use this
MicrosoftSkillpr-review
Verify the technical accuracy of a vscode-docs pull request against the VS Code source code in microsoft/vscode. Use when reviewing a docs PR for factual correctness: setting names, command IDs, default values, API shapes, keybindings, versioned availability, and described behavior.
Also in 3 projects that use this
Other versions8 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 8
- NVIDIA-NeMo/RL★ 2.1ksame name
- NVIDIA-NeMo/Automodel★ 1.1ksame name
- NVIDIA-NeMo/Megatron-Bridge★ 986same name
- saitarrun/Devforge-ai★ 4same name
- ffsshhttiikk/opencode-agents-skills★ 2same name
- nguyenquocan0101/skills★ 1same name
- sudarshanpjadhav/finggu-skills★ 0same name
- Xia-Ataraxia/craft-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository42 other files it gives its agents.
- accessibility-testingSkill
- alternatives-analysisSkill
- anomaly-detectionSkill
- api-designSkill
- async-messagingSkill
- caching-strategiesSkill
- chartsSkill
- code-reviewSkill
- commsSkill
- critical-feedbackSkill
- data-analysisSkill
- databaseSkill
- data-migrationsSkill
- data-visualizationSkill
- dependency-managementSkill
- dockerSkill
- error-handlingSkill
- feature-flagsSkill
- git-workflowSkill
- goalsSkill
- ide-setupSkill
- large-changeSkill
- logging-metricsSkill
- markdown-docsSkill
- mcp-serverSkill
- meeting-agendasSkill
- okrsSkill
- presentationsSkill
- product-managementSkill
- prompt-writingSkill
- pythonSkill
- reclassificationSkill
- release-managementSkill
- retrospectivesSkill
- roadmap-planningSkill
- securitySkill
- stakeholder-commsSkill
- statisticsSkill
- status-updatesSkill
- testingSkill
- ticket-writingSkill
- typescriptSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. 0 are common, 7 are distinctive, and 7 are very specific to this project.
0
Common
Most of the 8 edited versions we read keep these.
7
Distinctive
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 32
Every pipeline is kind: pipeline, type: docker.
- Distinctive: line 102
Use the exact same tool versions in CI and local dev.
- Very specific: line 137
Every test step installs only the dependencies it needs — no global requirements.txt.
- Very specific: line 138
Use --tb=short for concise failure output in CI.
- Very specific: line 139
Use --cov-fail-under=80 to enforce minimum coverage (see coverage section).
- Distinctive: line 140
If a test step needs system packages, use a custom Docker image (see build stage).
- Very specific: line 141
Never skip tests in CI with @pytest.mark.skip unless there's a tracked issue.
- Distinctive: line 213
Use the Drone Docker plugin for building and pushing images:
- Very specific: line 234
Always tag with both latest and a commit-specific tag (short SHA or semver).
- Distinctive: line 236
Use multi-stage Dockerfiles to keep published images small (see docker skill).
- Distinctive: line 375
Always include error notifications (webhook, email) for scheduled jobs.
- Distinctive: line 442
Add a dedicated release pipeline that triggers only on semver tags.
- Distinctive: line 506
If the project stores a version in a file, add a validation step to prevent drift:
- Very specific: line 526
Use this checklist when reviewing any .drone.yml:
“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
CI/CD Standards (Harness Drone)
When to Use
- Creating or modifying
.drone.ymlpipelines - Designing build, test, and deploy stages
- Adding code coverage reporting
- Publishing Docker images or other artifacts
- Configuring secrets, triggers, or cron schedules
- Reviewing pipeline design for correctness and efficiency
- Auditing an existing pipeline for missing stages (lint, test, coverage, security scan)
- Improving pipeline speed (parallelism, caching, fail-fast ordering)
Platform
- Harness Drone (OSS / Community Edition) running Docker pipelines.
- Pipeline config lives in
.drone.ymlat the repo root. - Every pipeline is
kind: pipeline,type: docker.
Core Principles
- Pipeline as code —
.drone.ymlis version-controlled, reviewed, and tested like application code. - Fail fast — cheapest checks (lint, format) run first. Expensive steps (integration tests, builds) run only if cheap checks pass.
- Hermetic builds — every step starts from a known Docker image. No reliance on host state.
- Secrets never in YAML — use Drone secrets (
from_secret). No env var values in pipeline definitions. - Idempotent deploys — running the same pipeline twice produces the same result.
Pipeline Architecture
Separate concerns into distinct pipelines (Drone --- document separators):
| Pipeline | Trigger | Purpose |
| lint-and-test | push, pull_request on main | Quality gate — must pass before merge |
| build-and-publish | push to main (post-merge) | Build artifacts, push images |
| deploy | push to main OR manual promote | Ship to staging/production |
| scheduled | cron | Recurring tasks (backups, scans, syncs) |
Pipeline Ordering
# Pipeline 1: Gate — blocks merge if it fails
kind: pipeline
name: lint-and-test
trigger:
branch: [main]
event: [push, pull_request]
# Pipeline 2: Build — only on merged code
kind: pipeline
name: build-and-publish
trigger:
branch: [main]
event: [push]
depends_on: [lint-and-test]
# Pipeline 3: Deploy — after build succeeds
kind: pipeline
name: deploy
trigger:
branch: [main]
event: [push]
depends_on: [build-and-publish]Stage 1: Lint and Format
Linting is the fastest, cheapest check. It runs first and blocks everything else.
steps:
- name: lint
image: python:3.12-slim
commands:
- pip install ruff
- ruff check .
- ruff format --check .Rules:
- Lint checks are non-negotiable — no
|| true, noallow_failure. - Use the exact same tool versions in CI and local dev.
- For multi-language repos, run language-specific linters in parallel steps.
| Language | Lint step |
| Python | ruff check . && ruff format --check . |
| TypeScript | npx prettier --check . && npx eslint . |
| YAML / Markdown | npx prettier --check "**/*.{yml,yaml,md}" |
| Dockerfile | hadolint docker/*.Dockerfile |
Stage 2: Test
Tests run after lint passes. Use parallel steps per test target to maximize throughput.
- name: test-shared
image: python:3.12-slim
commands:
- pip install pytest pytest-cov python-dotenv
- pytest shared/ -v --tb=short
- name: test-my-script
image: python:3.12-slim
commands:
- pip install pytest pytest-cov -r scripts/my_script/requirements.txt
- >-
pytest scripts/my_script/ -v --tb=short
--cov=scripts/my_script
--cov-report=term-missing
--cov-fail-under=80Rules:
- Every test step installs only the dependencies it needs — no global
requirements.txt. - Use
--tb=shortfor concise failure output in CI. - Use
--cov-fail-under=80to enforce minimum coverage (see coverage section). - If a test step needs system packages, use a custom Docker image (see build stage).
- Never skip tests in CI with
@pytest.mark.skipunless there's a tracked issue.
Test Parallelism
Drone runs steps within a pipeline in parallel by default. Steps that depend on each other need explicit depends_on:
steps:
- name: lint
...
- name: test-unit
depends_on: [lint]
...
- name: test-integration
depends_on: [lint]
...Lint → then unit + integration in parallel → then build (depends on both).
Stage 3: Code Coverage
Configuration
- name: test-with-coverage
image: python:3.12-slim
commands:
- pip install pytest pytest-cov
- >-
pytest
--cov=src
--cov-report=term-missing
--cov-report=xml:coverage.xml
--cov-fail-under=80Coverage Rules
| Rule | Value | Rationale |
| Minimum threshold | 80% | Floor — not a target. New code should aim higher. |
| Fail the build | Yes | --cov-fail-under=80 makes the step exit non-zero |
| Report format | term-missing + xml | Terminal for quick review, XML for tooling integration |
| What counts | Tested lines / total lines | Branch coverage is ideal but line coverage is the practical minimum |
Coverage Anti-Patterns
- Don't chase 100% — diminishing returns above 90%. Focus coverage on business logic and error paths.
- Don't exclude files just to raise the number — if code exists, it should be tested.
- Don't count generated code — exclude auto-generated files in
.coveragercorpyproject.toml.
[tool.coverage.run]
source = ["src", "scripts"]
omit = ["*/test_*", "*/__pycache__/*"]
[tool.coverage.report]
fail_under = 80
show_missing = trueStage 4: Build Artifacts
Docker Images
Use the Drone Docker plugin for building and pushing images:
- name: build-and-push
image: plugins/docker
settings:
dockerfile: docker/my-service.Dockerfile
repo: ${DRONE_REPO_OWNER}/my-service
tags:
- latest
- ${DRONE_COMMIT_SHA:0:8}
username:
from_secret: docker_username
password:
from_secret: docker_password
when:
branch: [main]
event: [push]Rules:
- Always tag with both
latestand a commit-specific tag (short SHA or semver). - Build images only on main branch, never on PRs (PRs run lint + test only).
- Use multi-stage Dockerfiles to keep published images small (see docker skill).
- Store registry credentials as Drone secrets, never in pipeline YAML.
- For release builds, prefer semver tags over SHA — see the release pipeline section below.
Python Packages
For internal Python packages:
- name: build-package
image: python:3.12-slim
commands:
- pip install build
- python -m build
when:
branch: [main]
event: [push]Stage 5: Deploy
Deployment Strategies
| Strategy | When to use | Risk |
| Direct deploy | Homelab scripts, internal tools | Low — rollback is a git revert + re-deploy |
| Blue-green | Services with zero-downtime requirement | Medium — need two environments |
| Canary | User-facing APIs with high traffic | Low — gradual rollout, auto-rollback |
| Manual promote | Production deployments requiring approval | Lowest — human gate |
Homelab Deploy Pattern
For homelab scripts running on a schedule, deployment means the cron pipeline pulls the latest image:
---
kind: pipeline
name: deploy-to-homelab
trigger:
branch: [main]
event: [push]
depends_on: [build-and-publish]
steps:
- name: deploy
image: appleboy/drone-ssh
settings:
host:
from_secret: deploy_host
username:
from_secret: deploy_user
key:
from_secret: deploy_ssh_key
script:
- cd /opt/homelab && docker compose pull && docker compose up -dServerless Deploy Pattern
For AWS Lambda services:
- name: deploy-staging
image: node:20-slim
environment:
AWS_ACCESS_KEY_ID:
from_secret: aws_access_key_id
AWS_SECRET_ACCESS_KEY:
from_secret: aws_secret_access_key
commands:
- npm ci
- npx serverless deploy --stage dev
when:
branch: [main]
event: [push]
- name: deploy-production
image: node:20-slim
environment:
AWS_ACCESS_KEY_ID:
from_secret: aws_access_key_id
AWS_SECRET_ACCESS_KEY:
from_secret: aws_secret_access_key
commands:
- npm ci
- npx serverless deploy --stage prod
when:
event: [promote]
target: [production]Promote to production manually: drone build promote <repo> <build> production
Secrets Management
- All credentials go through Drone secrets —
from_secret: key_name. - Store secrets via
drone secret addCLI or Drone UI, never in.drone.yml. - Secrets are not exposed in logs, pull request builds, or fork builds by default.
- For multi-repo secrets (Docker Hub creds), use organization-level secrets.
environment:
API_KEY:
from_secret: api_key # correct
# API_KEY: "sk-1234..." # NEVER — exposed in version controlCron / Scheduled Pipelines
For recurring tasks (backups, health checks, cleanup):
---
kind: pipeline
name: backup-daily
trigger:
event: [cron]
cron: [backup-daily]
steps:
- name: run-backup
image: python:3.12-slim
environment:
BACKUP_SOURCE:
from_secret: backup_source
commands:
- pip install -r scripts/backup/requirements.txt
- python -m scripts.backup.backupRules:
- Cron pipeline names match the Drone cron job name for clarity.
- Cron pipelines should not share triggers with CI pipelines — use separate
---documents. - Always include error notifications (webhook, email) for scheduled jobs.
Step Design Best Practices
Base Images
| Language | Image | Notes |
| Python | python:3.12-slim | Minimal, fast pull |
| Node.js | node:20-slim | For Serverless, frontend builds |
| Docker builds | plugins/docker | Drone's Docker build plugin |
| SSH deploy | appleboy/drone-ssh | Remote execution via SSH |
| General CLI | alpine:3.19 | When you just need curl, jq, etc. |
Caching
Drone Docker pipelines don't have built-in caching. Options:
- Pre-built images with dependencies baked in — fastest, most reliable.
- Drone volume (
/tmp/cachemounted) — works for single-node setups. - Layer caching for Docker builds — use
plugins/dockerwithcache_from.
Notifications
- name: notify-failure
image: plugins/slack
settings:
webhook:
from_secret: slack_webhook
channel: ci-alerts
template: >
{{repo.name}} build {{build.number}} failed on {{build.branch}}.
{{build.link}}
when:
status: [failure]Performance Pipeline
Integrate performance testing into CI with a tiered approach (see performance-testing and ui-performance skills for full details):
| Trigger | Test type | Purpose |
| Every PR | Smoke (k6, 1 min, 5 VUs) | Catch gross regressions cheaply |
| Release tag | Load + Stress (k6, 15 min) | Validate capacity before shipping |
| Release tag | Lighthouse audit | Enforce frontend performance score ≥ 80 |
| Weekly cron | Soak (k6, 1-4 hours) | Detect memory leaks and connection exhaustion |
- name: perf-smoke
image: grafana/k6:latest
commands:
- k6 run --duration=1m --vus=5 tests/perf/smoke.js
depends_on: [test]Release Pipeline
Tag-Triggered Releases
Add a dedicated release pipeline that triggers only on semver tags. This separates release builds from regular CI (see release-management skill for full versioning conventions):
---
kind: pipeline
name: release
trigger:
event: [tag]
ref: ["refs/tags/v*"]
steps:
- name: validate-tag
image: alpine:3.19
commands:
- |
TAG="${DRONE_TAG}"
if ! echo "$TAG" | grep -qE '^v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.]+)?$'; then
echo "ERROR: Tag '$TAG' does not match semver format"
exit 1
fi
echo "Valid semver tag: $TAG"
- name: lint
image: python:3.12-slim
commands:
- pip install ruff
- ruff check .
- ruff format --check .
depends_on: [validate-tag]
- name: test
image: python:3.12-slim
commands:
- pip install pytest pytest-cov
- pytest -v --tb=short --cov=src --cov-fail-under=80
depends_on: [validate-tag]
- name: build-and-publish
image: plugins/docker
settings:
repo: ${DRONE_REPO_OWNER}/my-service
tags:
- latest
- ${DRONE_TAG}
- ${DRONE_TAG##v}
username:
from_secret: docker_username
password:
from_secret: docker_password
depends_on: [lint, test]Release Pipeline Rules
| Rule | Rationale |
| Validate tag format | Reject accidental or malformed tags before building |
| Re-run lint + test | Tag may point to a commit that wasn't the latest CI run |
| Tag with semver | v1.5.0 and 1.5.0 alongside latest for flexibility |
Skip latest for pre-releases | v2.0.0-beta.1 should not be tagged latest |
| Version-file validation | Ensure pyproject.toml / package.json version matches the tag |
Version-File Validation Step
If the project stores a version in a file, add a validation step to prevent drift:
- name: validate-version
image: python:3.12-slim
commands:
- |
FILE_VERSION=$(python -c "import tomllib; print(tomllib.load(open('pyproject.toml','rb'))['project']['version'])")
TAG_VERSION="${DRONE_TAG#v}"
if [ "$FILE_VERSION" != "$TAG_VERSION" ]; then
echo "ERROR: pyproject.toml version ($FILE_VERSION) != tag ($TAG_VERSION)"
exit 1
fi
depends_on: [validate-tag]Pipeline Checklist
Use this checklist when reviewing any .drone.yml:
| Check | What to verify |
| Fail fast | Lint/format steps run before test steps |
| No secrets in YAML | All credentials use from_secret |
| Pinned images | Step images use specific tags, not :latest |
| Test coverage | --cov-fail-under is set and enforced |
| PR safety | Build/deploy steps have when: event: [push] (not on PRs) |
| Cron isolation | Scheduled pipelines use separate --- documents |
| Dependencies | depends_on ensures correct ordering between pipelines |
| Notifications | Failure notifications are configured |
| Minimal installs | Each step installs only what it needs |
| Short SHA tags | Docker images tagged with commit SHA, not just latest |
| Release pipeline | Tag-triggered pipeline exists for semver releases |
| Tag validation | Release pipeline validates semver format before building |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

