From c295c23f8e82a56953e0332cfcb54cc4e0c35501 Mon Sep 17 00:00:00 2001 From: Kevin Hudemann Date: Wed, 7 Oct 2020 10:16:37 +0200 Subject: [PATCH 1/5] Prepare next release --- release-notes-draft.md | 173 +---------------------------------------- 1 file changed, 1 insertion(+), 172 deletions(-) diff --git a/release-notes-draft.md b/release-notes-draft.md index aa4f917..d9fecc2 100644 --- a/release-notes-draft.md +++ b/release-notes-draft.md @@ -2,181 +2,10 @@ This document describes the changes which will be part of the next release and are already available in the latest version (master branch) of the pipeline. -# v43 +# v44 ## :warning: Breaking changes -### Quality Checks stage - -Due to alignments with project "Piper" the `s4SdkQualityChecks` stage has been removed. -Please remove any configuration for the stage `s4SdkQualityChecks` from your pipeline configuration or custom default configuration. - -### Additional tools stage - -The `Third-party Checks` stage has been aligned with project "Piper" and the `additionalTools` stage was not migrated. -In case you have a custom extension for the `additionalTools` stage, please migrate it to be an extension of the stage `security` instead. -The `security` stage is documented in [project "Piper"](https://sap.github.io/jenkins-library/stages/security/). - -In addition, this stage was used for running code analysis tools, e.g., Vulas, for internal projects, which has been removed as well. - -### Checkmarx Scan stage - -Similarly, the `checkmarxScan` stage has been merged into the project "Piper" stage `security`. -The configuration of Checkmarx needs to be moved to the step configuration of the [checkmarxExecuteScan](https://sap.github.io/jenkins-library/steps/checkmarxExecuteScan/) step. - -For example: - -```diff -- stages: -- checkmarxScan: -+ steps: -+ checkmarxExecuteScan: - groupId: - vulnerabilityThresholdMedium: 5 - checkMarxProjectName: 'My_Application' - vulnerabilityThresholdLow: 999999 - filterPattern: '!**/*.log, !**/*.lock, !**/*.json, !**/*.html, !**/Cx*, **/*.js, **/*.java, **/*.ts' - fullScansScheduled: false - generatePdfReport: true - incremental: true - preset: '36' - checkmarxCredentialsId: CHECKMARX-SCAN - checkmarxServerUrl: http://localhost:8089 -``` - -### NPM dependency audit stage - -Due to alignments with project "Piper" the `npmAudit` stage has been removed. -Please remove any configuration for the stage `npmAudit` from your pipeline configuration or custom default configuration. - -### Lint stage - -The `lint` stage has been aligned with project "Piper" in version v43 and the `checkUi5BestPractices` step was not migrated, since the used tool is deprecated. -In addition, the linting will now be executed as part of the `build` stage instead of in the dedicated `lint` stage. -Thus, the configuration for the `lint` stage has to be removed, as it will not have an effect anymore. -Instead, please configure the step `npmExecuteLint` in the steps section of your project configuration, as described in the [documentation](https://sap.github.io/jenkins-library/steps/npmExecuteLint/). - -For example: - -```diff -stages: -- lint: -- ui5BestPractices: -- esLanguageLevel: es2020 -- failThreshold: -- error: 3 -- warning: 5 -- info: 7 -steps: -+ npmExecuteLint: -+ failOnError: true -``` - -### Static code checks stage - -The `staticCodeChecks` stage has been aligned with project "Piper" in version v43. -The static code checks will now be executed as part of the `build` stage instead of in the dedicated `staticCodeChecks` stage. - -### Frontend unit tests stage - -The `frontendUnitTests` stage has been aligned with project "Piper" in version v43. -The stage has been renamed to `additionalUnitTests`. -Please move any existing stage configuration for the stage `frontendUnitTests` to the stage `additionalUnitTests`. - -For Example: - -```diff -stages: -- frontendUnitTests: -+ additionalUnitTests: - dockerImage: 'myDockerImage' -``` - -### Renaming of sonarQubeScan stage - -Continuing with the alignment efforts, the execution of the step `sonarExecuteScan` has been integrated into the project "Piper" stage `Compliance`, and the Cloud SDK Pipeline executes that stage instead. -To activate this stage, the step `sonarExecuteScan` needs to be configured in your `.pipeline/config.yml` as described in the [documentation](https://sap.github.io/jenkins-library/steps/sonarExecuteScan/). -By default, the pipeline will run the stage only for the productive branch, as before, but you can run it in all branches by configuring the option `runInAllBranches: true` for the stage `compliance`. -Also note that the parameter `sonarProperties` has been renamed to `options`. - -:warning: If you have created an extension for this stage, it needs to be renamed to `compliance.groovy`. - -The following diff shows the necessary migration of the configuration: - -```diff -steps: - -+ sonarExecuteScan: -+ projectKey: "my-project" -+ instance: "MySonar" -+ dockerImage: "myDockerImage" -+ options: -+ - "sonar.sources=./application" - -stages: - -- sonarQubeScan: -+ compliance: # The stage config is only necessary, - runInAllBranches: true # if you need to activate 'runInAllBranches'. -- projectKey: "my-project" -- instance: "MySonar" -- dockerImage: "myDockerImage" -- sonarProperties: -- - "sonar.jacoco.reportPaths=s4hana_pipeline/reports/coverage-reports/unit-tests.exec,s4hana_pipeline/reports/coverage-reports/integration-tests.exec" -- - "sonar.sources=./application" -``` - -Specifying `sonar.jacoco.reportPaths` as previously documented is no longer necessary. - -Recent versions of the SonarQube plugin (8.x) no longer supports coverage reports in .exec binary format. -It only supports .xml reports generated from the JaCoCo maven plugin. -As of now, it is a known issue that importing code coverage into the SonarQube service does not work in the Cloud SDK Pipeline out of the box. -If you need this, please open [an issue on GitHub](https://github.com/sap/cloud-s4-sdk-pipeline/issues). - -### Migration to whitesourceExecuteScan step - -The stage `whitesourceScan` has been replaced with the project "Piper" stage `security`. -Now the step `whitesourceExecuteScan` will be executed and the stage is activated **if** the step `whitesourceExecuteScan` is configured in your `.pipeline/config.yml` file. -The existing configuration for the stage `whitesourceScan` has to be moved to the step `whitesourceExecuteScan` with some modifications: - -```diff -steps: -+ whitesourceExecuteScan: -+ productName: 'THE PRODUCT NAME AS IN WHITESOURCE' -+ orgAdminUserTokenCredentialsId: 'Jenkins-credentials-id-org-token' -+ userTokenCredentialsId: 'Jenkins-credentials-id-user-token' -+ productVersion: 'current' # replaces staticVersion -+ cvssSeverityLimit: 5 # optional - -stages: -- whitesourceScan: -- product: 'THE PRODUCT NAME AS IN WHITESOURCE' -- credentialsId: 'Jenkins-credentials-id-org-token' -- whitesourceUserTokenCredentialsId: 'Jenkins-credentials-id-user-token' -- staticVersion: true -``` - -Note that the step will now **fail the pipeline if the scan finds security vulnerabilities** in any module that exceed the defined severity limit. -This can be controlled with the new parameter `cvssSeverityLimit`. -For more information about the step `whitesourceExecuteScan`, please refer its projert "Piper" [documentation](https://sap.github.io/jenkins-library/steps/whitesourceExecuteScan/). - -With using the new step implementation, there is also a potential change in naming the WhiteSource projects with regard to the version. -The naming scheme for each WhiteSource project that is part of a scan is " - ". -The version part is now guaranteed to be consistent across a single scan. -If the parameter `productVersion` is configured (formerly `staticVersion`), it is taken from there. -Otherwise it is taken from the main build descriptor file (i.e. mta.yaml) in accordance to the step parameter `versioningModel`, which defaults to `major`. -The version in the build descriptor files for each module is ignored. - -### Send notification post action - -Due to alignments with project "Piper" the `sendNotification` post action has been removed. -Please remove any configuration for the post action `sendNotification` from your pipeline configuration or custom default configuration. Please use the project "Piper" step [`mailSendNotification`](https://sap.github.io/jenkins-library/steps/mailSendNotification/) instead. - -### Post Pipeline Hook Extension -We moved some of the post actions into the default "Post Pipeline Hook" stage implementation. -If you implemented an extension for the "Post Pipeline Hook" with the name `postPipelineHook.groovy` please make sure to always run `parameters.originalStage.call()`. -Otherwise, some default post actions might be skipped. - ## New Features ## Fixes From c827617fab192e63396dc49bb0fd534df3cb9c16 Mon Sep 17 00:00:00 2001 From: Kevin Hudemann Date: Wed, 21 Oct 2020 16:12:37 +0200 Subject: [PATCH 2/5] Add note about backend & frontend IT --- release-notes-draft.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/release-notes-draft.md b/release-notes-draft.md index d9fecc2..ec577dd 100644 --- a/release-notes-draft.md +++ b/release-notes-draft.md @@ -6,6 +6,25 @@ This document describes the changes which will be part of the next release and a ## :warning: Breaking changes +### Backend & Frontend Integration Tests + +Due to alignments with project "Piper" the stages `backendIntegrationTests` and `frontendIntegrationTests` have been merged into the project "Piper" stage `integration`. +Please move any existing configuration for the stages `backendIntegrationTests` and `frontendIntegrationTests` to the configuration of the stage `integration`. + +For example: + +```diff +stages: +- backendIntegrationTests: ++ integration: + retry: 2 + credentials: + - alias: 'ERP' + credentialId: 'erp-credentials' + - alias: 'SF' + credentialId: 'successfactors-credentials' +``` + ## New Features ## Fixes From 89ea94fe801210c35a3ecc4fae6b1e6bacb0a796 Mon Sep 17 00:00:00 2001 From: Stephan Assmus Date: Thu, 29 Oct 2020 10:04:04 +0100 Subject: [PATCH 3/5] Explain new "runInAllBranches" toggle Co-Authored-By: Florian Wilhelm --- release-notes-draft.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/release-notes-draft.md b/release-notes-draft.md index ec577dd..a63debd 100644 --- a/release-notes-draft.md +++ b/release-notes-draft.md @@ -30,3 +30,24 @@ stages: ## Fixes ## Improvements + +It is possible to consistently enable or disable all **conditional** stages with the config key `runInAllBranches`. +The stages `productionDeployment`, `artifactDeployment`, `compliance`, and `security` are by default disabled **for non-productive** branches. +They can be enabled also for non-productive branches by configuring the respective stage with `runInAllBranches`. +Example `.pipeline/config.yml` file snippet to enable `security` also in non-productive branches: + +```yaml +stages: + security: + runInAllBranches: true +``` + +Similarily, if there are stages which you do **not** want to run by default also in your **non-productive** branches, you can disable them like this: + +```yaml +stages: + endToEndTests: + runInAllBranches: false +``` + +This would then deviate from the default behavior and run the End to End Tests stage only for the productive branch. From 78da150542689d0f7ec6e574235ba0a0334df14d Mon Sep 17 00:00:00 2001 From: Florian Wilhelm Date: Tue, 3 Nov 2020 14:29:15 +0100 Subject: [PATCH 4/5] Update release-notes-draft.md Co-authored-by: Stephan Assmus --- release-notes-draft.md | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/release-notes-draft.md b/release-notes-draft.md index a63debd..6731a50 100644 --- a/release-notes-draft.md +++ b/release-notes-draft.md @@ -15,14 +15,14 @@ For example: ```diff stages: -- backendIntegrationTests: -+ integration: - retry: 2 - credentials: - - alias: 'ERP' - credentialId: 'erp-credentials' - - alias: 'SF' - credentialId: 'successfactors-credentials' +- backendIntegrationTests: ++ integration: + retry: 2 + credentials: + - alias: 'ERP' + credentialId: 'erp-credentials' + - alias: 'SF' + credentialId: 'successfactors-credentials' ``` ## New Features @@ -31,6 +31,8 @@ stages: ## Improvements +### Conditional Execution of Stages + It is possible to consistently enable or disable all **conditional** stages with the config key `runInAllBranches`. The stages `productionDeployment`, `artifactDeployment`, `compliance`, and `security` are by default disabled **for non-productive** branches. They can be enabled also for non-productive branches by configuring the respective stage with `runInAllBranches`. @@ -51,3 +53,11 @@ stages: ``` This would then deviate from the default behavior and run the End to End Tests stage only for the productive branch. + +### Disable Usage of Deprecated Jenkins Plugins + +The [`checksPublishResults`](https://sap.github.io/jenkins-library/steps/checksPublishResults/) step uses some Jenkins plugins which have been deprecated in favor of [`warnings-ng`](https://plugins.jenkins.io/warnings-ng/). +When replacing the SAP Cloud SDK Pipeline specific build stage with the more generic build stage of project "Piper", those plugins became a requirement of SAP Cloud SDK Pipeline, which was not intended. +Due to backwards compatibility concerns in [project "Piper" general purpose pipeline](https://sap.github.io/jenkins-library/stages/introduction/), the old plugins are still available, but they have been disabled by default in SAP Cloud SDK Pipeline so that having those plugins installed is not required anymore. + +If you need any of the old plugins, see the docs of the [`checksPublishResults`](https://sap.github.io/jenkins-library/steps/checksPublishResults/) step to enable them in your pipeline config file. From deea9fa86c6e62b81c2e11042bd2cc41b229ab30 Mon Sep 17 00:00:00 2001 From: s4sdkJenkinsBot Date: Tue, 3 Nov 2020 14:12:08 +0000 Subject: [PATCH 5/5] Set release version v44 --- s4sdk-pipeline.groovy | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/s4sdk-pipeline.groovy b/s4sdk-pipeline.groovy index dadfcd5..0b1a2f7 100644 --- a/s4sdk-pipeline.groovy +++ b/s4sdk-pipeline.groovy @@ -1,6 +1,6 @@ #!/usr/bin/env groovy -final def pipelineSdkVersion = 'master' +final def pipelineSdkVersion = 'v44' library "s4sdk-pipeline-library@${pipelineSdkVersion}" cloudSdkPipeline(script: this)