New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

NGINX Ingress CI Pipelines

by nginx in nginx/kubernetes-ingress

Explains how the NGINX Ingress Controller's GitHub Actions workflows, reusable workflows, build matrices and release pipeline fit together across two repositories.

Apache-2.0Auto-check passedDevOps & Cloud

Install NGINX Ingress CI Pipelines

skills CLI
$ npx skills add nginx/kubernetes-ingress --skill nic-ci-pipelines -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install nginx/kubernetes-ingress nic-ci-pipelines --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/nginx/kubernetes-ingress.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.github/skills/nic-ci-pipelines .claude/skills/nic-ci-pipelines && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
nic-ci-pipelines
GitHub stars
5.1k
Token cost
~5.1k tokens
SKILL.md length
1,953 words
Files
1
Skills in repo
9
Repo updated
First seen
Licence
Apache-2.0

At a glance

Explains how the NGINX Ingress Controller's GitHub Actions workflows, reusable workflows, build matrices and release pipeline fit together across two repositories.

  • Works in 2 steps: Stage 1 (Prep / Creation)… → Stage 2 (Publish) (release-publish.yml /…
  • Debugging a failing NIC GitHub Actions workflow
  • SKILL.md covers Repository Split -- read this…, Workflow Architecture, Key Workflows and CI Patterns, plus 1 more section
  • Calls make, docker and go

What it does

The skill documents CI/CD for the NGINX Ingress Controller. Its first point is that workflow files are shared between an internal repository and the public one, and every job is gated on `github.repository`. The internal repository builds release images and binaries and stages them, while the public repository only publishes: it copies images from the staging registry with `skopeo`, publishes the Helm chart, and tags and publishes the GitHub release.

The public repository still builds images for PR testing and again on merge, but those go to a dev registry and are test artifacts, not release artifacts. `ci.yml` is the main orchestrator, running checks for format, lint, codegen, CRDs and chart version, plus a codegen verification that must produce no diff. A publish failure can be retried on its own because the images already exist in staging. The skill also covers matrix builds and a two-stage release architecture.

When your agent uses it

  • Debugging a failing NIC GitHub Actions workflow
  • Adding a step or changing a build matrix in the CI workflows
  • Working out which repository builds and which publishes a release

Example prompts

  • “Why does release-prep.yml do nothing when I dispatch it on the public repo?”
  • “Add a new variant to the build matrix in build-artifacts.yml.”
  • “The verify-codegen job fails with a diff. Tell me which generators to rerun.”

Workflow steps

2 steps, taken from the first numbered list in SKILL.md.

  1. Stage 1 (Prep / Creation) (release-prep.yml / release-prep-lts.yml) -- runs in nginx/kubernetes-ingress-internal
  2. Stage 2 (Publish) (release-publish.yml / release-publish-lts.yml) -- runs in nginx/kubernetes-ingress (public)

What it can do on your machine

Read from SKILL.md and the folder at commit 29a1a36. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • make
    • docker
    • go

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use docker, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

NGINX Ingress CI Pipelines loads about 5.1k tokens when it runs. Until then it costs about 69 tokens; SKILL.md has 1,953 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~69
When it runs · the whole SKILL.md, loaded when a task matches
~5.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from nginx/kubernetes-ingress at commit 29a1a36, republished under its Apache-2.0 licence (© nginx). 1,953 words, ~5,081 tokens.

Download SKILL.mdSave it as .claude/skills/nic-ci-pipelines/SKILL.md (or your agent's skills folder).
name
nic-ci-pipelines
description
CI/CD pipeline structure, GitHub Actions workflows, reusable workflow patterns, and matrix builds for NIC. Use when working on CI workflows, debugging build failures, adding new workflow steps, modifying build matrices, or understanding the release pipeline.

NIC CI/CD Pipelines

Repository Split -- read this first

Workflow files are shared between two repositories, and every job is gated on github.repository. The same file behaves differently depending on which repo runs it.

RepositoryOwnsGate string
nginx/kubernetes-ingress-internalRelease image and binary builds. Builds all OSS/Plus/NAP variants, stages them plus the Helm chart in the internal registry, signs binaries, uploads tarballs to Azuregithub.repository == 'nginx/kubernetes-ingress-internal'
nginx/kubernetes-ingress (public)Publishing only. Pulls prepped images from the internal staging registry and pushes them to every public registry, publishes the Helm chart, certifies UBI images, opens the operator PR, tags and publishes the GitHub releasegithub.repository == 'nginx/kubernetes-ingress'

Consequences:

  • release-prep.yml / release-prep-lts.yml are internal-repo only. They are the only workflows that build release images. Dispatching them on the public repo is a no-op -- every job skips.
  • release-publish.yml / release-publish-lts.yml are public-repo only. They never run docker build; oss-release.yml and plus-release.yml copy image manifests with skopeo from source_registry (default docker-mgmt-test.nginx.com) to the public targets.
  • The public repo still builds images for PR/CI testing (ci.yml -> build-artifacts.yml) and again on merge (image-promotion.yml calls build-artifacts.yml with force: true before tagging edge/stable). Both push to the GCR dev registry -- they are test artifacts, not release artifacts.
  • A publish failure is retryable on its own -- nothing needs rebuilding because the images already exist in the staging registry.
text
   internal repo                        public repo
   -------------                        -----------
   release-prep.yml                     release-publish.yml
     build-artifacts.yml                  oss-release.yml   (skopeo copy)
     push-prep-images  --> docker-mgmt-test.nginx.com --> GCR / Docker Hub / ECR Public / Quay / GHCR / NGINX Registry
     stage-helm-chart  --> oci://docker-mgmt-test...  --> publish-helm.yml (Helm repo + GHCR)
     binaries (SBOM, Cosign)                            certify-openshift-images (Pyxis)
     azure-upload      --> Azure blob                   operator (dispatch nginx-ingress-helm-operator/sync-chart.yml)
                                                        release-gate -> tag -> release-assets -> github-release

Workflow Architecture

The CI system uses GitHub Actions with extensive reusable workflow composition.

text
ci.yml (main CI orchestrator)                          [public repo]
  -> checks (format, lint, codegen, CRDs, chart version)
  -> verify-codegen (go mod tidy, make update-crds, make update-codegen, make telemetry-schema -- all must produce no diff)
  -> unit-tests, staticcheck, govulncheck
  -> build-artifacts.yml (reusable)   <- CI/test images only, pushed to GCR dev registry
       -> build-oss.yml (per-variant, matrix)
       -> build-plus.yml (per-variant, matrix)  <- also used for NAP variants
  -> package-tests, helm-tests
  -> setup-smoke.yml (reusable)
  -> smoke / e2e tests

image-promotion.yml (post-merge)                       [public repo]
  -> build-artifacts.yml (force: true)  <- rebuilds test images before promoting
  -> tags images edge/stable
  -> Trivy + DockerScout security scans
  -> publishes edge Helm charts to GHCR
  -> updates GitHub Release draft notes

release-prep.yml (dispatchable Stage 1: Creation)      [INTERNAL repo only]
  -> build-artifacts.yml (reusable)   <- the only release image build
  -> push-prep-images -> stages images in docker-mgmt-test.nginx.com
  -> stage-helm-chart -> stages Helm chart in oci://docker-mgmt-test.nginx.com/nginx-ic/helm
  -> binaries -> generates SBOM (Syft), signs (Cosign), creates tarballs
  -> azure-upload -> uploads signed tarballs to Azure blob storage

release-publish.yml (dispatchable Stage 2: Publish)    [PUBLIC repo only -- no builds]
  -> oss-release.yml (skopeo copy from source_registry: docker-mgmt-test.nginx.com)
  -> plus-release.yml (skopeo copy from source_registry: docker-mgmt-test.nginx.com)
  -> publish-helm.yml (publishes Helm chart to Helm repo & GHCR)
  -> certify-openshift-images (certifies UBI images on OpenShift / Pyxis)
  -> operator -> dispatches nginx-ingress-helm-operator/sync-chart.yml to raise the operator PR
  -> release-gate -> verifies all artifact publications succeed
  -> tag -> creates and pushes the vX.Y.Z git tag
  -> release-assets -> downloads tarballs from Azure and uploads to GitHub release draft
  -> github-release -> closes milestone and publishes the GitHub release draft
Two-Stage Release Architecture

Release pipelines are split into two independently dispatchable stages that run in different repositories:

  1. Stage 1 (Prep / Creation) (release-prep.yml / release-prep-lts.yml) -- runs in nginx/kubernetes-ingress-internal:
    • Builds binaries and container images (the only place release images are built)
    • Stages container images and Helm charts in the internal test registry (docker-mgmt-test.nginx.com)
    • Generates Syft SBOMs, signs artifacts with Cosign, and uploads release tarballs to Azure blob storage
    • Does not create git tags, publish public images, or publish the GitHub release
  2. Stage 2 (Publish) (release-publish.yml / release-publish-lts.yml) -- runs in nginx/kubernetes-ingress (public):
    • Copies prepped images from docker-mgmt-test.nginx.com to public registries (GCR, Docker Hub, ECR Public, Quay, GHCR, NGINX Registry) plus the marketplace registries (GCR Marketplace, ECR Marketplace, Azure Marketplace) for Plus
    • Publishes public Helm charts and certifies UBI images on OpenShift
    • Dispatches sync-chart.yml in nginx/nginx-ingress-helm-operator to raise the operator PR (requires a non-empty operator_version input, otherwise the job skips)
    • Verifies all prerequisites via release-gate
    • Creates and pushes the release git tag (vX.Y.Z or <lts_version>)
    • Downloads signed binaries from Azure blob storage and attaches them to the GitHub release draft
    • Closes the release milestone and publishes the GitHub release

Because the stages are decoupled and live in separate repos, a transient failure in publishing or external registry sync can be retried directly via release-publish.yml without rebuilding any images or binaries.

Key Workflows

Core CI & Testing
WorkflowTriggerPurpose
ci.ymlPR to main/release-*, merge_group, workflow_dispatchMain CI orchestrator: checks + build + test. Images built here are test images pushed to the GCR dev registry
lint-format.ymlPR to main/release-*, merge_groupFormat & lint checks (gofumpt, goimports, golangci-lint, actionlint, markdownlint, yamllint, workflow gating validation)
regression.ymlDaily cron (03:00 UTC), manual dispatchMulti-K8s-version regression matrix tests
single-image-regression.ymlManual dispatchRuns Python e2e tests on a single image variant and K8s version
build-base-images.ymlWeekday cron (04:30 UTC), manual, workflow_callRebuilds all base images (alpine, debian, ubi)
build-ubi-dependency.ymlPush to main touching build/dependencies/Dockerfile.ubi10, manualBuilds the UBI dependency image published to ghcr.io/nginx/dependencies/nginx-ubi
image-promotion.ymlPush to main/release-*, workflow_callRebuilds images via build-artifacts.yml (force: true), tags edge/stable, runs security scans, publishes GHCR edge chart
Release Workflows
WorkflowRepoTriggerPurpose
release-prep.ymlinternalManual dispatchStage 1: build artifacts, stage images and Helm chart in test registry (docker-mgmt-test.nginx.com), sign binaries, upload tarballs to Azure blob storage
release-publish.ymlpublicManual dispatchStage 2: copy staged images to public registries, publish Helm chart, certify UBI images, dispatch operator sync PR, create git tag, upload release assets, close milestone, publish GitHub release
release-prep-lts.ymlinternalManual dispatchLTS Stage 1: build LTS Plus images & binaries, stage in test registry, sign binaries, upload tarballs to Azure blob storage
release-publish-lts.ymlpublicManual dispatchLTS Stage 2: copy staged LTS Plus images to public registries, publish LTS Helm chart (nginx-ingress-lts), create git tag, attach release assets, close milestone, publish GitHub release
oss-release.ymlpublicManual dispatch, workflow_callCopies OSS images from staging registry to public registries via skopeo (called by release-publish.yml)
plus-release.ymlpublicManual dispatch, workflow_callCopies Plus/NAP images from staging registry to GCR, NGINX Registry and the GCR/ECR/Azure marketplaces via skopeo (called by release-publish.yml)
plus-release-lts.ymlpublicManual dispatch, workflow_callCopies LTS Plus images from staging registry to GCR and NGINX Registry (called by release-publish-lts.yml and update-docker-images.yml)
publish-helm.ymlbothManual dispatch, workflow_callPackages and publishes Helm charts to OCI registries (GHCR, docker-mgmt-test) or the public Helm repo
create-release-branch.ymlpublicManual dispatchCreates a new release-X.Y branch and bumps versions
release-pr.ymlpublicManual dispatchAutomates creation of release PRs for version updates and changelogs
version-bump.ymlpublicManual dispatchBumps IC_VERSION and HELM_CHART_VERSION across the repository
Reusable Build Workflows (called via workflow_call)
WorkflowPurpose
build-artifacts.ymlOrchestrates GoReleaser binary builds + multi-variant image build matrix
build-oss.ymlBuilds a single OSS image variant
build-plus.ymlBuilds a single Plus/NAP image variant (maps pkg-src-repo, pkg-src-waf, pkg-src-dos to docker build args)
build-single-image.ymlBuilds a single image variant on demand (manual dispatch)
build-test-image.ymlBuilds Python e2e test image (kic-test-image)
setup-smoke.ymlSets up Kind cluster and runs smoke tests
patch-image.ymlOS-level security patches on existing images
retag-images.ymlRe-tags images in GCR Dev Registry
Security, Compliance & Automation
WorkflowTriggerPurpose
codeql-analysis.ymlPush, PR, merge_groupGitHub CodeQL security analysis
scorecards.ymlWeekly cron (Sun 20:43 UTC), push to mainOpenSSF Scorecards security scanning
dependency-review.ymlPR to main/release-*, merge_groupGitHub Dependency Review for PRs
certify-ubi-image.ymlManual dispatch, calledRed Hat UBI certification for OpenShift (Pyxis)
f5-cla.ymlPR target, issue commentCLA Assistant check for PRs
external-pr.ymlIssue commentTriggers CI for external contributor PRs after review
cherry-pick.ymlIssue comment (/cherry-pick)Automated cherry-picking of PRs to release branches
renovate-build.ymlPR (opened, synchronize)CI validation for Renovate dependency updates
update-release-draft.ymlManual dispatch, pushAutomatically updates GitHub Release draft release notes from PRs
labeler.ymlpull_request_targetApplies PR labels from .github/labeler.yml config
issues.yamlIssue openedPosts the triage acknowledgement comment
Maintenance & Repository Hygiene
WorkflowTriggerPurpose
update-docker-images.ymlWeekly cron (Sun 01:00 UTC), manualRebuilds / updates Docker images with latest base packages
update-docker-sha.ymlManual dispatchUpdates pinned base image digests in Dockerfiles
dockerhub-description.ymlPush to mainUpdates description and README on Docker Hub
cache-update.ymlManual dispatchRefreshes Go binary and image build caches
pull-nap-images.ymlManual dispatchPulls/syncs NAP images from internal registry
stale.ymlDaily cron (01:30 UTC)Closes stale issues and PRs

CI Patterns

Matrix Builds

Image variants and test configurations are defined in JSON under .github/data/:

The matrix-images-*.json rows use build_os / image / tag_suffix and are checked by .github/scripts/validate-image-matrices.sh. See docs/developer/image-matrices.md for the schema and the checklist for adding an image.

  • matrix-images-oss.json: debian, alpine, ubi (amd64 + arm64)
  • matrix-images-plus.json: debian-plus, alpine-plus, alpine-plus-fips, ubi-10-plus
  • matrix-images-plus-lts.json: LTS Plus image definitions
  • matrix-images-nap.json: WAF v4/v5, DoS, UBI 10 (amd64 only). WAF images appear twice -- the unsuffixed entry pins nginx-agent v2 and the -agent suffixed entry pins v3. DoS images package Agent v3 by default under standard tags (unsuffixed and -ubi) and do not have -agent variants.
  • matrix-smoke-oss.json, matrix-smoke-plus.json, matrix-smoke-nap.json: Smoke test matrices
  • matrix-regression.json: Regression test matrix (K8s version combinations)
  • patch-images.json, patch-images-lts.json: Patch image definitions for patch-image.yml
Show full SKILL.md (757 more words)Show less
Caching Strategy
  • Go binaries: cached by go_code_md5 hash (computed in .github/scripts/variables.sh over all *.go, go.mod, go.sum, *.tmpl, version.txt)
  • Docker images: cached by docker_md5 hash (computed over build/, .github/data/version.txt, internal/configs/njs, internal/configs/oidc)
  • Build tags: build_tag (t-<md5>) and stable_tag (s-<md5>) determine image freshness
  • Stable images in GCR Dev Registry are checked before rebuilding to prevent redundant Docker builds
Change Detection & Optimization
  • docs_only detection in variables.sh identifies PRs touching only docs (*.md, docs/**, examples/**) and skips expensive image builds and integration tests.
Fork Awareness
  • forked_workflow variable gates authenticated operations. Forked PRs get local-only builds without secret access.
Concurrency
  • CI workflows use group: ${{ github.ref_name }}-<suffix> with cancel-in-progress: true.
  • Release workflows (release-prep.yml and release-publish.yml) share group: ${{ inputs.release_branch }}-release with cancel-in-progress: false to ensure a publish dispatch cannot overtake a prep in flight.
  • LTS release workflows (release-prep-lts.yml and release-publish-lts.yml) share group: ${{ inputs.release_branch }}-release-lts with cancel-in-progress: false.
Secrets & Authentication
  • Secrets are retrieved from Azure Key Vault via nginx/ci-self-hosted/.github/actions/get-from-vault using OIDC / Workload Identity -- not stored directly as GitHub repository secrets.
  • Google Cloud authentication uses Workload Identity Federation (google-github-actions/auth).
Version Source of Truth
  • .github/data/version.txt contains IC_VERSION and HELM_CHART_VERSION.
Generated-Artifact Gates

The verify-codegen job in ci.yml regenerates and then diffs a specific path -- it is not a repository-wide check. A PR that edits the source without committing the regenerated output in these paths will not merge:

CommandPath diffed
go mod tidygo.mod, go.sum
make update-crdsconfig/crd/bases
make update-codegenpkg/**
make telemetry-schemainternal/telemetry

Gaps to be aware of: make update-crds also rewrites deploy/crds*.yaml and docs/crd/, but neither path is diffed, so stale bundles merge silently. Snapshot golden files are not covered by verify-codegen either -- they fail in unit-tests instead.

Gotchas

  • Release images are never built in the public repo. release-prep*.yml is gated to nginx/kubernetes-ingress-internal; the public repo only copies manifests with skopeo. Never add a docker build step to a publish-stage workflow
  • Never add secrets as GitHub repository secrets -- use Azure Key Vault OIDC flow via get-from-vault action
  • Always pin GitHub Actions to immutable SHA hashes with version comments, not mutable tags
  • Matrix JSON files in .github/data/ must stay in sync with Makefile image targets
  • NAP variants are linux/amd64 only -- do not add arm64 to NAP matrices
  • Renovate manages tool versions via # renovate: comments -- do not update manually
  • image-promotion.yml runs on merge to main and release-*, not on PR -- don't expect images from PRs
  • Release-only workflows and .github/config/config-* files must be listed in .github/scripts/exclude_ci_files.txt, otherwise they feed get_actions_md5() and invalidate stable_tag, forcing a full image rebuild
  • .github/config/config-* files are shared between release-publish.yml, image-promotion.yml, regression.yml and update-docker-images.yml. Never add a SOURCE_*_IMAGE_PREFIX override to one -- the other callers read from the dev registry and would break. Override TARGET_* only
  • Every job in a non-mirror-* workflow must be gated as github.repository == 'nginx/kubernetes-ingress' (or nginx/kubernetes-ingress-internal for internal-only jobs like prep) optionally followed by && ( ... ) with all extra conditions inside one balanced group. && binds tighter than ||, so an ungrouped chain like gate && (a) || (b) parses as (gate && (a)) || (b) and would run on a fork. Enforced by .github/scripts/validate-workflow-gating.sh (pre-commit + lint-format.yml); run it locally after editing any job's if
  • Adding a job to a shared workflow means picking the right gate string. An internal-repo gate in release-publish.yml (or vice versa) silently skips the job forever -- there is no error, just a permanently grey box
  • The operator job skips silently when operator_version is empty. If a release ships without an operator PR, check that input before assuming the dispatch failed
  • A job whose if contains always(), !cancelled() or failure() runs even when a needs dependency failed. Such jobs must assert every dependency explicitly (needs.<job>.result == 'success'), which is why the release jobs list results one by one
  • Asserting a downstream job is not enough -- a dependency that failed leaves its dependants skipped, and result == 'skipped' is usually an accepted arm. Assert the job that actually does the work (e.g. tag asserts release-gate, release-assets asserts variables)
  • contains() is a substring match, not a token match. Never gate on a value that is a prefix of another job name: contains(skip_step, 'prep') also matches push-prep-images, and contains(skip_step, 'publish') also matches publish-helm-chart
  • release-prep.yml and release-publish.yml share the <branch>-release concurrency group so a publish dispatch cannot overtake a prep still writing to the staging registry (likewise for LTS release workflows sharing <branch>-release-lts)
  • copy-images.sh resolves SOURCE_REGISTRY/TARGET_REGISTRY after sourcing CONFIG_PATH, so an explicit positional argument beats the config file. Pass the source registry as $1; let the config own TARGET_REGISTRY
  • Jobs that publish externally visible artifacts must fail loudly when there is nothing to publish. github-release errors on a missing draft release before closing the milestone, so a green run guarantees a published release

© nginx, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .github/skills/nic-ci-pipelines of nginx/kubernetes-ingress.

Open the folder on GitHubat commit 29a1a36

Compare with similar skills

NGINX Ingress CI Pipelines next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

NGINX Ingress CI Pipelines compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
NGINX Ingress CI Pipelines this skillnginx/kubernetes-ingress5.1k—~5.1kAutomated safety check: PassApache-2.0
Senior DevOps Toolkitmaslennikov-ig/claude-code-orchestrator-kit2606 repos~1.1kAutomated safety check: NotesCustom licence
CI CDEliasOulkadi/shokunin114—~3.4kAutomated safety check: NotesMIT
Devops EngineerYikai-Liao/symusic1891 repos~1.5kAutomated safety check: PassMIT
CI/CD Pipeline Principlesirahardianto/awesome-agv156—~2.7kAutomated safety check: NotesMIT
Devops Excellencemajiayu000/spellbook287—~2.4kAutomated safety check: NotesMIT

Similar skills

  • Senior DevOps Toolkit

    maslennikov-ig/claude-code-orchestrator-kit

    Comprehensive DevOps skill for CI/CD, infrastructure automation, containerization, and cloud platforms (AWS, GCP, Azure). Includes pipeline setup…

    260 GitHub starsUsed in 6 repos~1.1k tokens
    DevOps & CloudAuto-check: notes

  • CI CD

    EliasOulkadi/shokunin

    Design CI/CD pipelines for GitHub Actions, GitLab CI, and CircleCI with matrix builds, test sharding, caching, Docker layer caching, OIDC auth, deployment strategies (rolling, blue-green, canary)…

    114 GitHub stars~3.4k tokensUpdated 6 days ago
    DevOps & CloudAuto-check: notes

  • Devops Engineer

    Yikai-Liao/symusic

    Creates Dockerfiles, configures CI/CD pipelines, writes Kubernetes manifests, and generates Terraform/Pulumi infrastructure templates.

    189 GitHub starsUsed in 1 repo~1.5k tokens
    DevOps & CloudAuto-check passed

  • CI/CD Pipeline Principles

    irahardianto/awesome-agv

    Rules for designing CI/CD pipelines in layers: universal lint, test and scan stages, container builds with SBOM attestation, and GitOps for orchestrated deployments.

    156 GitHub stars~2.7k tokensUpdated 6 days ago
    DevOps & CloudAuto-check: notes

  • Devops Excellence

    majiayu000/spellbook

    DevOps and CI/CD expert. An agent skill from majiayu000/spellbook.

    287 GitHub stars~2.4k tokensUpdated 2 days ago
    DevOps & CloudAuto-check: notes

  • Devops Deployment

    yonatangross/orchestkit

    A skill your agent uses when setting up CI/CD pipelines, containerizing applications, deploying to Kubernetes, or writing infrastructure as code.

    292 GitHub stars~2.7k tokensUpdated yesterday
    DevOps & CloudAuto-check passed

More from nginx/kubernetes-ingress

All 9 skills in this repo

  • NGINX Ingress Controller Feature Checklists

    nginx/kubernetes-ingress

    Gives step-by-step checklists for adding Ingress annotations, VirtualServer fields and Helm values to the NGINX Kubernetes Ingress Controller, with common gotchas.

    5.1k GitHub stars~1.4k tokensUpdated yesterday
    Auto-check passed

  • NGINX Ingress Policy CRD Guide

    nginx/kubernetes-ingress

    Step-by-step checklist for adding a new Policy CRD type to the NGINX Ingress Controller, from the Go types and validation to config generation and templates.

    5.1k GitHub stars~2k tokensUpdated yesterday
    Auto-check passed

  • NGINX Ingress Controller Image Builder

    nginx/kubernetes-ingress

    Explains the multi-stage Dockerfile, the 25 image variant combinations, and the Makefile targets for building NGINX Ingress Controller images.

    5.1k GitHub stars~2.9k tokensUpdated yesterday
    Auto-check passed

  • NGINX Ingress Controller Structure

    nginx/kubernetes-ingress

    Maps the NGINX Kubernetes Ingress Controller codebase: repository layout, architectural layers, layer-crossing rules and which files are generated.

    5.1k GitHub stars~3.8k tokensUpdated yesterday
    Auto-check passed

  • NIC Testing Patterns

    nginx/kubernetes-ingress

    Testing conventions for the NGINX Ingress Controller repo: Go table-driven tests, mandatory snapshot regeneration, Helm tests and Python pytest integration tests.

    5.1k GitHub stars~2.8k tokensUpdated yesterday
    Auto-check passed

  • NGINX Ingress Controller Debugging

    nginx/kubernetes-ingress

    Troubleshooting patterns for the NGINX Ingress Controller: reload failures, custom resources that have no effect, controller panics and snapshot test failures.

    5.1k GitHub stars~1.7k tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about NGINX Ingress CI Pipelines

What does NGINX Ingress CI Pipelines do?

Explains how the NGINX Ingress Controller's GitHub Actions workflows, reusable workflows, build matrices and release pipeline fit together across two repositories. The skill documents CI/CD for the NGINX Ingress Controller.repository`.

When should I use NGINX Ingress CI Pipelines?

NGINX Ingress CI Pipelines fits situations like: debugging a failing NIC GitHub Actions workflow; adding a step or changing a build matrix in the CI workflows; working out which repository builds and which publishes a release.

How do I install NGINX Ingress CI Pipelines in Claude Code?

Run `npx skills add nginx/kubernetes-ingress --skill nic-ci-pipelines -a claude-code`. Or copy the skill folder (.github/skills/nic-ci-pipelines in nginx/kubernetes-ingress) into .claude/skills/nic-ci-pipelines in your project. Claude Code loads it when a task matches its description.

How do I install NGINX Ingress CI Pipelines in Codex?

Run `npx skills add nginx/kubernetes-ingress --skill nic-ci-pipelines -a codex`. Or copy the skill folder (.github/skills/nic-ci-pipelines in nginx/kubernetes-ingress) into .agents/skills/nic-ci-pipelines in your project. Codex loads it when a task matches its description.

Can I use NGINX Ingress CI Pipelines in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add nginx/kubernetes-ingress --skill nic-ci-pipelines -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/nic-ci-pipelines, .gemini/skills/nic-ci-pipelines, .github/skills/nic-ci-pipelines and .opencode/skills/nic-ci-pipelines in your project.

What does NGINX Ingress CI Pipelines need to run?

Going by SKILL.md and its folder, NGINX Ingress CI Pipelines needs the command-line tools its instructions call (make, docker and go).

Does NGINX Ingress CI Pipelines access the network?

SKILL.md contains no URLs. Its commands use docker, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is NGINX Ingress CI Pipelines safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does NGINX Ingress CI Pipelines use?

NGINX Ingress CI Pipelines is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does NGINX Ingress CI Pipelines use?

About 5.1k tokens (SKILL.md is roughly 20k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to NGINX Ingress CI Pipelines?

Skills that share tags, products or a category with NGINX Ingress CI Pipelines: Senior DevOps Toolkit (maslennikov-ig/claude-code-orchestrator-kit, 260 stars), CI CD (EliasOulkadi/shokunin, 114 stars), Devops Engineer (Yikai-Liao/symusic, 189 stars) and CI/CD Pipeline Principles (irahardianto/awesome-agv, 156 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains NGINX Ingress CI Pipelines?

nginx (a GitHub organization) maintains it in nginx/kubernetes-ingress, which has 5,081 GitHub stars. The repository holds 9 skills in this directory. The repository was last updated on October 10, 2026.

Source: nginx/kubernetes-ingress on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.