* artifactPrepareVersion: additional options
it is now possible to use
* a Unix timestamp number
* a short commit hash
* Add dedicated Docker versioning scheme
* fix docu
* enhanced step docu and metadata
* regenerate after changing metadata
* small wording change
Co-authored-by: Marcus Holl <marcus.holl@sap.com>
* add possible values for xsDeploy
* add possible values for protecodeExecuteScan
* add possible values for mtaBuild
* add possible values for artifactPrepareVersion
* add possible values for sonarExecuteScan
* add possible values for detectExecuteScan
* add possible values for checkmarxExecuteScan
* Update gctsCreateRepository.yaml
This change enables the use of the artifactPrepareVersion go step instead
of the deprecated artifactSetVersion groovy implementation for the Cloud
SDK Pipeline. The groovy wrapper for the artifactPrepareVersion step now
enables the use of the download cache and minor issues are fixed.
With the step gctsCreateRepository it is possible to create a local gCTS repository on an ABAP server
Co-authored-by: Marcus Holl <marcus.holl@sap.com>
* Extends kubernetesDeploy step to support Helm 3
Currently, the kubernetesDeploy step has no support to Helm 3 due to the fact that:
- the initialization command used works only for Helm 2
- the image used when running the helm CLI is based on Helm 2
The need for Helm 3 support comes from the fact that Helm 3 introduces major architectural changes,
more specifically, the removal of its server-side agent called Tiller - thus, being incompatible with
one another.
This commit adds this support by introducing a new configuration field (helmVersion).
By default, its values is set to 2 (Helm 2) to avoid breaking any existing functionalities.
* Use deployTool field to decide between Helm 2 or 3
* Remove helm init and replace wait for atomic in v3
* Update cmd/kubernetesDeploy.go
Nice catch!
Co-Authored-By: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* Add documentation for kubernetesDeploy step
* Add helm3 example for kubernetesDeploy step using mandatory fields
* Add new line at the end of kubernetesDeploy documentation
* Link kubernetesDeploy step with docs generator
* Add possible values for deployTool in kubernetesDeploy
* dummy change
* Revert "dummy change"
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
Co-authored-by: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* use sonar go in groovy
* use SONAR_TOKEN
* only use owner/repo if both are set
* trim version to major version digit
* fix code climate issues
* remove Sonar defaults
* use sonar go step
* use SONAR_TOKEN
* use certs from parameters
* use docker workspace & options
* add instance parameter
* implement branchName
* implement branchName
* remove duplicate default
* update docs
* fix TODOs
* remove merge mess
* fix code climate issue
* address comments
* respect custom defaults and custom config file name
* fix typo
* remove obsolete test cases
* disable CommonStepChecks
* check step config instead of context config
* remove TODOs
* respect jenkins PR envvars
* use value from stepConfig
* Update vars/sonarExecuteScan.groovy
* rename options to config
* correct type for options
* add test cases
* log sonar.options in debug message
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
* iterate over found pom.xml files for maven projects, deploy found artifacts
* classifiers are found by testing prefix/suffix of artifact
* Remove additionalClassifiers option
* Improve documentation
* Fix fallback for finalBuildName
* Ignore mvn modules with packaging != pom but no target dir
* Fail when main artifact is missing, add more tests
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
* Add ReportAggregator to collect information about executed stages and create reports
* ReportAggregator is used by the SAP Cloud SDK to collect information about which stages were executed,
code coverage and many more measurements.
* based on the measurements a pdf report can be generated which can be used to get a certification by SAP
* Add ReportAggregator to collect information about executed stages and create reports
* ReportAggregator is used by the SAP Cloud SDK to collect information about which stages were executed,
code coverage and many more measurements.
* based on the measurements a pdf report can be generated which can be used to get a certification by SAP
Artifacts to upload are assembled for MTA projects and Maven projects with optional application sub-module. Then maven deploy:deploy-file is used as backend to upload bundles of artifacts plus sub-artifacts.
Co-authored-by: Florian Wilhelm <florian.wilhelm02@sap.com>
* Golang step metadata: Config aliases for steps
This will ease following scenarios:
* config migration due to step name changes
* re-use of more general config, e.g. `mavenExecute` in `mavenBuild`
* fix CodeClimate finding
* Fix panic if original stage config does not exist yet
* add static code checks for maven based projects as:
* pmd plugin
* spotBugs plugin
* test modules as unit-tests and integration-tests will be ignored by default. Additional modules to ignore are configurable
* for pmd: rulesets and excludes are configurable
* for spotBugs: includeFilter and excludeFilter are configurable
* Update schema and hcp deployer version in mta.yaml file
* Add name parameter in mta yaml file
* Rename template_mta.yml to template_mta.yaml
* Fix indentation
Co-authored-by: Oliver Feldmann <oliver.feldmann@sap.com>
Co-authored-by: Marcus Holl <marcus.holl@sap.com>
* Protecode as go implementation
Co-authored-by: Sven Merk <33895725+nevskrem@users.noreply.github.com>
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
The DebugReport is a global instance where steps can store information relevant for diagnosing failed pipelines. In the SDK Pipeline, this is used to generate a debug report within the postActionArchiveDebugLog step. The reason for adding this to Piper is to feed information about extended or overwritten stages in piperStageWrapper into the DebugReport, as was done before in the SDK Pipeline's equivalent runAsStage step.
* Use commonPipelineEnvironment in go binary
* Update groovy part incl. tests
* Rework structure and naming
* Support influx resources in steps
* Update tests and some cleanups
* Add correct defer handling
* Address PR feedback
* Fix test
* Update resources.go
Co-authored-by: Sven Merk <33895725+nevskrem@users.noreply.github.com>
* chore(go): add schema for go metadata files
* chore(go): use k8s container definition in schema
* chore(go): add reusable schema definitions
* chore(go): add further schema definitions
* docs(schema): add description how to use metadata schema
* tests(testsPublishResults): evaluate file pattern for cobertura
* tests(testsPublishResults): test for cobertura in UI5 projects
* feat(testsPublishResults): collect cobertura of UI5 projects by default
# Changes
This PR adds a new step: cloudFoundryServiceCreate
There is a cf community plugin [Create-Service-Push](https://github.com/dawu415/CF-CLI-Create-Service-Push-Plugin) available to apply infrastructure as code to Cloud Foundry. The plugin uses a manifest.yml to create services in a targeted CF space.
The proposed step provides an interface to this plugin.
Already done:
- [x] Tests
- [x] Documentation
Further actions:
- a Refactoring: Move varOptions and varsFileOption code into a class and make us of this here and in cloudFoundryDeploy step. -> Is it ok to use the CfManifestUtils, or add it as a new class to variablesubstitiion package?
- enhance the s4sdk cf cli docker image to include the plugin.
* Provide additional opts for cf deploy
Inside cloudFoundyDeploy we use these cf commands
o login
o plugins
o blue-green-deploy
o push
o deploy
o bg-deploy
o stop
o logout
o logout and stop does not provide any options
o plugins provides options (--checksum --outdated) but it is unlikely that
these options can be used in a reasonable way during the deploy process.
o login now uses `loginOpts`
o The other commands uses now `deployOpts`
* provide additional opts also for cf api calls
* Provide more log when verbose
* re-use mtaDeployParameters and adjust names of other params (api, login) accordingly
* Streamline naming
* distinuish between cfNative and mta deploy params
* Add cfNativeDeployParam default
* login and api paramters are not under cloudFoundry
* Take proper jnlp image as default for Kubernetes execution
Following changes are contained:
* removal of custom jnlp image as default
* allow customization of jnlp image via system environment
fixes#757
* add documentation
* add Slack notification to post stage
* add Slack notification to init stage
* add trigger condition for Slack notification
* fix whitespaces
* use capital stage name
* add tests for init stage
* remove unused import
* add tests for post stage
* minor changes
* fix typo
* whitesourceExecuteScan - fix stashing behavior for golang
**changes:**
golang scan requires sources to be present. They are already part of the `checkmarx` stash which can be used here.
* fix tests
* handlePipelineStepErrors - allow step timeouts
This adds another resilience option:
A timeout can be configured for steps in order to stop step execution, continue with the pipeline while setting build status to "UNSTABLE"
