* fetch xsuaa credentials in newman execution
* refactor CfUtils and moving to integration package
* removing CfUtils from old package com.sap.piper
* avoid config.verbose as "null"
* variable renamed for consistent naming
* handling NPE and other comments incorp
* added test cases
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
Co-authored-by: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* The metadata for artifactPrepareVersion-go specifies a container for when the buildTool is maven.
* The alias to 'mavenExecute' was removed. The problem with this is that when a section containers is included in the metadata, dockerImage will always be picked up from mavenExecute, the conditional dependency on buildTool will not even be considered. Parameters such as m2Path, projectSettingsFile and globalSettingsFile should be configured in general/maven if necessary.
* When the step ends up being executed within dockerExecuteOnKubernetes, we need to preserve the .git folder. This folder would normally be excluded by the default excludes of the stash step. There was already a comment that suppressing this behavior by passing useDefaultExcludes: false was problematic (unfortunately without going into details), so I've added a new parameter to dockerExecute and dockerExecuteOnKubernetes named stashNoDefaultExcludes (note the reverted meaning to ease preserving the default behavior when this parameter is not provided). This parameter is passed to piperExecuteBin from the artifactPreferVersion groovy wrapper.
* piperExecuteBin - prevent non-speaking exit code 1 error
Make sure that error during context resolution gets more context.
* properly provide golang errors
* improve error message, when no details are available
* Add error category
* Update getConfig.go
The document moved to another location. The currently linked document will be deleted on June 17th.
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
* added new step gctsDeployCommit
* suggested PR fixes applied
* fixed test
* Remove unused imports
Co-authored-by: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* added URL encoding for 'request' parameter
* regenerate after change
* minor changes
* renamed step to 'gctsDeploy'
* changed name
* remove space
Co-authored-by: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
Co-authored-by: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
* write flag for sonar execution to influx
* add missing step metadata file
* first attempt to read influx from disk
* add missing import
* correct glob pattern
* use file path
* correct type names
* cleanup
* fix code climate issue
* fix typo
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
* add test case
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
* Add parameter "--ignoreCustomDefaults"
* Pass to piper customDefaults from config also via --defaultConfig
... and add "--ignoreCustomDefaults".
* Log output when ignoring customDefaults
Co-authored-by: Daniel Kurzynski <daniel.kurzynski@sap.com>
This change enables the setupCommonPipelineEnvironment step to handle
custom default configurations defined in customDefaults parameter of the
project configuration.
Previously, only the getConfig Go step was able to incorporate custom
default configurations.
Update documentation on custom defaults and sharing between projects.
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
* fail in case git add or git commit fails during artifactSetVersion
* check if there is a git config on os level
* better error message in case no user name/mail are configured
Co-authored-by: Srinikitha Kondreddy <srinikitha.kondreddy@sap.com>
Co-authored-by: Srinikitha Kondreddy <srinikitha.kondreddy@sap.com>
Avoid maven error `Unknown lifecycle phase \"-\"` when the value of a define contains `-`.
Don't split and trim maven arguments. Expect they come in as a list, keep them as list.
This is a breaking change compared to the old Groovy implementation which relied on using a shell for calling maven.
As an example, consider this diff:
```diff
- goals: 'org.apache.maven.plugins:maven-help-plugin:3.1.0:evaluate',
- defines: "-Dexpression=$pomPathExpression -DforceStdout -q",
+ goals: ['org.apache.maven.plugins:maven-help-plugin:3.1.0:evaluate'],
+ defines: ["-Dexpression=$pomPathExpression", "-DforceStdout", "-q"],
```
Do not exit with os.Exit(1) but using log.Entry().Fatal() instead
* Golang: forward error details
* extend groovy wrapper to provide proper error message
* create closure for error handling
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>
Also establish mavenExecute() via new JenkinsMavenExecuteRule in Groovy Unit Tests.
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
Co-authored-by: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* handlePipelineStepErrors: allow disabling for stages
* update error handling in stages
* move file loading into try catch
* Cleanup DebugReport before test
Apparantly, the same DebugReport instance is loaded
during all Unit Tests. Avoid left-overs from previous
tests.
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.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>
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>
* provide trust store via JVM parameter
* adjust test cases
* Update vars/sonarExecuteScan.groovy
* Update vars/sonarExecuteScan.groovy
* Update sonarExecuteScan.groovy
* expose seleniumHubCredentialsId in karmaExecuteTests
* expose seleniumHubCredentialsId in uiVeri5ExecuteTests
* refer to documentation of seleniumExecuteTests
* Added documentation of stepParameters being a Groovy map, requiring at least the script reference
* Fix writeToDisk in case value is instance of List
* Fix writeToDisk in case value is instance of List
* Added comments
* Keep String as is, serialize everything else
* Fixed import
Co-authored-by: Sven Merk <33895725+nevskrem@users.noreply.github.com>
* handle NPE
* fix Code Climate issue
* add test case
Co-Authored-By: Maximilian Lenkeit <mlenkeit@users.noreply.github.com>
* correct test case
Co-authored-by: Maximilian Lenkeit <mlenkeit@users.noreply.github.com>
* avoid sending mails to addresses which contain the string noreply
* enrich test to ensure that mails containing the string noreply never end up in recipient list
* Update MailSendNotificationTest.groovy
* inject container metadata via env vars to selenium
* set step-specific env var for uiVeri55ExecuteTests
* Revert "set step-specific env var for uiVeri55ExecuteTests"
This reverts commit 8deb39ac5b.
* remove env vars that indicate piper step
* remove env var to indicate execution through selenium step
Co-Authored-By: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* remove defaulting of docker env vars
Co-Authored-By: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* Update vars/karmaExecuteTests.groovy
Co-Authored-By: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
Co-authored-by: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* writeFile() cannot be passed a Map
I've changed the return type of DebugReport.generateReport() from
String to Map in order to get the generated file name as part of the
return value instead of getting it from a field of DebugReport. The
UnitTest checks whether writeFile() creates the debug_report file
successfully and whether it has the expected contents. The effect
of passing the Map instead of map.contents to writeFile() should
have been an unnecessary wrapping via Map.toString() as in the test,
but in the execution context of Jenkins, this throws an
IllegalArgumentException: Could not instantiate {... and then the
results of map.toString().
* Improve JenkinsWriteFileRule compatibility
Calling m.text.toString() is wrong, since the type stored at m.text
already needs to be a String (or GString). Expecting valid parameters
here makes sure problems are detected by tests already. (All tests
pass as before.)
This fixes configuring sidecars for the given stage when Jenkins runs
on Kubernetes and the surounding stage has passed a stageName via parameters which is different from env.STAGE_NAME.
* 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 code of extensions was not executed within the try-catch-block of
handlePipelineStepErrors. The main benefit of this change is better
logging and re-using the 'unstable' feature also for
extended/overwritten steps.
This is part of the effort to get rid of the "runAsStage" step in the SDK pipeline, and use piperStageWrapper directly. The SDK pipeline currently needs to support for loading "old" extensions where the call() method had different parameters. The support for the exact API can and should be removed, however, having a mechanism for supporting old extension APIs seems beneficial in general.
Another crucial change is the deleteDir() call before unstashing at the beginning of the stage. Without this, the SDK pipeline fails to unstash, since apparently the workspace may not always be clean at that point.
* add evaluateFromMavenPom to piper Utils
* adapt mavenExecute to accept `returnStdout` as parameter. If configured mavenExecute will return the stdout for further processing
* adapt tests of mavenExecute and mavenArtifactVersioning as well as add another exception to CommonStepsTest because mavenExecute will return a String if configured
On groovy level we take into account:
- parameters via signature
- project config
- landscape config(s)
- for docker: nested and plain config
also more tests added ...
In case docker parameters are configured in the project config or
in a landscape layer we have to take care. The corresponding values from
the context config are only the fallbacks.
* 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>
* Add new config mtarName for mtaBuild step
* Remove unnecessary whitespace changes in unit test
* Sort new config & avoid file operation when this config provided
* Modify the test to take the custom name without extension
* Update new config documentation
Co-Authored-By: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* custom mta name should be given with mtar extension
* Updated the config documentation
* Streamline url parsing in piperPipelineStageInit
* Remove .git appendix only once
* Improve the regex for parsing urls
now the colon for the port is contained in the port group. This increases the
understandability of the regex.
* Improve the regex for parsing the urls again
now the leading slash of the path is contained in the path group. This increases the
understandability of the regex.
The parameter map is directly handed over from outside into the step via signature of the call method.
The container map is defined as step parameters, not as parameter handed over (only) via the parameters map.
With the current approach only the container map from the parameters is taken into account. In case the
parametersMap is defined elsewhere it is not taken into account.
* [refactoring] condence common coding for cf deploy
Small change beyond refactoring: for mtaDeploy the user is now quoted.
* more general name: logoutAction -> postDeployAction
# 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
