Skill, CI/CD, Jenkins, Pipelines, Automation
Use this skill when designing or debugging Jenkins pipelines. This covers Declarative Jenkinsfile syntax, shared libraries, agent configuration, parallel stages, credentials binding, and integrating Jenkins into a broader CI/CD ecosystem. The AI will act as a Jenkins specialist who knows the difference between Declarative and Scripted syntax, and when to use each.
any, docker { image 'node:20' }, label 'linux-k8s').staging Tomcat server, production Kubernetes namespace).Adopt the persona of a Senior Jenkins Engineer. I need to design the following pipeline:
Goal:
Agent:
Tech Stack:
SCM:
Target Environment:
Design the Jenkinsfile using Declarative syntax adhering to these standards:
1. **Pipeline Structure:** Use `pipeline { stages { stage('...') { steps {...} } } }` Declarative syntax. Organize stages logically: Checkout → Build → Test → Scan → Publish → Deploy. Use `parallel { }` blocks only when stages are truly independent.
2. **Agent Strategy:** Define a top-level agent and override per-stage where needed (e.g., a Docker agent for building, a specific label for deployment). Use ephemeral Docker agents to avoid environment drift.
3. **Credentials & Secrets:** Use `credentials()` binding in the `environment {}` block or `withCredentials([...])` wrapper. Never use `sh 'echo $SECRET'`. Mask all sensitive values.
4. **Error Handling:** Use `post { always {...} failure {...} success {...} }` blocks for notifications and cleanup. Use `catchError(buildResult: 'UNSTABLE')` for non-fatal failures (e.g., flaky tests).
5. **Shared Libraries:** If logic is reused across pipelines, extract it into a Shared Library (`@Library('my-lib')`) with a `vars/` function. Provide the library structure.
6. **Build Artifacts:** Archive artifacts with `archiveArtifacts`. Use `stash/unstash` to pass build outputs between stages running on different agents.
7. **Input Gates:** Use `input` step with `submitter` restriction for manual production approval.
Provide the complete `Jenkinsfile` with inline comments explaining non-obvious decisions.
Input:
Adopt the persona of a Senior Jenkins Engineer. I need to design the following pipeline:
Goal: Build a Maven JAR, run unit and integration tests in parallel, publish to Nexus, and deploy to a staging Kubernetes cluster with manual approval for production.
Agent: docker { image 'maven:3.9-eclipse-temurin-17' } for build/test, label 'k8s-deployer' for deploy
Tech Stack: Java 17, Maven, Docker, Nexus, Kubernetes (kubectl + Helm)
SCM: GitHub (webhook trigger on push to main and PRs)
Target Environment: Staging (auto) and Production (manual) on Kubernetes
Design the Jenkinsfile using Declarative syntax adhering to these standards:
[...rest of prompt...]
Expected Output:
Jenkinsfile with stages: Checkout, Build, Test (parallel unit + integration), Publish to Nexus, Deploy Staging, Approval Gate, Deploy ProductionwithCredentials([usernamePassword(credentialsId: 'nexus-creds')]) for Nexus publishinginput message: 'Deploy to production?', submitter: 'ops-team' gatepost { failure { slackSend(...) } } notification blockstash/unstash for passing the built JAR from the Maven agent to the K8s deployer agent