DOCSEARCHbyAlgolia
Submit Docs

Project Piper Jenkins Shared Library

repository·master·Indexed 21 days ago

https://github.com/sap/jenkins-library

A Jenkins Shared Library providing default CI/CD pipelines and reusable steps for integration with SAP systems. It includes scenarios for building and deploying SAPUI5/SAP Fiori applications to SAP BTP (Cloud Foundry and Neo), SAP HANA XSA, and attaching binaries to SAP ABAP transport requests via OData (CTS) or RFC.

Tokens
123.3K
Snippets
377
Records
533
Agent score
74%

What's inside sap-jenkins-library

  2. Repository Archive Notice and Timeline

    master

    This repository is scheduled for archiving on December 31, 2026.

    Timeline:

    • Until December 31, 2026: The project is under limited maintenance (critical issues only).
    • From January 1, 2027: The repository will become read-only. No further updates, bug fixes, or pull requests will be accepted.

    Impact:

    • SAP Internal Teams: If using Piper through internal platforms, you are not affected. Support continues through internal channels.
    • External Users: Please contact your SAP representative for information regarding migration paths or alternatives.

  3. Choose an implementation approach for Project Piper

    master

    Project Piper provides multiple ways to implement continuous delivery for SAP technologies, depending on your infrastructure and customization needs:

    1. Ready-Made Pipelines (Best-Practice Way): Use predefined pipelines for common use cases. This is recommended for most users to minimize effort while following best practices.

      • General Purpose Pipeline: For standalone SAP BTP applications or SAP Cloud Application Programming Model (CAP) projects. Supports various technologies and languages.
      • ABAP Environment Pipeline: Specifically for ABAP environments.

    2. Customized Pipelines (Do-It-Yourself Way): Use the provided shared library as building blocks to create your own Jenkins pipelines. This is suitable when you need high flexibility beyond standard pipeline features.

    3. Standalone Tools: Use the command line utility (Linux) or the GitHub Action for environments outside of Jenkins.

    4. Docker Images: Use a set of specialized Docker images to set up a CI/CD environment with managed lifecycles.

  4. Understand the Project Piper Repository

    master

    Project Piper provides default CI/CD pipelines designed to integrate with SAP systems. It consists of two main components:

    1. Default Pipelines: Pre-configured pipelines for common CI/CD processes.
    2. Shared Library: A set of reusable "steps" that allow developers to build custom pipeline scenarios beyond the provided defaults.

  6. What is a Target Vector and how is it used?

    master

    A Target Vector defines the content of an add-on product version and is used by deployment tools. It is derived from the addon.yml file and contains:

    • Product name
    • Product release
    • Product Support Package stack and Patch level
    • A list of contained software component versions (including name, release, and the Delivery Package used).

    Lifecycle in the ABAP Environment Pipeline

    1. Build Stage: The target vector for the specific add-on product version is published in test scope. This allows for add-on test installations during the Integration Tests stage (but only during system provisioning).
    2. Publish Stage: The target vector is published in production scope, making the version available for add-on updates and installation during system provisioning.

  7. Coding pattern for pipeline steps

    master

    When writing new pipeline steps, they should be written in Go. For Groovy-based steps, follow these constraints:

    • No return values: Pipeline steps must not return values (they are effectively void).
    • Parameter sharing: To share parameters between pipeline steps or between a step and a pipeline script, use the commonPipelineEnvironment object.

    New steps should be implemented in Go rather than Groovy whenever possible.

  8. Understand Software Component Versions

    master

    A Software Component is a self-contained unit of development (repository) within the SAP BTP, ABAP environment. A Software Component Version is a technically distinguishable unit of software consisting of ABAP development packages and objects, delivered via delivery packages.

    Software Component Naming

    • Format: /NAMESPC/COMPONENTA (must include a namespace).
    • Constraints: Maximum 30 characters.

    Software Component Versioning

    Versions follow a three-number dot-separated format (1.2.0):

    1. Release (e.g., 1.x.x): Used for new functionalities or feature enhancements. Delivered via Add-on Installation (AOI) delivery packages. Usually created quarterly.
    2. Support Package Level (e.g., x.2.x): Contains objects changed since the last release or support package. Used for smaller functional enhancements or collections of patches. Delivered via Component Support Package (CSP) delivery packages. Usually created bi-weekly.
    3. Patch Level (e.g., x.x.0): Contains only objects changed since the previous patch. Used for bugfixes (e.g., emergency patches).

    Note: Software Component Versions are independent of Add-on Product versions. Once built, a version is reused in subsequent add-on product versions.

  9. How the initialChecks stage works

    master

    The initialChecks stage performs preliminary validation tasks required before the Build stage can execute. It ensures that the environment and dependencies are correctly prepared for the ABAP build process.

    Execution Steps

    The stage executes the following specific steps:

    • abapAddonAssemblyKitCheckPV
    • abapAddonAssemblyKitCheckCVs
    • abapAddonAssemblyKitReserveNextPackages

    Activation Logic

    The initialChecks stage is automatically activated if the Build stage is configured in your config.yml file. If you have entries for Build, this stage will run as a prerequisite.

  10. Obtain Change Document and Transport Request IDs from Git

    master

    In OS Piper pipelines, you can automate the retrieval of IDs from Git commit messages. By using the following steps, the IDs are injected into the commonPipelineEnvironment, allowing transportRequestUploadSOLMAN to use them without explicit parameter passing.

    transportRequestDocIDFromGit( script: this )
transportRequestReqIDFromGit( script: this )
transportRequestUploadSOLMAN( script: this, ... )

  11. How Groovy and Go steps resolve configuration

    master

    Configuration resolution involves a coordination between the Groovy layer (Jenkins) and the Go layer (the executable).

    • setupCommonPipelineEnvironment (Groovy): This step initializes the commonPipelineEnvironment and the DefaultValueCache. It handles custom defaults provided via parameters or the .pipeline/config.yml file.
    • DefaultValueCache (Groovy): This component caches the merged configuration (Custom Defaults + Piper Defaults). It also maintains a list of configuration paths used to inform Go steps where to find their specific configurations.

    Key distinction: The Go layer resolves configurations provided via the customDefaults parameter independently, so the DefaultValueCache only tracks paths for configurations not provided via customDefaults.

  12. How pattern matching works for errors

    master

    The system uses a two-tier approach to match patterns against step logs:

    1. Regular Expression Matching: The system first attempts to compile and match the pattern as a regular expression. This is the preferred method and supports wildcards (.*) and anchoring (^).
    2. Substring Matching: If the pattern is not a valid regular expression (i.e., regex compilation fails), the system falls back to treating the pattern as a literal substring match.

    Matching Examples:

    • Regex with wildcard: npm error 404.*Not Found
    • Exact substring: npm error code E401
    • Anchored regex: ^ERROR: