jenkins-pipeline-jjb
Skill2 starsChanged 22 days agoMITView on GitHub
Write or review JJB YAML, Pipelines, plugin compatibility and the Jenkins job state loop, verifying rendering, CPS, queue, cancellation and callbacks layer by layer; run test jobs only in an approved isolated local environment and never auto-publish to or modify a real Jenkins. Deployment strategy and traffic switching belong to deployment-patterns, GitLab webhook receiving to gitlab-webhook-local-git, image build and push to container-image-management, local Compose environments to docker-local-environment.
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 33
Use the synthetic JJB example to show offline template expansion.
- Distinctive: line 35
Use the evidence template to deliver the source/plugin matrix, XML diff, actual tests and unverified items.
- Distinctive: line 42
If the real trigger source (e.g.
- Distinctive: line 48
Wrap-up cleanup: test jobs, build records, workspaces, agent containers and rendered output created in the isolated local environment are …
- Very specific: line 49
Follow the local resource cleanup rules of task-implementation: register identities on creation, clean up only objects registered this time …
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
JJB and Pipeline
Inputs:
- Approved scope.
- Actual versions of JJB, Jenkins, Java and plugins.
- Job type and parameter schema.
- Job templates, macros and source list.
- Output directory.
- Agent labels and isolation.
- Local endpoint admission.
- Callback, cancellation and artefact contracts.
Missing branches:
- A version missing -> review configuration sources first; do not claim runtime compatibility.
- Environment admission missing -> offline work only.
Expand by the layer where the failure sits
- Draw
YAML -> defaults/project/job template/macro -> job XML -> Pipeline script -> stage/external action -> callback. Annotate each edge with input, expansion time and artefact identity. - For YAML, parameter or XML differences read JJB rendering; render offline first, then compare semantics. Pushing configuration directly is not a syntax check.
- For Pipelines, steps and runtime read Plugins and execution; record evidence separately for linter, Groovy compilation, stub tests and real Jenkins.
- For multi-layer strings and parameter entry points read Quoting and secrets; template escaping is not safe input validation.
- For triggering, queue, cancellation and callbacks read Job lifecycle; keep an operation identity before initiating, and query before retrying when the result is unknown.
- Use the synthetic JJB example to show offline template expansion; it is disabled by default and accesses no network/repository. For execution, enable it only in an explicitly approved test copy. When the project uses SCM, keep using SCM; do not switch back to an inline script because of the example.
- Use the evidence template to deliver the source/plugin matrix, XML diff, actual tests and unverified items. When the current contract is already complete, fill gaps in it; do not create a parallel authoritative document.
Normal: a missing macro causes an offline failure; add the macro and parameters first, then verify the XML script, then verify on an authorised synthetic agent node. Counter-example: marking running as soon as the queue POST returns, or archiving because a post callback said success; instead obtain the build identity and verify the final building/result.
On failure keep the source, XML, parameter snapshot and operation/queue/build identity. An unknown initiation result must not be blindly re-sent; persist cancel intent first; late callbacks must not revive the task. If the real trigger source (e.g. GitLab) and real traffic switching are covered by the consuming project's manual go-live verification, local rehearsal does not sign off for them.
Resource suggestion: low/low for mechanical rendering/diff checks; normal/medium for Pipeline design; normal/high for CPS, cancellation races, credential egress and plugin conflicts.
Grade words map to actual execution configuration through the project resource mapping.
Parallelism is set by node/workspace/external resource isolation; do not assume each stage gets its own executor.
Wrap-up cleanup: test jobs, build records, workspaces, agent containers and rendered output created in the isolated local environment are cleaned up after verification.
Follow the local resource cleanup rules of task-implementation: register identities on creation, clean up only objects registered this time at wrap-up, record evidence to keep and failed cleanups in the receipt, and use no global cleanup commands.
Sources
- Pinned sources: WS02 deployment-pipeline-design, EC10 deployment-patterns.
- Adopted inputs/outputs, stage dependencies and the health/failure framework; the JJB/CPS/state-machine specifics are own-authored for this package and checked against the linked official material; the upstream is not claimed to provide a complete JJB package. Dropped fixed gates, deployment commands, credentials, default platforms and timeouts. Re-verify against actual versions when updating.
- License: shipped with the package as LICENSE-WS.txt (WS, MIT), LICENSE-EC.txt (EC, MIT); library-wide third-party summary in the root THIRD_PARTY_NOTICES.md. Copy the license files along when copying this package alone.
In this repository39 other files it gives its agents.
- ai-trace-auditSkill
- ai-workspace-governanceSkill
- archive-maintenanceSkill
- change-reviewSkill
- cloud-api-integrationSkill
- coding-conventionsSkill
- container-image-managementSkill
- context-handoffSkill
- deployment-patternsSkill
- docker-local-environmentSkill
- documentation-authoringSkill
- estimationSkill
- external-dependency-simulationSkill
- gitlab-webhook-local-gitSkill
- go-patternsSkill
- go-testingSkill
- grpc-proto-contractSkill
- guided-evidence-collectionSkill
- http-api-designSkill
- ldap-rbacSkill
- mysql-migration-safetySkill
- plan-designSkill
- plan-reviewSkill
- playwright-e2eSkill
- project-contextSkill
- pytest-patternsSkill
- readonly-ops-diagnosticsSkill
- redis-patternsSkill
- release-readinessSkill
- role-bootstrapSkill
- security-reviewSkill
- skill-maintenanceSkill
- subtask-dispatchSkill
- systematic-diagnosisSkill
- task-implementationSkill
- test-strategySkill
- verification-gateSkill
- vue3-developmentSkill
- vue-testingSkill
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.

