### Basic Jenkins Pipeline Setup with Piper Library (Groovy)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/stages/examples.md

This snippet demonstrates the minimal `Jenkinsfile` configuration required to set up a Jenkins pipeline using the 'piper-lib' shared library. It initializes the library and then invokes the `piperPipeline` function, passing the current script context.

```Groovy
@Library('piper-lib') _

piperPipeline script: this
```

--------------------------------

### Basic Logging in Go Steps (Go)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

This Go snippet demonstrates how to perform basic logging within a Jenkins Library step using the `sirupsen/logrus` framework, accessed via the `github.com/SAP/jenkins-library/pkg/log` package. It shows an example of an informational log entry.

```golang
import (
    "github.com/SAP/jenkins-library/pkg/log"
)

func myStep ...
    ...
    log.Entry().Info("This is my info.")
    ...
}
```

--------------------------------

### Basic Jenkinsfile Example for apiProxyUpload

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/apiProxyUpload.md

A minimal example demonstrating how to integrate the `apiProxyUpload` step directly into a Jenkinsfile, passing the current script context.

```groovy
apiProxyUpload script: this
```

--------------------------------

### Executing Maven Goals with `mavenExecute` (Basic)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/mavenExecute.md

This example demonstrates a basic invocation of the `mavenExecute` step, running the 'clean' and 'install' goals. It shows how to pass the Jenkins script environment using `script: this` to allow the function to access the common pipeline environment.

```groovy
mavenExecute script: this, goals: ['clean', 'install']
```

--------------------------------

### Using Custom Defaults in Jenkins Pipeline (Groovy)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/stages/examples.md

This `Jenkinsfile` snippet extends the basic pipeline setup to incorporate custom default configurations. It loads multiple shared libraries, including 'piper-lib-os' and 'myCustomLibrary', and then calls `piperPipeline` while specifying a custom defaults file, 'myCustomDefaults.yml', to override or extend standard settings.

```Groovy
@Library(['piper-lib-os', 'myCustomLibrary']) _

piperPipeline script: this, customDefaults: ['myCustomDefaults.yml']
```

--------------------------------

### Complete ABAP Environment Build Configuration Example in config.yml (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapEnvironmentBuild.md

This comprehensive YAML example showcases a full `abapEnvironmentBuild` configuration in `config.yml`. It includes direct host/credential settings, certificate names, phase definition, dynamic value injection (as a JSON string), result file handling, download directory, error treatment, and runtime/polling parameters.

```yaml
stages:
  MyPhase:
    abapCredentialsId: 'abapCredentialsId'
    host: 'https://myABAPendpoint.com'
    certificateNames: ['myCert.cer']
    phase: 'MyPhase'
    values: '[{"value_id":"ID1","value":"Value1"},{"value_id":"ID2","value":"Value2"}]'
    downloadResultFilenames: ['File1','File2']
    publishResultFilenames: ['File2']
    subDirectoryForDownload: 'MyDir'
    filenamePrefixForDownload: 'MyPrefix'
    treatWarningsAsError: true
    maxRuntimeInMinutes: 360
    pollingIntervallInSeconds: 15
```

--------------------------------

### Example Docker Config.json for Registry Authentication

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/cnbBuild.md

This example demonstrates a `config.json` structure for authenticating with a Docker registry, `example.com`. The `auth` field contains a Base64 encoded username and password, `dXNlcm5hbWU6cGFzc3dvcmQ=`, for secure credential storage.

```json
{
  "auths": {
    "example.com": {
      "auth": "dXNlcm5hbWU6cGFzc3dvcmQ="
    }
  }
}
```

--------------------------------

### Default Gauge Installation via curl

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/gaugeExecuteTests.md

This is the default command used to install Gauge, leveraging curl to download and execute the official installation script. It places the Gauge executable in the user's home bin directory, providing a quick setup.

```Shell
curl -SsL https://downloads.gauge.org/stable | sh -s -- --location=$HOME/bin/gauge
```

--------------------------------

### Example CommonPipelineEnvironment Input (JSON)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapEnvironmentAssemblePackages.md

This JSON snippet provides an example structure for input data expected via the `CommonPipelineEnvironment`. It details various fields related to addon products and repositories, including names, versions, package details, and commit IDs.

```json
{"addonProduct":"","addonVersion":"","addonVersionAAK":"","addonUniqueID":"","customerID":"","AddonSpsLevel":"","AddonPatchLevel":"","TargetVectorID":"","repositories":[{"name":"/DMO/REPO_A","tag":"","branch":"","version":"","versionAAK":"0001","PackageName":"SAPK001001REPOA","PackageType":"CPK","SpLevel":"0000","PatchLevel":"0001","PredecessorCommitID":"cbb834e9e03cde177d2f109a6676901972983fbc","Status":"P","Namespace":"/DMO/","SarXMLFilePath":""},{"name":"/DMO/REPO_B","tag":"","branch":"","version":"","versionAAK":"0002","PackageName":"SAPK002001REPOB","PackageType":"CPK","SpLevel":"0001","PatchLevel":"0001","PredecessorCommitID":"2f7d43923c041a07a76c8adc859c737ad772ef26","Status":"P","Namespace":"/DMO/","SarXMLFilePath":""}]}
```

--------------------------------

### Example JSON Configuration File for Cloud Foundry Service (JSON)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/cloudFoundryCreateService.md

This JSON snippet represents a configuration file (e.g., `createServiceConfig.json`) that can be referenced by the `cfCreateServiceConfig` parameter in the `cloudFoundryCreateService` step. It provides key-value pairs for service-specific settings.

```json
{
  "example":"value",
  "example":"value"
}
```

--------------------------------

### Generating Jenkins Library Steps (Bash)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

This Bash command initiates the generation of the Jenkins Library step framework. It processes YAML metadata files located in `resources/metadata/` to create boilerplate Go code for new steps, automating much of the initial setup.

```bash
go generate
```

--------------------------------

### Executing Maven Goals with `mavenExecute` (Advanced)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/mavenExecute.md

This example showcases the correct usage of the `goals`, `defines`, and `returnStdout` parameters in `mavenExecute` for versions `v1.24.0` and newer. It demonstrates passing multiple define arguments as separate list elements and capturing the command output for further processing.

```groovy
mavenExecute(
    script: script,
    goals: ['org.apache.maven.plugins:maven-help-plugin:3.1.0:evaluate'],
    defines: ["-Dexpression=$pomPathExpression", "-DforceStdout", "-q"],
    returnStdout: true
)
```

--------------------------------

### Example YAML File for Cloud Foundry Manifest Variable Values (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/cloudFoundryCreateService.md

This YAML snippet provides an example of a `vars.yml` file, which contains the actual values for variable substitution defined in a `manifest.yml`. This file is referenced by the `manifestVariablesFiles` parameter to dynamically populate service names or other manifest properties.

```yaml
name1: test1
name2: test2
name3: test3
```

--------------------------------

### Initializing Groovy Beans with Java Syntax (Correct)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

Shows the correct method for initializing Groovy beans using standard Java constructor syntax, which is fully supported and recommended for compatibility within Jenkins. This approach ensures proper object instantiation.

```Groovy
Version javaVersion = new Version(1, 8)
```

--------------------------------

### Initial Go Step Function Structure (Go)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

This Go code illustrates the standard initial structure for a Jenkins Library step, featuring `step` and `runStep` functions. This separation is crucial for facilitating unit tests and mocking, allowing `runStep` to be tested in isolation with mock dependencies.

```golang
func step(options stepOptions, telemetryData *telemetry.CustomData) {
    err := runStep(&options, telemetryData)
    if err != nil {
        log.Entry().WithError(err).Fatal("step execution failed")
    }
}

func runStep(options *stepOptions, telemetryData *telemetry.CustomData) error {
}
```

--------------------------------

### Configuring Basic NeoDeploy in YAML

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/neoDeploy.md

This YAML configuration example shows how to set up the `neoDeploy` step with `mta` deployment mode. It defines the target SAP BTP Neo `account` and `host` for the deployment, typically used within a Jenkinsfile's `steps` section for declarative pipelines.

```yaml
steps:
  <...>
  neoDeploy:
    deployMode: mta
    neo:
      account: <myDeployAccount>
      host: hana.example.org
```

--------------------------------

### Example Usage of GitHub Publish Release Step with Parameters (Jenkins)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/githubPublishRelease.md

This example illustrates how to invoke the 'githubPublishRelease' step in a Jenkins pipeline, passing a specific parameter 'releaseBodyHeader' to customize the release body. This demonstrates direct parameter passing.

```groovy
githubPublishRelease script: this, releaseBodyHeader: "**This is the latest success!**<br />"
```

--------------------------------

### Cloning ABAP Repository via YAML Configuration

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/gctsCloneRepository.md

This YAML example shows how to configure the `gctsCloneRepository` step within a `.pipeline/config.yaml` file. It specifies the ABAP host, client, credentials, and the repository, suitable for declarative pipeline configurations.

```YAML
steps:
  <...>
  gctsCloneRepository:
    host: 'https://abap.server.com:port'
    client: '000'
    abapCredentialsId: 'ABAPUserPasswordCredentialsId'
    repository: 'myrepo'
```

--------------------------------

### Example repositories.yml/addon.yml Configuration for ABAP Environment Tags (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapEnvironmentCreateTag.md

This snippet shows the structure of a `repositories.yml` or `addon.yml` file, which is used to define multiple repositories, their branches, commit IDs, and versions. It also includes `addonVersion` and `addonProduct` for add-on specific tagging, and is the recommended approach for complex configurations.

```yaml
addonVersion: "1.2.3"
addonProduct: "/DMO/PRODUCT"
repositories:
  - name: '/DMO/REPO'
    branch: 'feature'
    commitID: 'cd87a3cac2bc946b7629580e58598c3db56a26f8'
    version: '1.0.0'
```

--------------------------------

### Installing Gauge CLI via npm

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/gaugeExecuteTests.md

This command demonstrates how to install the Gauge command-line interface globally using npm, specifying a particular version. It's a common way to manage Node.js-based tools and ensures a consistent Gauge environment.

```JavaScript
npm install -g @getgauge/cli@1.2.1
```

--------------------------------

### Running uiVeri5 Tests with Custom Env and PATH (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/npmExecuteTests.md

This advanced `npmExecuteTests` configuration is tailored for uiVeri5 tests, demonstrating how to specify a global install command, a custom run command, Selenium hub options, and environment variables for `NPM_CONFIG_PREFIX` and `PATH` adjustments.

```yaml
stages:
  - name: Test
    steps:
      - name: npmExecuteTests
        type: npmExecuteTests
        params:
          runCommand: "/home/node/.npm-global/bin/uiveri5"
          installCommand: "npm install @ui5/uiveri5 --global --quiet"
          runOptions: ["--seleniumAddress=http://localhost:4444/wd/hub"]
          usernameEnvVar: "PIPER_SELENIUM_HUB_USER"
          passwordEnvVar: "PIPER_SELENIUM_HUB_PASSWORD"
          envs:
            - "NPM_CONFIG_PREFIX=~/.npm-global"
          paths:
            - "~/.npm-global/bin"
```

--------------------------------

### Building with User-Provided Buildpacks in Groovy

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/cnbBuild.md

This example illustrates using the `cnbBuild` function to build a container image with specific buildpacks. It sets Docker credentials, image details, registry URL, and explicitly lists the `nodejs` and `build-plan` buildpacks to be used during the build process.

