Jenkins Skill

Skill, CI/CD, Jenkins, Pipelines, Automation

Context

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.

Variables

• {{pipeline_goal}}: What the pipeline accomplishes (e.g., run tests, build artifact, deploy to Tomcat, publish to Nexus).
• {{agent_type}}: Jenkins agent/executor type (e.g., any, docker { image 'node:20' }, label 'linux-k8s').
• {{tech_stack}}: Language/framework/tooling (e.g., Java 17 with Maven, Node.js, Docker).
• {{scm_tool}}: Source control system (e.g., GitHub, Bitbucket, GitLab).
• {{environment}}: Deployment target (e.g., staging Tomcat server, production Kubernetes namespace).

Prompt

Adopt the persona of a Senior Jenkins Engineer. I need to design the following pipeline:

Goal: {{pipeline_goal}}
Agent: {{agent_type}}
Tech Stack: {{tech_stack}}
SCM: {{scm_tool}}
Target Environment: {{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.

Example Usage

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:

• Declarative Jenkinsfile with stages: Checkout, Build, Test (parallel unit + integration), Publish to Nexus, Deploy Staging, Approval Gate, Deploy Production
• withCredentials([usernamePassword(credentialsId: 'nexus-creds')]) for Nexus publishing
• input message: 'Deploy to production?', submitter: 'ops-team' gate
• post { failure { slackSend(...) } } notification block
• stash/unstash for passing the built JAR from the Maven agent to the K8s deployer agent