- MTA extension description files can now be configured in the pipeline_config.yml per stage. For more information please visit the configuration guide.
- The lint stage now supports the SAPUI5 best practices linting also for ecmascript version 6. To enable es6 linting follow the instructions as described here.
- In case of a missing package-lock.json the npm audit as well as the whitesource scan will not fail anymore but instead will install the npm packages and inform at which path a package-lock.json is expected.
@Grabannotations have been removed from the cloud-s4-sdk-pipeline-library to not depend on downloading external dependencies during a pipeline execution anymore.
- Multiple error messages have been improved to make it easier to solve issues with the pipeline and find solutions in the configuration guide.
- To analyze long running pipeline stages easier the duration of the pipeline will now be printed to the log.
- For MTA projects the java modules as well as the root pom.xml are installed to the local maven repository to be reusable for following pipeline stages e.g. integration-tests.
Support for project-specific pipeline extensions.
This feature allows you to change or rewrite individual stages of the pipeline.
It should not be required for most users to do this, but there are few good use-cases for this, such as:
- Custom lint tools
- As of
v21one lint tool (SAPUI5 Best Practices) is automatically run as part of the Pipeline. You may want to add additional linters (such as Checkstyle) to the pipeline to ensure common code standards in your team.
- An example for running Checkstyle as an extension is provided in the documentation.
- As of
- Additional third party code analyzers
- The pipeline has support for Checkmarx, Fortify, SourceClear and WhiteSource built in.
- Additional tools can be integrated by providing a custom
For background information and usage instructions, see Pipeline extensibility.
- Improved SAPUI5 Best Practices lint
- In previous versions, the linter was limited to a single UI5 component per project. The new version automatically discovers UI5 components in your project and lints them. Please refer to the documentation for usage instructions.
- The linter can also be run from the command line as described in the README file.
- NPM Audit and WhiteSource scan are run for all directories that contain a
- Removed dependency on
@Grabto avoid proxy configuration issues as described here.
- The supported package structure for SAP Cloud Application Programming (CAP) Model projects has changed
- CAP projects have a
pom.xmlfile in the project's root directory now, which makes it simple to import them into Java development environments such as IntelliJ IDEA or Eclipse.
- Please refer to the SAP Cloud Application Programming Model / MTA section of the build tools documentation for details on accepted project structures.
- Existing CAP/MTA projects need to be migrated.
- CAP projects have a
- Tomcat archetype removed from README as it won't be available in future versions of SAP Cloud SDK.
- Existing projects based on the archetype do still work in the pipeline, but the archetype is not tested with new pipeline versions anymore.
- The following checks are run in MTA modules of the types
html5now, if they are configured:
- Frontend unit tests
- Support Fortify client version 18.x
The build aborts now if the Checkmarx plugin reports findings, to avoid false negatives where the pipeline looks "successful" but Checkmarx actually has severe findings.
This is a potentially "breaking" change for projects above the threshold.
If your build fails due to this reason, and you cannot quickly address the reported issues, please stay with
v19 of the pipeline until you can fix them.
- Fix error case for WhiteSource scan where the URL was constructed wrongly
As SAP S/4HANA Cloud SDK was renamed to SAP Cloud SDK, this release adapts to the new name.
- Adapt to the name SAP Cloud SDK in documentation and user interface
- Enable Maven download cache for projects using MTA as the build tool
- Update to version 2.1.0 of the MTA cli plugin for CloudFoundry in the cf-cli Docker image
- This release significantly enhances the support for projects based on the SAP Cloud Application Programming (CAP) Model. As soon as the new CAP template is available in SAP WebIDE, projects can use the stages listed in build-tools. SAP Cloud Application Programming Model projects which use the old structure will be informed by the pipeline to adapt to the new structure. This is mandatory and documented in build-tools.
- MTA projects now support the use of the download cache as well as a project-specific maven settings file defined in
- End-to-end tests can now also report their results in JUnit format. Earlier, only cucumber was supported.
- Updated project "Piper" jenkins library to the lastest version
- To enable Integration-tests which rely on other systems that can be started as a local container, like databases, starting a sidecar-container before executing the integration-test is possible now. For more details consult the configuration.
- We improved the documentation of our operations guide regarding the usage of TLS encryption and backups.
- Because of an issue with the latest Chromium version in the end-to-end-tests we set Chromium to a fixed version in our Docker image.
- The pipeline can check for SAP UI 5 best practices as part of a newly introduced
- By default, the pipeline does not fail on lint findings. This can be changed via the pipeline configuration.
- See documentation for usage instructions
- To simplify the configuration of Checkmarx scans it is possible to configure the preset by its name which can be looked up in the Checkmarx Web UI instead of the Id which can only be retrieved by using the Checkmarx REST API
- See documentation for usage instructions
- Code check results from SpotBugs and pmd are presented using Jenkins Warnings Next Generation Plugin
- This plugin brings a new visual style into the Jenkins build page
- Make the
cx-serverdirectory a single point of truth for the state of your Jenkins server by moving TLS and backup directories under the
Any misconfiguration of Nexus or the Jenkins parameter such as proxy or JVM memory will lead to a startup failure of the cx-server.
- The productive deployment to CloudFoundry failed when it was run for the first time due to a bug in the deployment code. This is fixed now.
v15 introduces the following changes:
- The outdated vulnerability check "Node Security Platform" has been removed from the pipeline and replaced it with an implementation based on its successor "npm audit". The pipeline might fail now for you if you are using vulnerable npm dependencies. After auditing and fixing findings, you can use the
auditedAdvisoriesproperty in the
pipeline_config.ymlto declare false positive findings. For detailed information, please have a look into the pipeline configuration reference.
- The pipeline now checks before every execution whether enough disk space is available for a build. If this is not the case, the build is aborted and a corresponding error message is provided. Necessary space is estimated by applying the formula (1GB + 3 * average build size from previous runs).
- The S/4HANA Cloud SDK Jenkins image now supports HTTPS. Please consult the operations guide for details on the setup of a secured instance.
- Even if some deployments fail, all corresponding end-to-end tests will be executed. The corresponding results are visible in the log and help to establish transparency on the healthiness of running app instances, independent from their version.
- Allow listing custom OData services in the configuration that shall be exempted from the check for use of non-public API. The pipeline will not fail when one of those services is accessed. This allows to deliberately declare OData services outside of the public API of SAP S/4HANA Cloud used by the project and at the same time make the decision to use this non-public API transparent. See the corresponding section in the configuration guide.
cx-serverscript now offers a
statuscommand to check the state of Cx-Server related Docker containers. Try it out by running
- The need for redundantly defining proxy settings has been eliminated. Now, all tool-specific proxy settings are derived from the configuration attributes
https_proxy. For details, please consult the operations guide.
- Minor update of SpotBugs version used in pipeline.
- Minor update of Nexus version used for download cache.
- Multiple minor improvements in the operations guide.
- Fixed a bug related to inconsistent script execution behavior when on-the-fly updates of
- Fixed a potential bug in determining the own id of a running docker container when running ancient Docker versions.
In our latest release an old instance will be stopped in your Cloud Foundry space when doing a blue-green deployment instead of deleting it.
For details on how to use the new features, consult the documentation.
The Fortify-scan has been completely reworked and need only one credential configured in Jenkins now.
Our Jenkins stops the backup if there is not enough space left on the machine where it is running. It is logged how much space is available on the device and how big the backup is.
Since this is an open source project everybody can contribute to it. For the reason of simplification we added a Pull Request template.
We have cleaned up the list of Jenkins plugins which is bundled in the Continuous Delivery Toolkit. This reduces the size of the Jenkins master image, and thus makes Jenkins quicker to start.
A consequence is that all plugins which are not bundled with the Continuous Delivery Toolkit anymore are not maintained by the Continuous Delivery Toolkit life cycle management. If you did not install any plugins on your own, we recommend to remove all installed plugins, and then do
Example command to remove all plugins:
docker exec -it s4sdk-jenkins-master rm -rf /var/jenkins_home/plugins/*
- In this release we provide the possibility to split end-to-end tests into multiple sub-scenarios and run those scenarios on different deployments. Therefore it is possible to parallelize the end-to-end tests.
- Furthermore the pipeline scans in productive branches all deployment descriptors like
mta.yamlfor usage of security violating variables. There is still an option to skip scanning which is only recommended for demo purposes.
- For details on how to use the new features, consult the documentation.
- We have updated our operations guide to make it even more easy to understand how to use the life-cycle management of the Cx Server for Continuous Integration and Delivery.
- The pipeline now ensures that builds are executed in the correct order. That means: Earlier builds will be deployed before later builds.
- If the administrator of your Whitesource service has activated additional access level control, a token is needed. This token can now be configured in Jenkins and will be used in the pipeline.