In a Jenkins shared library repository, what do the vars/, src/ and resources/ directories each hold, and how does a Jenkinsfile reach each one?

## The layout is fixed A shared library repository has exactly three meaningful top-level directories, and Jenkins ignores anything else it finds: ``` (root) +- src/ # Groovy source tree, on the pipeline classpath | +- com/acme/Notifier.groovy +- vars/ | +- deployApp.groovy # becomes the step deployApp | +- deployApp.txt # documentation shown in the globals reference +- resources/ +- com/acme/settings.json # static files, read with libraryResource ``` ## vars: the DSL surface Each `.groovy` file in `vars/` defines a *global variable* whose name is the file name, so the file name must be a valid identifier and is conventionally camelCase. If the file defines a method named `call`, the variable is callable, and Groovy's syntax makes that look exactly like a built-in step: ```groovy // vars/deployApp.groovy def call(Map config = [:]) { sh "./deploy.sh ${config.app} ${config.env ?: 'staging'}" } ``` ```groovy deployApp app: 'billing', env: 'prod' ``` A vars file can define several methods, and the pipeline reaches them as `deployApp.validate(...)`. Crucially, code in `vars/` can call pipeline steps directly — `sh`, `echo`, `withCredentials` — because the file is executed with the pipeline script as its delegate. That is the single biggest practical difference from `src/`. A matching `.txt` file next to the `.groovy` file supplies documentation, rendered on the controller's global-variable reference page. On a library that forty repositories consume, that file is the difference between a library and a mystery. One caution: the global variable is instantiated once per build, so any field you set on it is shared by everything in that build. Treat vars as stateless entry points, not as places to stash state. ## src: real classes `src/` is an ordinary package tree added to the pipeline's classpath. Use it when the logic deserves types, constructors, and unit tests rather than a flat step. Two rules matter: **A src class cannot call steps by itself.** It has no delegate, so you inject the pipeline script: ```groovy package com.acme class Notifier implements Serializable { private final def script Notifier(script) { this.script = script } void info(String msg) { script.echo "[info] ${msg}" } } ``` Called from the Jenkinsfile as `new com.acme.Notifier(this).info('built')`, or more commonly wrapped by a thin vars step so callers never see the constructor. **Implement Serializable and mind CPS.** A Pipeline can pause and be resumed after a controller restart, so its state is serialised at every step boundary. Classes that live across step calls should implement `Serializable`, and methods holding non-serialisable objects or using constructs the CPS transformer handles badly are marked `@NonCPS` — with the restriction that a `@NonCPS` method must not call pipeline steps. ## resources: everything that is not Groovy `resources/` holds files you want to ship with the library — a JSON policy document, a Helm values template, a shell script — read at runtime: ```groovy def body = libraryResource 'com/acme/settings.json' writeFile file: 'settings.json', text: body ``` `libraryResource` returns the file content as a String; it does not place it in the workspace, so you write it out yourself. Resource loading is supported for libraries retrieved from an SCM, which is the normal case. ## How to divide code between them A useful discipline: `vars/` is the public API, `src/` is the implementation. Callers should see a handful of well-named steps with named parameters; changes to the internals then happen in `src/` without touching forty Jenkinsfiles. The opposite arrangement — hundreds of lines of business logic in one enormous vars file — is the pattern teams regret, because it is the hardest part of a library to unit-test and the easiest to break. ## What interviewers listen for Naming the three directories is table stakes. The distinguishing answers are: vars files can call steps and src classes cannot without an injected script object; the file name in vars *is* the step name; and library code participates in CPS serialisation like the rest of the pipeline.