Version 35

Release v35

This new release contains a change which is especially important if you want to continue to use Fortify in the future. Depending on the Fortify installation and configuration, Fortify will disable the basic authentication access which was used in the previous pipeline versions. In this new version, the pipeline will only rely on token based authentication to communicate with Fortify.

⚠️ Breaking changes

Fortify

The past Fortify scan implementation was replaced by a new step from project "Piper". The configuration options for the step executeFortifyScan and the stage fortifyScan have been removed. Instead, Fortify is solely configured using the step fortifyExecuteScan as documented here.

The new implementation might be slightly different from the old one. Even for CAP projects based on MTA we will use the groupId, artifactId and version from the pom file to generate values for the project name and project version. (Please note that the Fortify user interface refers to the project also as application and to the project version as application version.)

The fortifyProjectName it not required anymore. Instead, it will be generated from the groupId and artifactId. If the generated name would not match your Fortify project name, you can use the projectName parameter to specify it.
Also, the versioning behaves differently. Before, you could configure a projectVersionId and with every scan the version was updated to the current one generated in the pipeline. The new one tries to automatically detect the version id by using the projectName (generated or configured) and the major version of the artifact.
The pipeline will fail if the version cannot be found.

For the migration we recommend creating a new version in the Fortify dashboard by copying the last project version and setting the name of the copy to the major version of your artifact in the project root, e.g. 1.
Please select Application State to copy the application state including all audit results when copying the version. Otherwise, you will have to re-audit all findings.

As the new step does not only scan the maven modules, the set of scanned files might be different. You can control them by using the configuration options src and exclude.

This diff shows how the change looks like:

steps:
-  executeFortifyScan:
-    dockerImage: 'fortify-docker-image:latest'
+  fortifyExecuteScan:
+    dockerImage: 'fortify-docker-image:latest'
+    fortifyCredentialsId: 'fortifyTokenCredentialId'
+    serverUrl: 'https://fortify.dummy.corp.domain/ssc'
stages:
-  fortifyScan:	
-    sscUrl: 'https://fortify.dummy.corp.domain/ssc'	
-    fortifyCredentialId: 'fortifyCredentialId'	
-    fortifyProjectName: 'mySampleProject'	
-    projectVersionId: '12345'

Please note that it might be a good idea to configure some of these values, such as the serverUrl, centrally, e.g. in a project extension, as it done for example within SAP.

Fixes

• Default configuration as well as shared configuration and extension configuration is taken into account when loading stage specific configuration.
• On Kubernetes the pod for the build stage will already contain a docker container to build MTA. No new pod will be scheduled.

Version 34

Release v34

Improvements

• Development dependencies are excluded from the npm audit

Fixes

• MTA build uses the correct configured npm registry without the need for .npmrc files
• Shared pipeline configuration is loaded again from an HTTPS source that requires extra certificates

Version 33

Release v33

🟥 Known issues

Release v33 has known issues that are addressed in v34. Please don't use v33.

Known issues:

• Npm registries are not set correctly, breaking builds that depend on npm install from non-standard registries
• Custom defaults are not loaded correctly

⚠️ Breaking changes

Shared configuration

Shared configuration property in the pipeline configuration file (.pipeline/config.yml) has changed.
It must be a list of strings now named customDefaults, sitting on the top level.

This diff shows how the change looks like:

+customDefaults: ['https://my.github.local/raw/someorg/shared-config/master/backend-service.yml']
general:
    # other properties
-    sharedConfiguration: 'https://my.github.local/raw/someorg/shared-config/master/backend-service.yml'

This change is necessary to align the SAP Cloud SDK Pipeline closer with Project "Piper".
Please refer to Project "Piper" documentation for further details.

Maven 3.6+ required

Please note that maven-related functionality requires Maven version 3.6 or higher in the configured Docker image.
This is handled in the default image, but if you need to provide a custom image please ensure it meets this requirement.
See here for more details.

mavenExecute parameters in extensions

If you make use of the extensibility feature of the pipeline, and use the mavenExecute step in any of your extensions, please take note of the changed api.
The goals, defines and flags parameters of the step need to be lists of strings with each element being one item.
Please consult the step documentation for more details on how the step works.
Note that this change does not affect you if you don't have any extensions in your pipeline.

New Functionality

• SonarQube scans can run in all branches of a project. This can be enabled by setting the runInAllBranches property in the pipeline configuration.

Improvements

• Lint stage will be skipped now if no lintable files (JavaScript or TypeScript) are found in the project, and if no custom Lint stage was provided
• The default maven docker image has been switched to a debian-based image instead of alpine-based
  • In some cases the alpine image might cause issues with native compiled software. One example where this caused issues was when using the maven frontend plugin which downloads node.js, the downloaded node.js version won't work in alpine due to the libc implementation used in alpine.

Fixes

• Default configuration is applied to steps using the new project "Piper" command-line tool
• Some internal configuration changes of the pipeline had been ignored in the new project "Piper" command-line tool before which is fixed now
• WhiteSource scan works again after it broke due to wrong handling of maven parameters
• MTA build uses the correct configured npm registry

Version 32

Release v32

New Functionality

• A custom linting script named ci-lint is executed as part of the Lint stage if it is defined
  in the 'scripts' section of the package.json file(s) of the project. In the absence of this script,
  the Lint stage now also supports non-SAPUI5 Javascript/Typescript projects by executing ESLint with a
  provided default configuration. See the documentation for more details.
• The stage Artifact Deployment can now also deploy npm build artifacts. It uploads everything which is
  not excluded in .npmignore via npm publish. See the documentation for more details.
• Also for the stage Artifact Deployment, the requirements for Maven projects have been relaxed such that
  any multi-module projects are now supported.