```Groovy
cnbBuild(
    script: this,
    dockerConfigJsonCredentialsId: 'DOCKER_REGISTRY_CREDS',
    containerImageName: 'images/example',
    containerImageTag: 'v0.0.1',
    containerRegistryUrl: 'gcr.io',
    buildpacks: ['docker.io/paketobuildpacks/nodejs', 'paketo-community/build-plan']
)
```

--------------------------------

### Executing Closure with Sidecar Container (Groovy)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/dockerExecute.md

This advanced example illustrates using `dockerExecute` with a sidecar container, common for scenarios like Selenium testing. It configures port mappings, specifies the main and sidecar images, and defines a custom workspace, allowing complex multi-container setups within a single step.

```Groovy
dockerExecute(
        script: script,
        containerPortMappings: [containerPortMappings:'selenium/standalone-chrome':[containerPort: 4444, hostPort: 4444]],
        dockerImage: 'node:8-stretch',
        dockerName: 'node',
        dockerWorkspace: '/home/node',
        sidecarImage: 'selenium/standalone-chrome',
        sidecarName: 'selenium',
) {
    git url: 'https://github.com/XXXXX/WebDriverIOTest.git'
    sh '''npm install\n          node index.js\n    '''
}
```

--------------------------------

### Example YAML Manifest for Multiple Cloud Foundry Services (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/cloudFoundryCreateService.md

This YAML snippet illustrates the structure of a `manifest.yml` file used for creating multiple Cloud Foundry services. It defines an array of services, each with a `name`, `broker`, and `plan`, enabling the creation of several services in a single operation.

```yaml

---
create-services:
- name:   "testDatabase1"
  broker: "mongodb"
  plan:   "v4.0-dev"

- name:   "testDatabase2"
  broker: "mongodb"
  plan:   "v4.0-dev"

- name:   "testDatabase3"
  broker: "mongodb"
  plan:   "v4.0-dev"
```

--------------------------------

### Defining Add-on Product and Repositories (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/pipelines/abapEnvironment/stages/integrationTest.md

This YAML file specifies the add-on product details and its associated component repositories. It includes the product name, version, and details for each repository such as name, branch, version, and commit ID, essential for add-on installation.

```yaml
---
addonProduct: /NAMESPC/PRODUCTX
addonVersion: 1.2.0
repositories:
  - name: /NAMESPC/COMPONENTA
    branch: v1.2.0
    version: 1.2.0
    commitID: 7d4516e9
  - name: /NAMESPC/COMPONENTB
    branch: v2.0.0
    version: 2.0.0
    commitID: 9f102ffb
```

--------------------------------

### Example repositories.yml File Content (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapEnvironmentCheckoutBranch.md

This YAML snippet illustrates the structure of a `repositories.yml` file, which can be used by the `abapEnvironmentCheckoutBranch` step to define multiple ABAP repositories and their target branches. Each entry requires a `name` and a `branch`, and all branch values must be filled.

```yaml
repositories:
- name: '/DMO/GIT_REPOSITORY'
  branch: 'master'
- name: '/DMO/GIT_REPO'
  branch: 'master'
```

--------------------------------

### Executing Malware Scan in Groovy

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/malwareExecuteScan.md

This Groovy snippet demonstrates a basic invocation of the `malwareExecuteScan` step within a Jenkins pipeline. It passes the current script context, initiating the malware scanning process.

```groovy
malwareExecuteScan script: this
```

--------------------------------

### Example `repositories.yml` for `abapEnvironmentPullGitRepo` (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapEnvironmentPullGitRepo.md

This YAML snippet illustrates the structure of a `repositories.yml` file, which defines multiple Git repositories to be pulled. Each entry can specify `name`, `branch`, `commitID`, or `tag`, allowing for precise control over the version of the repository content.

```yaml
repositories:
- name: '/DMO/GIT_REPOSITORY'
  branch: 'main'
- name: '/DMO/GIT_REPO_COMMIT'
  branch: 'feature'
  commitID: 'cd87a3cac2bc946b7629580e58598c3db56a26f8'
- name: '/DMO/GIT_REPO_TAG'
  branch: 'realease'
  tag: 'myTag'
```

--------------------------------

### Helm 3 Chart Deployment with Kubernetes (Groovy)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/kubernetesDeploy.md

This example shows how to deploy a Helm 3 chart named 'myChart' as 'myRelease' using the `kubernetesDeploy` step. It specifies an Nginx image and a Docker container registry URL, demonstrating a more comprehensive Helm-based deployment.

```Groovy
// Deploy a helm chart called "myChart" using Helm 3
kubernetesDeploy script: this, deployTool: 'helm3', chartPath: 'myChart', deploymentName: 'myRelease', image: 'nginx', containerRegistryUrl: 'https://docker.io'
```

--------------------------------

### Configuring abapEnvironmentAssemblePackages with Direct Host and Credentials (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapEnvironmentAssemblePackages.md

This YAML configuration example shows how to directly specify the `abapCredentialsId` and `host` for the `abapEnvironmentAssemblePackages` step within a `config.yml` file, bypassing Cloud Foundry service key lookups.

```yaml
steps:
  abapEnvironmentAssemblePackages:
    abapCredentialsId: 'abapCredentialsId',
    host: 'https://myABAPendpoint.com',
```

--------------------------------

### Defining Mockable Interface and Real Implementation in Go

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

This Go code defines `myStepUtils` interface for file operations and `myUtilsData` struct which implements this interface using `piperutils.Files`. It allows for dependency injection, enabling easy mocking of file system interactions during testing.

```Go
import (
    "github.com/SAP/jenkins-library/pkg/piperutils"
)

type myStepUtils interface {
    fileExists(path string) (bool, error)
    fileRead(path string) ([]byte, error)
}

type myUtilsData struct {
    fileUtils piperutils.Files
}

func (u *myUtilsData) fileExists(path string) (bool, error) {
    return u.fileUtils.FileExists(path)
}

func (u *myUtilsData) fileRead(path string) ([]byte, error) {
    return u.fileUtils.FileRead(path)
}
```

--------------------------------

### Using Mockable Interface in Go Step Functions

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

This Go code demonstrates how to initialize `myUtilsData` with `piperutils.Files` in the main `step` function and pass it as `myStepUtils` interface to the `runStep` function. This pattern allows the `runStep` function to operate on an abstract interface, facilitating testability.

```Go
func step(options stepOptions, _ *telemetry.CustomData) {
    utils := myUtilsData{
        fileUtils: piperutils.Files{},
    }
    err := runStep(&options, &utils)
    ...
}

func runStep(options *stepOptions, utils myStepUtils) error {
    ...
    exists, err := utils.fileExists(path)
    ...
}
```

--------------------------------

### Configuring VS Code Go Debugging (JSON)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

This JSON snippet shows a 'launch.json' configuration for debugging a Go binary ('piper.exe') in VS Code. It specifies the program path, execution mode, and command-line arguments required for a 'checkmarxExecuteScan' operation, enabling easy debugging of Piper steps.

```javascript
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "type": "go",
            "request": "launch",
            "mode": "exec",
            "program": "C:/CF@HCP/git/jenkins-library-public/piper.exe",
            "env": {},
            "args": ["checkmarxExecuteScan", "--password", "abcd", "--username", "1234", "--projectName", "testProject4711", "--serverUrl", "https://cx.server.com/"]
        }
    ]
}
```

--------------------------------

### Example addon.yml Descriptor File - YAML

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapLandscapePortalUpdateAddOnProduct.md

This YAML snippet illustrates the structure of an `addon.yml` descriptor file, which is used to define details about an addon product and its version. This file is typically referenced by the `abapLandscapePortalUpdateAddOnProduct` step to provide specific addon metadata.

```yaml
addonProduct: some-addon-product
addonVersion: some-addon-version
```

--------------------------------

### Initializing Groovy Beans with Named Parameters (Incorrect)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

Illustrates the incorrect way to initialize Groovy beans using named parameters, which is explicitly stated as not supported by Jenkins. This syntax should be avoided for bean instantiation in a Jenkins context.

```Groovy
Version javaVersion = new Version( major: 1, minor: 8)
```

--------------------------------

### Initializing Jenkins Pipeline with Prepare Stage - Groovy

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/guidedtour.md

This Jenkinsfile snippet defines a basic pipeline with a 'prepare' stage. It checks out the source code and sets up common pipeline environment variables using the 'piper-lib-os' shared library. This stage is crucial for synchronizing the repository and initializing project-specific settings.

```Groovy
@Library('piper-lib-os') _
node() {
    stage('prepare') {
        checkout scm
        setupCommonPipelineEnvironment script:this
    }
}
```

--------------------------------

### Example YAML Manifest with Variable Substitution for Cloud Foundry Services (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/cloudFoundryCreateService.md

This YAML snippet shows a `manifest.yml` file adapted for variable substitution, where service names are defined using placeholders like `((name1))`. These placeholders can be dynamically replaced at runtime, allowing for flexible service naming.

```yaml

---
create-services:
- name:   ((name1))
  broker: "mongodb"
  plan:   "v4.0-dev"

- name:   ((name2))
  broker: "mongodb"
  plan:   "v4.0-dev"

- name:   ((name3))
  broker: "mongodb"
  plan:   "v4.0-dev"
```

--------------------------------

### Omitting Curly Braces in GStrings for Variables

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

Illustrates the Groovy style guide recommendation to omit curly braces ({}) when interpolating simple variables or 'variable.property' directly within GStrings, enhancing readability. The example shows both the less preferred and preferred syntax.

```Groovy
echo "[INFO] ${name} version ${version.version} is installed."
```

```Groovy
echo "[INFO] $name version $version.version is installed."
```

--------------------------------

### Basic ATC System Configuration JSON Example

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapEnvironmentPushATCSystemConfig.md

This JSON snippet provides a basic structure for an `atcSystemConfig.json` file, used to create or update an ATC System Configuration. It defines the configuration name, the ATC check variant to be used, and specifies the behavior for blocking and informing about findings, without any specific priority overrides.

```JSON
{
  "conf_name": "myATCSystemConfigurationName",
  "checkvariant": "SAP_CLOUD_PLATFORM_ATC_DEFAULT",
  "block_findings": "0",
  "inform_findings": "1"
}
```

--------------------------------

### Starting SAPUI5 QUnit Integration Tests - JavaScript

Source: https://github.com/phgermanov/jenkins-library/blob/master/integration/testdata/TestKarmaIntegration/src/frontend/test/integration/opaTests.qunit.html

This snippet initializes and starts the QUnit test suite for SAPUI5 OPA5 integration tests. It requires the 'AllJourneys' module, which typically aggregates all individual test journeys, and then calls QUnit.start() to begin test execution. This setup is common for running automated UI tests in SAPUI5 applications.

```JavaScript
jQuery.sap.require("sap.ui.piper.test.integration.AllJourneys"); QUnit.start();
```

--------------------------------

### Basic Kaniko Execution in Jenkins (Groovy)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/kanikoExecute.md

A simple example demonstrating the basic invocation of the `kanikoExecute` step within a Jenkins pipeline, passing the current script context. This is the most common way to use the step when configuration is handled via a `config.yml` file.

```Groovy
kanikoExecute script:this
```

--------------------------------

