github.com/xgoffin/jenkins-library@v1.154.0/documentation/docs/stages/introduction.md (about)

     1  # Project "Piper" general purpose pipeline
     2  
     3  The pipeline consists of a sequence of stages where each contains a number of individual steps.
     4  
     5  ## First step: Pull Request Pipeline
     6  
     7  In order to validate pull-requests to your GitHub repository you need to perform two simple steps:
     8  
     9  ### 1. Create Pipeline configuration
    10  
    11  Create a file `.pipeline/config.yml` in your repository (typically in `master` branch) with the following content:
    12  
    13  ``` YAML
    14  general:
    15    buildTool: 'npm'
    16  ```
    17  
    18  !!! note "buildTool"
    19      Please make sure that you specify the correct build tool.
    20      Following are currently supported:
    21  
    22      * `docker`
    23      * `kaniko`
    24      * `maven`
    25      * `mta`
    26      * `npm`
    27  
    28      If your build tool is not in the list you can still use further options as described for [Pull-Request Voting Stage](prvoting.md)
    29  
    30  ### 2. Create Jenkinsfile
    31  
    32  Create a file called `Jenkinsfile` in the root of your repository (typically in `master` branch) with the following content:
    33  
    34  ```groovy
    35  @Library('piper-lib-os') _
    36  
    37  piperPipeline script: this
    38  ```
    39  
    40  **There is typically no need to further touch this file**
    41  
    42  !!! note "Using custom defaults"
    43      It is possible to overwrite/extend the pipeline defaults with custom defaults.
    44  
    45      ```
    46      piperPipeline script: this, customDefaults: ['myCustomDefaults.yml']
    47      ```
    48  
    49      You find more details about the custom defaults in the [configuration section](../configuration.md)
    50  
    51  ## Second step: Prepare pipeline for your main branch
    52  
    53  Extend your configuration to also contain git ssh credentials information.
    54  
    55  Your `.pipeline/config.yml` should then look like:
    56  
    57  ``` YAML
    58  general:
    59    buildTool: 'npm'
    60    gitSshKeyCredentialsId: 'credentials-id-in-jenkins'
    61  ```
    62  
    63  !!! note "gitSshKeyCredentialsId"
    64      The pointer to the Jenkins credentials containing your ssh private key is an important part of the pipeline run.
    65      The credentials are for example required to push automatic versioning information to your GitHub repository.
    66  
    67  ## Subsequent steps: Configure individual stages
    68  
    69  The stages of the pipeline can be configured individually.
    70  As a general rule of thumb, only stages with an existing configuration are executed.
    71  
    72  If no dedicated configuration is required for a step, the precence of relevant files in the repository trigger the step execution.
    73  
    74  **This smart and context-aware way of configuration** allows you an iterative approach to configuring the individual steps.
    75  
    76  The pipeline comprises following stages:
    77  
    78  ### Init
    79  
    80  This stage takes care that the pipeline is initialized correctly.
    81  It will for example:
    82  
    83  * Check out the GitHub repository
    84  * Set up the overall pipeline configuration and perform basic checks
    85  * Identify which pipeline stages to execute based on the configuration and file patterns
    86  * Perform automatic versioning of the software artifact in case the `master` branch pipeline is executed.
    87  
    88  You find details about this stage on  [**Init Stage** Details](init.md)
    89  
    90  ### Pull-Request Voting
    91  
    92  This stage is responsible for validating pull-requests, see also above.
    93  
    94  You find further details about this stage on the page [**Pull-Request Voting**](prvoting.md).
    95  
    96  ### Build
    97  
    98  In this stage the build of the software artifact is performed.
    99  The build artifact will be `stash`ed for use in subsequent stages. For `Docker` builds the build result will be uploaded to a container registry (as per your configuration).
   100  
   101  Afterwards the results of static checks & unit tests are published on the Jenkins.
   102  
   103  You find details about this stage on the page [**Build**](build.md).
   104  
   105  ### Additional Unit Tests
   106  
   107  In this stage additional unit-like tests are executed which should not run during the build.
   108  
   109  Currently, this stage holds the execution of a Karma runner which allows for
   110  
   111  * qUnit tests
   112  * OPA5 (One Page Acceptance tests) for SAPUI5
   113  
   114  You find details about this stage on the page [**Additional Unit Tests**](additionalunittests.md).
   115  
   116  ### Integration
   117  
   118  The [Integration stage](integration.md) allows to run test based on maven, npm, or a custom integration test script.
   119  If more flexibility is required, consider using the [stage extension mechanism](../extensibility.md).
   120  
   121  You find details about this stage on the page [**Integration**](integration.md).
   122  
   123  ### Acceptance
   124  
   125  In this stage the application/service is typically deployed and automated acceptance tests are executed.
   126  
   127  This is to make sure that
   128  
   129  * new functionality is tested end-to-end
   130  * there is no end-to-end regression in existing functionality
   131  
   132  You find details about this stage on the page [**Acceptance**](acceptance.md).
   133  
   134  ### Security
   135  
   136  This stage can run security checks using Checkmarx, Synopsys Detect, Fortify and WhiteSource.
   137  
   138  You find details about this stage on the page [**Security**](security.md).
   139  
   140  ### Performance
   141  
   142  The stage will execute a Gatling test, if the step `gatlingExecuteTests` is configured.
   143  
   144  You find details about this stage on the page [**Performance**](performance.md).
   145  
   146  ### Compliance
   147  
   148  The stage will execute a SonarQube scan, if the step `sonarExecuteSan` is configured.
   149  
   150  You find details about this stage on the page [**Compliance**](compliance.md).
   151  
   152  ### Confirm
   153  
   154  The [Confirm stage](confirm.md), if executed, stops the pipeline execution and asks for manual confirmation before proceeding to the stages _Promote_ and _Release_.
   155  
   156  ### Promote
   157  
   158  This stage is responsible to promote build artifacts to an artifact repository / container registry where they can be used from production deployments.
   159  
   160  You find details about this stage on the page [**Promote**](promote.md).
   161  
   162  ### Release
   163  
   164  This stage is responsible to release/deploy artifacts into your productive landscape.
   165  
   166  You find details about this stage on the page [**Release**](release.md).