Improvements

• To help you avoid errors in the pipeline configuration file .pipeline/config.yml, it is validated against a schema file starting with v29. Any findings are now visualized in the Jenkins UI:
  
  Please note that the validation can never be 100% complete and may therefore show wrong findings and/or miss some problems.
• To offer more control over which rules are used to run the static code checks for maven with pmd and spotbugs, the pipeline does not inject a fixed set of rules anymore.
  Instead the user can configure which rules are executed in the plugins section in the pom.xml of the project.
  All configuration options for the stage staticCodeChecks have been removed.
  Some new parameters were introduced with the new step mavenExecuteStaticCodeChecks.
  Please migrate any existing stage configuration into the corresponding configuration in your pom.xml or step configuration.
  Please find below an example how you can can configure and continue to use the pmd rules provided by the SAP Cloud SDK.

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-pmd-plugin</artifactId>
                <configuration>
                    <rulesets>
                        <ruleset>rulesets/cloud-sdk-qualities.xml</ruleset>
                        <ruleset>rulesets/java/maven-pmd-plugin-default.xml</ruleset>
                    </rulesets>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>com.sap.cloud.sdk.quality</groupId>
                        <artifactId>pmd-rules</artifactId>
                        <version>3.18.0</version>
                    </dependency>
                </dependencies>
            </plugin>
        </plugins>
    </pluginManagement>
    ...
</build>

Version 31

Please ignore this release and instead refer to the release notes for v32.

Version 30

Release v30

New Functionality

The Cloud Foundry Service Broker for SAP HANA Deployment Infrastructure (HDI) containers on SAP Cloud Platform are configurable now (See docs for details).

Improvements

The pipeline is more lenient now with regards to project structure for MTA projects, for example the existence of an integration-tests module is not enforced anymore.

Fixes

The Transport Management System (TMS) upload used an invalid user name format, which is now fixed.

Version 29

Release v29

New Functionality

• The Cloud SDK Pipeline now supports multi-module Maven projects.

  • The stage Unit Tests was merged into the Build stage to remove the need for a unit-tests module. The tests can be part of your productive module. If you have an extension for stageUnitTests it needs to be adopted and extend the Build stage instead.
  • The steps fortifyScan, sonarQubeScan, and the staticCodeChecks also support multi-module Maven projects.

• Users may now disable individual quality checks via the new configuration key s4SdkQualityChecks.

• There is a new stage postPipelineHook for the sole purpose of being overwritten by an extension. This can be used to run custom actions after the pipeline has finished.

• CI-friendly versioning is supported for Maven projects.

• The pipeline will run yarn install if the file yarn.lock exists in the project, but neither of the files package-lock.json or npm-shrinkwrap.json.

Improvements

• The pipeline configuration is now expected at .pipeline/config.yml. The old location at .pipeline_config.yml will be supported for a limited time, please move the configuration file. Note that the documentation as well as error log messages reference the new location consistently.

• Extensions are now expected in .pipeline/extensions to align with the general purpose pipeline. The old location at pipeline/extensions will be supported for a limited time, please move your extensions.

• Service creation in deployments to Cloud Foundry can be controlled via a services manifest file and the new config key cfCreateServices.

• The pipeline supports creating an HDI container and injecting the connection details into the intergration tests not only for MTA projects but also for Maven projects.

• A docker image can be specified for the step sonarQubeScan.

• The pipeline configuration is validated against our schema, any errors will currently appear in the Jenkins log.

• Users may now override the stageInit with an extension.

Version 28

Release v28

Breaking Changes

cloudMbt is now the default build tool for Multi-Target Applications (MTA).

Please note that your mta.yaml file might need some migration to work in the new tool. See the migration documentation for more details.

You can still use the classic build tool if you need to, see the configuration for details.

New Functionality

Multi-Target Applications (MTA) with JavaScript backends can make use of unit- and integration tests in the pipeline now. Please consult the build tools documentation for usage instructions and limitations.

Fixes

The resilience quality check and the check for unofficial API have been updated to work with SAP Cloud SDK version 3.

Version 27

Release v27

New Functionality

Multi-Target Applications (MTA) can make use of the new Cloud MTA Build Tool. In version 27 the classic (Java-based) MTA Builder is still the default option. You can change the used tool as documented.
In Version 28 of the pipeline, the default will be switched to the new build tool.
Please note that your mta.yaml file might need some migration to work in the new tool. See the migration documentation for more details.

Maven projects can have frontend integration tests now, as it was already possible for NodeJS projects. The pipeline will run the ci-it-frontend script from your package.json, if one is provided.

Improvements

You can use a static version for WhiteSource scans, if desired. This means that you won't see multiple entries for your project in WhiteSource. See documentation for more details and usage hints.

Fixes

Previously not all pipeline stages had access to the application's source code due to Jenkins pipeline internals. This has been fixed so the source code is always available.

Version 26

Feature

• Added JSON schema for pipeline configuration. It makes editing a lot better, you get code completion and validation.
• Configuration is now shareable between the projects that are composed of multiple repositories. For details please refer to the documentation.
• TMS can be used for uploading files, see documentation for details on how to configure it.

Improvements

• Now specific URLs can be excluded from being checked in context of ERP API whitelists.
• Jacoco threshold are now configurable to make it more strict. For details please refer to the documentation
• The container images used for Cx Server have changed. cx-server will offer you to migrate to the new images. The migration is highly recommended, because the old images are no longer maintained.
• Support sonarqube scan for better inspection of code, see documentation for information on how to configure.

Fix

• Throw warning when pipeline is running on non-multibranch job.
• Throw error if application name contains underscore because cloud foundry doesn't support underscores.
• Throw warning if application name contains non-alphanumeric characters.