### Configuring Build Tool for Pull-Request Voting (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/stages/examples.md

This YAML configuration snippet, typically found in `.pipeline/config.yml`, specifies the build tool to be used for a pipeline, in this case, 'npm'. This is relevant for scenarios like pure pull-request voting where specific build environment settings are needed.

```YAML
general:
  buildTool: 'npm'
```

--------------------------------

### Configuring Malware Scan Step Parameters

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/malwareExecuteScan.md

This configuration snippet illustrates how to define parameters for the `malwareExecuteScan` step within a Jenkins pipeline's `steps` block. It specifies the target file, the host URL of the malware scanning service, and the Jenkins credential ID for authentication.

```yaml
steps:
    malwareExecuteScan:
        file: myFile.zip
        host: https://malwarescanner.example.sap.com
        malwareScanCredentialsId: MALWARESCAN
```

--------------------------------

### Cloning a Project Fork with Git - Shell

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

This snippet demonstrates how to fork and clone the jenkins-library repository, set up the local directory structure, and configure Git remotes for upstream synchronization. It ensures the project is checked out outside of GOPATH using Go modules.

```shell
mkdir -p ${HOME}/projects/jenkins-library
cd ${HOME}/projects
git clone git@github.com:${YOUR_GITHUB_USERNAME}/jenkins-library.git
cd jenkins-library
git remote add upstream git@github.com:sap/jenkins-library.git
git remote set-url --push upstream no_push
```

--------------------------------

### Cloning ABAP Repository in Jenkinsfile (Groovy)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/gctsCloneRepository.md

This Groovy example demonstrates how to use the `gctsCloneRepository` step directly within a Jenkinsfile. It configures the ABAP host, client, credentials, and the repository to be cloned, passing the current script context for environment access.

```Groovy
gctsCloneRepository(
  script: this,
  host: 'https://abap.server.com:port',
  client: '000',
  abapCredentialsId: 'ABAPUserPasswordCredentialsId',
  repository: 'myrepo'
)
```

--------------------------------

### Direct ABAP Credentials Configuration for `abapEnvironmentPullGitRepo` in Jenkinsfile (Groovy)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapEnvironmentPullGitRepo.md

This Groovy snippet demonstrates how to directly configure the `abapEnvironmentPullGitRepo` step within a Jenkinsfile, providing all parameters inline. It includes `script: this`, `repositoryName`, `CommitID`, `abapCredentialsId`, and `host` for direct communication arrangement setup.

```groovy
abapEnvironmentPullGitRepo (
  script: this,
  repositoryName: '/DMO/GIT_REPOSITORY',
  CommitID: 'abcd1234'
  abapCredentialsId: 'abapCredentialsId',
  host: '1234-abcd-5678-efgh-ijk.abap.eu10.hana.ondemand.com'
)
```

--------------------------------

### Customizing HTTP Client Retries in Go

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

This snippet illustrates how to customize the automatic retry behavior of the `piperhttp` client. By setting `MaxRetries` in `ClientOptions`, developers can override the default 15 retries, for example, setting it to `-1` to disable retries or a specific lower number for more stable services. This allows fine-grained control over network resilience.

```golang
clientOptions := piperhttp.ClientOptions{}
clientOptions.MaxRetries = -1
httpClient.SetOptions(clientOptions)
```

--------------------------------

### Uploading App to ASC using Command Line

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/ascAppUpload.md

This snippet shows how to execute the `ascAppUpload` step directly from the command line using the `piper` CLI tool. This method is suitable for local execution or integration into shell scripts.

```Shell
piper ascAppUpload
```

--------------------------------

### Advanced npmExecuteTests with Custom Script and Vault Credentials (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/npmExecuteTests.md

This YAML configuration shows an advanced usage of `npmExecuteTests`, defining custom install and run commands, and specifying environment variables for username and password, which are intended to be populated from a Vault configuration.

```yaml
stages:
  - name: Test
    steps:
      - name: npmExecuteTests
        type: npmExecuteTests
        params:
          installCommand: "npm install"
          runCommand: "npm run custom-e2e-test"
          usernameEnvVar: "e2e_username"
          passwordEnvVar: "e2e_password"
          baseUrl: "http://example.com/index.html"
          urlOptionPrefix: "--base-url="
```

--------------------------------

### Executing cloudFoundryCreateServiceKey via Command Line

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/cloudFoundryCreateServiceKey.md

This snippet shows how to execute the `cloudFoundryCreateServiceKey` step directly from the command line. This method utilizes the `piper` CLI tool and is suitable for non-Jenkins environments or for local development and testing.

```sh
piper cloudFoundryCreateServiceKey
```

--------------------------------

### Handling Variable Shadowing in Parallel Go Table Tests

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

This example illustrates how to prevent variable overwriting issues in parallel table-driven tests. By creating a shadowed instance of the loop variable (`testCase := testCase`) within the loop body, each `t.Run()` closure captures its specific test case value, ensuring it remains fixed during parallel execution.

```Go
func TestMethod(t *testing.T) {
    t.Parallel() // indicates that this method can parallel to other methods
    testCases := []struct {
        Name string
    }{
        {
            Name: "Name1"
        },
        {
            Name: "Name2"
        }
    }

    for _, testCase := range testCases { // testCase defined here is re-assigned in each iteration
        testCase := testCase // define new variable within loop to detach from overwriting of the outer testCase variable by next loop iteration
        // The same variable name "testCase" is used for convenience.
        t.Run(testCase.Name, func(t *testing.T) {
            t.Parallel() // indicates that this sub test can run parallel to other sub tests
            // execute test
        })
    }
}
```

--------------------------------

### Handling Fatal Errors with Logging (Go)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

