SAP jenkins-library: the Project Piper steps for Jenkins pipelines

What Project Piper and the shared library are

The repository holds the shared library of Project Piper. The README separates the two ideas: Piper offers default pipelines to easily implement CI/CD processes integrating SAP systems, and the shared library provides a set of steps to build your own scenarios beyond the defaults.

That split is the design. The defaults are the opinionated part, a ready-made pipeline for the common SAP deployment shapes, and the shared library is the reusable vocabulary underneath, so a team that needs something the defaults do not cover can compose the existing steps rather than starting from nothing.

The project is written in Go, and the primary language field in the repository metadata says so, but the artefact Jenkins consumes is a shared library rather than a binary. The Go code is the CLI and the implementation behind the steps, which is a common shape for Jenkins tooling where a single binary handles the cloud and platform calls that a shell step would handle badly.

The homepage is project-piper.io, and the user documentation is published separately at sap.github.io/jenkins-library. The repository topics are ci-cd, cli, golang, jenkins and open-source, which is a fair summary of what it is.

The archive notice and what it means in practice

The first thing in the README is an archive notice, and it is the most consequential fact about the project.

The repository will be archived on December 31, 2026. It will remain available in read-only mode for reference. No further updates, bug fixes or pull requests will be accepted after that date.

The timeline is spelled out in two phases. From now until December 31, 2026 the project is in limited maintenance, with critical issues only. On January 1, 2027 the repository becomes read-only and archived.

The last push was on 2026-10-19, and the release history is fast, with v1.534.0 from 2026-10-19, v1.533.0 from 2026-10-13 and v1.532.0 from 2026-10-12. So the code is still moving, but the destination is fixed.

For SAP internal development teams using Piper through internal platforms, the README says they are not affected by the change, that access and support continue uninterrupted, and that questions should go through internal support channels. For external users, the README says to contact an SAP representative for information about alternatives or migration paths.

That is a deliberately narrow public offer. There is no fork named, no successor project pointed at, and no migration guide in the repository. The guidance is to talk to SAP.

The steps, the CLI and the repository layout

The repository root shows a project with several distinct concerns rather than a single library file.

There is a pkg/ directory for the Go packages, a cmd/ directory for the CLI entry points, a src/ directory, a main.go at the root, and a go.mod. There is a vars/ directory, which in a Jenkins shared library is where the global variables and pipeline steps are declared, and a cfg/ directory, a template/ directory and resources/ for configuration and templating.

The test/ and unit-report.out and cover.out files show that the Go code is unit tested and that coverage is tracked, and the integration/ directory suggests a separate tier of tests. The pom.xml at the root is a Maven descriptor, which is there because the project produces artefacts consumed by a Java and Jenkins ecosystem rather than only by Go.

The documentation/ directory holds the user documentation that is published to the pages site, and the .pipeline/ directory holds pipeline definitions. A Dockerfile at the root is worth a closer look, because it is unusual for this kind of project.

The image runs the tests during the build.

FROM golang:1.24.0 AS build-env
COPY . /build
WORKDIR /build

# execute tests
RUN go test ./... -tags=unit -cover

The build stage is a golang 1.24.0 image, and the unit tests run with the unit tag and coverage enabled, before anything is compiled. The comments that follow note that the build step is to be added later, and the runtime stage that would copy the binary into a distroless base is present but commented out. So the Dockerfile currently produces a test image rather than a deployment image, which is an honest reflection of where the packaging work stands.

The dependency list tells you what the steps actually reach for

The go.mod is more informative about the scope of the library than any prose would be, and it is a long list.

The cloud storage and messaging clients come first: the Google Cloud pubsub and storage modules, the Azure blob storage SDK, the AWS SDK v2 with its config and S3 service, and the InfluxDB client. So the steps can talk to object storage and eventing across three clouds plus a time series database.

The source control and delivery clients are next: go-git, the Docker CLI, buildpacks lifecycle, the Go container registry client, the Moby API and buildkit, and the Google Cloud buildpacks pieces. The library can build and push container images, and it can run the buildpacks lifecycle.

Then the platform and artefact surfaces: the Azure DevOps Go API, the CDEvents SDK and the CloudEvents SDK, CycloneDX for software bill of materials, Jenkins' own gojenkins client, the Vault API with AppRole auth, Sentry for error reporting, and the Go GitHub client. The CycloneDX dependency is the one worth singling out, because it means the library can produce SBOMs as part of a pipeline, which is a compliance requirement many teams have to satisfy and a fiddly thing to implement themselves.

The go directive is go 1.27, so the toolchain floor is recent, while the Dockerfile builds on golang 1.24.0. That mismatch is the kind of thing that bites when a build image and the module declaration drift apart.

Where this library is the wrong choice