This Go code demonstrates the recommended approach for handling fatal errors in a Jenkins Library step. Using `log.Entry().WithError(err).Fatal()`, it logs the error, performs necessary cleanup actions, and then exits the process, ensuring proper termination.

```golang
...
    if err != nil {
        log.Entry().
            WithError(err).
            Fatal("failed to execute step ...")
    }
```

--------------------------------

### Mocking Interface Implementation and Test Cases in Go

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

This Go code defines `mockUtilsBundle` as a mock implementation of `myStepUtils` for testing file operations. It includes `newMockUtilsBundle` for initialization and `fileExists`/`fileRead` mock methods. The `TestSomeFunction` demonstrates how to use this mock in unit tests for happy and error paths.

```Go
type mockUtilsBundle struct {
    files map[string][]byte
}

func newMockUtilsBundle() mockUtilsBundle {
    utils := mockUtilsBundle{}
    utils.files = map[string][]byte{}
    return utils
}

func (m *mockUtilsBundle) fileExists(path string) (bool, error) {
    content := m.files[path]
    return content != nil, nil
}

func (m *mockUtilsBundle) fileRead(path string) ([]byte, error) {
    content := m.files[path]
    if content == nil {
        return nil, fmt.Errorf("could not read '%s': %w", path, os.ErrNotExist)
    }
    return content, nil
}

// This is how it would be used in tests:

func TestSomeFunction() {
    t.Run("Happy path", func(t *testing.T) {
        // init
        utils := newMockUtilsBundle()
        utils.files["some/path/file.xml"] = []byte(`content of the file`)
        // test
        err := someFunction(&utils)
        // assert
        assert.NoError(t, err)
    })
    t.Run("Error path", func(t *testing.T) {
        // init
        utils := newMockUtilsBundle()
        // test
        err := someFunction(&utils)
        // assert
        assert.EqualError(t, err, "could not read 'some/path/file.xml'")
    })
}
```

--------------------------------

### Example JSON Input for CommonPipelineEnvironment

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapEnvironmentAssembleConfirm.md

This JSON snippet illustrates the expected input format for the CommonPipelineEnvironment. It defines properties for an addon product (e.g., ID, version, patch level) and an array of repositories, each with attributes like name, AAK version, package details, and status. This structure is crucial for automating build and deployment processes.

```json
{"addonProduct":"","addonVersion":"","addonVersionAAK":"","addonUniqueID":"","customerID":"","AddonSpsLevel":"","AddonPatchLevel":"","TargetVectorID":"","repositories":[{"name":"/DMO/REPO_A","tag":"","branch":"","version":"","versionAAK":"0001","PackageName":"SAPK001001REPOA","PackageType":"CPK","SpLevel":"0000","PatchLevel":"0001","PredecessorCommitID":"cbb834e9e03cde177d2f109a6676901972983fbc","Status":"P","Namespace":"/DMO/","SarXMLFilePath":""},{"name":"/DMO/REPO_B","tag":"","branch":"","version":"","versionAAK":"0002","PackageName":"SAPK002001REPOB","PackageType":"CPK","SpLevel":"0001","PatchLevel":"0001","PredecessorCommitID":"2f7d43923c041a07a76c8adc859c737ad772ef26","Status":"P","Namespace":"/DMO/","SarXMLFilePath":""}]}
```

--------------------------------

### Cloning Git Repository via Command Line

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapEnvironmentCloneGitRepo.md

This snippet shows how to execute the `abapEnvironmentCloneGitRepo` step directly from the command line using the `piper` CLI tool. This method is suitable for standalone execution or scripting outside of a Jenkins pipeline, assuming the `piper` tool is installed and configured.

```sh
piper abapEnvironmentCloneGitRepo
```

--------------------------------

### Configuring SAP BTP Neo Environment Deployment (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/scenarios/ui5-sap-cp/Readme.md

This YAML configuration provides an optional setup for deploying the build result to the SAP BTP Neo environment. It sets the `mtaBuild` platform to 'NEO' and defines `neoDeploy` parameters including Jenkins credentials ID, account ID, and the Neo host endpoint.

```yaml
steps:
  mtaBuild:
    platform: 'NEO'
  neoDeploy:
    neo:
      credentialsId: 'NEO-jenkins-credentials-id'
      account: 'your-account-id'
      host: 'hana.ondemand.com'
```

--------------------------------

### Installing Log4brains Globally via npm

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/adr/README.md

This command installs the Log4brains command-line interface (CLI) globally on your system using npm, making it accessible from any directory. It is a prerequisite for managing Architecture Decision Records (ADRs) locally.

```bash
npm install -g log4brains
```

--------------------------------

### Downloading API Provider with Piper CLI

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/apiProviderDownload.md

This snippet illustrates how to execute the `apiProviderDownload` step directly from the command line using the `piper` CLI tool. This method is suitable for environments where Jenkins is not used or for quick, direct execution.

```sh
piper apiProviderDownload
```

--------------------------------

### Example `myConfig.yml` for Change Management

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/checkChangeInDevelopment.md

This YAML snippet provides an example of a `myConfig.yml` file, detailing common change management properties. These properties, such as `changeDocumentLabel`, `cmClientOpts`, `credentialsId`, `endpoint`, and Git parameters, are shared across all change management-related steps.

```YAML
general:
  changeManagement:
    changeDocumentLabel: 'ChangeDocument\s?:'
    cmClientOpts: '-Djavax.net.ssl.trustStore=<path to truststore>'
    credentialsId: 'CM'
    endpoint: 'https://example.org/cm'
    git:
      from: 'HEAD~1'
      to: 'HEAD'
      format: '%b'
```

--------------------------------

### Example Shared Change Management Configuration (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/transportRequestUploadFile.md

This YAML snippet provides an example of a `myConfig.yml` file, illustrating common configuration parameters under `general/changeManagement`. These parameters, such as `changeDocumentLabel`, `credentialsId`, `type`, `endpoint`, and `git` settings, are shared across various change management-related steps.

```yaml
general:
  changeManagement:
    changeDocumentLabel: 'ChangeDocument\s?:'
    cmClientOpts: '-Djavax.net.ssl.trustStore=<path to truststore>'
    credentialsId: 'CM'
    type: 'SOLMAN'
    endpoint: 'https://example.org/cm'
    git:
      from: 'HEAD~1'
      to: 'HEAD'
      format: '%b'
```

--------------------------------

### Invoking transportRequestRelease Step Examples (Groovy)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/transportRequestRelease.md

This Groovy snippet provides practical examples of directly invoking the transportRequestRelease step within a Jenkins pipeline. It demonstrates configurations for both SOLMAN and CTS change management types, specifying required parameters like script, changeDocumentId (for SOLMAN), transportRequestId, and the changeManagement map with type and endpoint.

```Groovy
// SOLMAN
transportRequestRelease script:this,
                        changeDocumentId: '001',
                        transportRequestId: '001',
                        changeManagement: [
                          type: 'SOLMAN'
                          endpoint: 'https://example.org/cm'
                        ]
// CTS
transportRequestRelease script:this,
                        transportRequestId: '001',
                        changeManagement: [
                          type: 'CTS'
                          endpoint: 'https://example.org/cm'
                        ]
```

--------------------------------

### Configuring apiProviderList Parameters in YAML

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/apiProviderList.md

This YAML configuration example demonstrates how to define and customize the `apiProviderList` step and its parameters within a `.pipeline/config.yaml` file. It showcases the use of various parameters such as `apimApiServiceKeyCredentialsId`, `Top`, `Skip`, `Filter`, `Orderby`, `Count`, `Search`, `Select`, and `Expand` to control the behavior of the API provider list retrieval.

```yaml
steps:
  <...>
  apiProviderList:
    apimApiServiceKeyCredentialsId: 'MY_API_SERVICE_KEY'
    Top: MY_API_PROVIDER_GET_N_ENTITIES
    Skip: MY_API_PROVIDER_SKIP_N_ENTITIES
    Filter: MY_API_PROVIDER_FILTER_BY_ENTITY_FIELD
    Orderby: MY_API_PROVIDER_ORDER_BY_ENTITY_FIELD
    Count: MY_API_PROVIDER_ORDER_ENTITY_COUNT
    Search: MY_API_PROVIDER_SEARCH_BY_ENTITY_FIELD
    Select: MY_API_PROVIDER_SELECT_BY_ENTITY_FIELD
    Expand: MY_API_PROVIDER_EXPAND_BY_ENTITY_FIELD
```

--------------------------------

### Defining ATC Object Set in atcConfig.yml - YAML

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/pipelines/abapEnvironment/stages/test.md

This `atcConfig.yml` snippet specifies the software components to be checked by ATC. In this example, it configures the ATC stage to run checks against the `/DMO/SWC` software component.

```yaml
objectSet:
  softwarecomponents:
    - name: "/DMO/SWC"
```

--------------------------------

### Building and Running TomEE Application via Maven

Source: https://github.com/phgermanov/jenkins-library/blob/master/integration/testdata/TestMavenIntegration/cloud-sdk-tomee-archetype/application/src/main/webapp/index.html

This command line snippet uses Maven to compile and package the application, then runs it using the TomEE plugin. It's intended to be executed from the `application/` directory to start the local development server for the SAP BTP Cloud Foundry TomEE application.

```Shell
mvn package tomee:run
```

--------------------------------

### Executing uiVeri5 Tests via Command Line

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/uiVeri5ExecuteTests.md

This snippet illustrates how to execute the `uiVeri5ExecuteTests` step directly from the command line using the `piper` CLI tool. This method provides a simple and direct invocation of the step, suitable for local development or non-orchestrated environments.

```Shell
piper uiVeri5ExecuteTests
```

--------------------------------

### Omitting .class Suffix in Groovy

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

Demonstrates the Groovy convention of omitting the '.class' suffix for class literals, improving readability and simplicity. This is a common Groovy idiom that simplifies type references.

```Groovy
new ExpectedException().expect(AbortException.class)
```

```Groovy
new ExpectedException().expect(AbortException)
```

--------------------------------

### Wrapping Errors for Context (Go)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

This Go snippet illustrates the practice of wrapping errors using `github.com/pkg/errors` to enrich error messages with context. This technique helps in tracing the root cause of issues by preserving the original error and adding contextual information as the error propagates.

```golang
f, err := os.Open(path)
    if err != nil {
        return errors.Wrapf(err, "open failed for %v", path)
    }
    defer f.Close()
```

--------------------------------

### Setting Up Project Piper CLI Shell Completion - Shell

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/cli/index.md

This command provides instructions on how to set up shell completion scripts for the Project 'Piper' CLI. Shell completion enhances interactive usage by suggesting commands and arguments.

```Shell
piper completion --help
```

--------------------------------

### Configuring ATC with Packages and Software Components (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapEnvironmentRunATCCheck.md

This `atcconfig.yml` example demonstrates how to specify both software components and packages for an ATC check. It also includes `packagetrees` to include subpackages. Note that the API combines these sets with a logical AND operation, so it's often advised to specify either software components or packages, but not both.

```YAML
objectset:
  softwarecomponents:
    - name: TestComponent
    - name: TestComponent2  
  packages:
    - name: TestPackage
  packagetrees:
    - name: TestPackageWithSubpackages
```

--------------------------------

### Deploying Git Repository to ABAP System using Command Line

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/gctsDeploy.md