The first limitation is the archive date, and it is not a soft one. A team starting a project today that plans to run for two years is choosing a dependency whose upstream stops accepting fixes at the end of this year. Nothing breaks on January 1, 2027, the code keeps working, but every dependency bump, every Jenkins update and every security fix in the transitive closure becomes your problem rather than the project's.

The second is that the library is tied to a vendor's product line. The steps integrate SAP systems, and their behaviour is shaped by what SAP systems expect. A pipeline for a non-SAP stack gets very little from the step set, and a team that has one SAP system in a larger estate may find the shared library's abstractions forcing their whole pipeline into SAP's shape.

The third is the dependency surface. Cloud SDKs for three providers, two container toolchains, two event formats, a CI API, a secret manager, an error tracker and a GitHub client, all in one module, means the transitive dependency tree of anything that loads this library is large. A Jenkins controller loading Piper pulls in a lot of code, and every one of those modules has its own release cadence.

The fourth is that the archive notice offers no public migration path. There is no successor project, no documented replacement and no compatibility shim, only a note to contact an SAP representative. An external team that decides to leave has to do the porting work with whatever help it can get.

The fifth is the scope of the defaults versus the steps. Piper's default pipelines are opinionated and opinionated defaults age badly, because they encode assumptions about the SAP release and the deployment tooling of the moment. The shared library is the part that stays useful, and a team that only wants the steps can ignore the defaults, but the defaults are what most people arrive for.

How this compares with a plain Jenkins shared library and with the official SAP tooling

The comparison with a plain shared library is the one most teams will recognise. A Jenkins shared library without Piper is a folder of Groovy steps that a team writes and shares, and it does the same job of centralising pipeline logic. The difference in approach is that Piper's steps are pre-built for a specific domain, with SAP system knowledge already inside, so a team does not write the integration to an SAP deployment API or a transport system from scratch. The cost is that the domain knowledge is now coupled to a library that is about to stop changing.

The comparison with the official SAP tooling is the honest one. SAP also ships its own deployment and change management tooling, and Piper sits in the CI/CD layer around SAP systems rather than replacing the change management layer. For a team that already uses the official tooling, Piper's value is that it wraps it in a pipeline and adds the non-SAP steps around it, such as container builds, source control and artefact handling. For a team that does not, Piper is one of the routes to getting an SAP change into a pipeline.

A third comparison is with the many small Jenkins step collections in the ecosystem, which are usually community maintained and usually narrow. Piper is the opposite shape, wide and vendor-maintained, and its breadth is exactly what the archive makes costly: there is a lot of it to own if the maintenance stops.

There is also a Go CLI angle, since the project describes itself as a Jenkins shared library and also as a CLI. Running the CLI outside Jenkins is what makes the steps testable and scriptable, and it is how a team can use the same integration from a GitHub Actions job or a local script without reimplementing it.

Licence, quality signals and what to do before December

The licence field on the repository records Apache-2.0, with a LICENSE file at the root and a LICENSES/ directory, which is the REUSE style layout, and the README carries a REUSE status badge from the REUSE software project. REUSE compliance is a good sign for a large multi-licence-adjacent repository, because it means every file has a clear licence and copyright statement rather than relying on a root file that may not cover everything.

The quality signals in the README are the usual set for a project of this size: a CodeClimate maintainability badge and a test coverage badge, a Go Report Card badge, and the REUSE status badge. The repository also carries a sonar-project.properties file, a staticcheck.conf, a .mockery.yml for mock generation, a .yamllint.yml, a .markdownlint.yml, a .log4brains.yml for architectural decision records, a .reuse/ directory, an AGENTS.md and a CONTRIBUTING.md. The presence of the coverage and report card badges next to the archive notice is a bit of a contrast, and the interesting question for a user is whether the maintainability trend was still good when work stopped.

Three things are worth doing before the end of the year if you use this library. Read the known issues list on the issues page, since that is where the remaining sharp edges are recorded. Note the version you are on, since after the archive there is no upgrade path and pinning is what makes a future port predictable. And if you are external, contact an SAP representative about migration paths while that conversation is still possible, because after January 1, 2027 the same request will have a different answer.

Editorial conclusion

SAP jenkins-library suits a team building Jenkins pipelines for SAP systems today who wants the standard Piper steps rather than writing the integration themselves, and who can plan their own timeline around the archive date. It is the wrong choice for a new long-lived project, because the repository goes read-only on January 1, 2027 and no further fixes are accepted after December 31, 2026, so any dependency on it becomes a maintenance liability you will own. Before starting work on it, read the archive notice and the known issues list, and if you are an SAP internal team on internal platforms the README says your access and support continue uninterrupted, so use the internal channels rather than migrating.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. SAP/jenkins-library on GitHub