This snippet shows how to execute the `gctsDeploy` step directly from the command line using the `piper` CLI tool. This method is suitable for non-orchestrator environments or for quick, manual deployments, relying on environment variables or a `config.yml` file for parameter configuration.

```sh
piper gctsDeploy
```

--------------------------------

### Basic Jenkinsfile Call for Integration Artifact Undeploy

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/integrationArtifactUnDeploy.md

This example illustrates a simple invocation of the 'integrationArtifactUnDeploy' step within a Jenkinsfile. The 'script: this' parameter is crucial for providing the step with access to the Jenkins pipeline's execution context and environment.

```groovy
integrationArtifactUnDeploy script: this
```

--------------------------------

### Structuring Go Unit Tests with Subtests

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/DEVELOPMENT.md

This snippet demonstrates a recommended pattern for structuring Go unit tests using `t.Run` subtests. This approach allows for multiple test cases within a single test function, improving test output readability and organization. It encourages clear separation of initialization, testing, and assertion phases for each scenario.

```golang
func TestNameOfFunctionUnderTest(t *testing.T) {
    t.Run("A description of the test case", func(t *testing.T) {
        // init
        // test
        // assert
    })
    t.Run("Another test case", func(t *testing.T) {
        // init
        // test
        // assert
    })
}
```

--------------------------------

### Defining Multitarget Application Descriptor - YAML

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/guidedtour.md

This `mta.yaml` file defines the metadata for a multitarget application. It specifies the schema version, application ID, version, description, provider, and a single module named 'piper.node.hello.world' of type 'nodejs' located in the current directory. This descriptor is consumed by the `mtaBuild` step.

```YAML
_schema-version: 2.1.0
ID: com.sap.piper.node.hello.world
version: 1.0.0
description: A Hello World sample application
provider: SAP Sample generator
modules:
  - name: piper.node.hello.world
    type: nodejs
    path: .
```

--------------------------------

### Executing Gauge Tests Command

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/gaugeExecuteTests.md

This command specifies how Gauge tests are executed. The example shows running tests silently ('-s') and from a specific project path ('-p specs/'), allowing for customized test execution flows.

```Gauge CLI
run -s -p specs/
```

--------------------------------

### Recommended Way to Pass Credentials to UIVeri5 in Jenkins Pipeline (Groovy)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/uiVeri5ExecuteTests.md

This Groovy example illustrates the recommended secure approach for passing credentials to UIVeri5 tests in a Jenkins pipeline. It uses `withCredentials` to fetch `TEST_USER` and `TEST_PASS` directly into environment variables, which are then picked up by the `conf.js` file, avoiding the exposure of secrets in `runOptions`.

```Groovy
withCredentials([usernamePassword(
    credentialsId: 'MY_ACCEPTANCE_CREDENTIALS',
    passwordVariable: 'TEST_PASS',
    usernameVariable: 'TEST_USER'
)]) {
    uiVeri5ExecuteTests script: this, runOptions: ["--seleniumAddress=http://localhost:4444/wd/hub", "./uiveri5/conf.js"]
}
```

--------------------------------

### Configuring ATC with Only Software Components (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapEnvironmentRunATCCheck.md

This `atcconfig.yml` example illustrates how to define an ATC check solely based on software components. This is a common and recommended approach when the scope of the check is defined by the software components deployed in the ABAP environment.

```YAML
objectset:
  softwarecomponents:
    - name: TestComponent
    - name: TestComponent2
```

--------------------------------

### Configuring Maven Bindings from URL (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/cnbBuild.md

This snippet illustrates how to fetch Maven settings from a remote URL for a buildpack binding. This approach is suitable when the settings file is hosted externally and needs to be dynamically retrieved.

```yaml
bindings:
  maven-settings:
    type: maven
    data:
    - key: settings.xml
      fromUrl: https://url-to/setting.xml
```

--------------------------------

### Running Grafana Docker Container

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/influxWriteData.md

This command starts a Grafana Docker container, mapping port 3000, setting a restart policy, naming the container, linking it to the `influxdb` container, and setting the admin password. It uses the `grafana/grafana` image.

```Shell
docker run -d -p 3000:3000 --name grafana --restart=always --link influxdb:influxdb -e "GF_SECURITY_ADMIN_PASSWORD=adminPwd" grafana/grafana
```

--------------------------------

### Running InfluxDB Docker Container

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/influxWriteData.md

This command starts an InfluxDB Docker container, mapping ports 8083 and 8086, setting a restart policy, naming the container, and mounting a volume for data persistence. It uses the official `influxdb` image.

```Shell
docker run -d -p 8083:8083 -p 8086:8086 --restart=always --name influxdb -v /var/influx_data:/var/lib/influxdb influxdb
```

--------------------------------

### Verifying Project Piper CLI Version - Shell

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/cli/index.md

This command is used to verify the installed version of the Project 'Piper' CLI. It helps confirm that the correct binary is in use and accessible in the system's `$PATH`.

```Shell
piper version
```

--------------------------------

### Creating ABAP Environment System using Command Line

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapEnvironmentCreateSystem.md

This shell command shows how to execute the `abapEnvironmentCreateSystem` step directly from the command line using the `piper` CLI tool. This method is suitable for direct execution without an orchestrator like Jenkins.

```sh
piper abapEnvironmentCreateSystem
```

--------------------------------

### Configuring ATC with Only Packages and Package Trees (YAML)

Source: https://github.com/phgermanov/jenkins-library/blob/master/documentation/docs/steps/abapEnvironmentRunATCCheck.md

This `atcconfig.yml` example shows how to configure an ATC check to include only specific packages and their subpackages using `packagetrees`. This approach is suitable when the scope of the ATC run is defined purely by ABAP packages.

```YAML
objectset:
  packages:
    - name: TestPackage
  packagetrees:
    - name: TestPackageWithSubpackages
```