* 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
* Back commonPipelineEnvironment step by shared class
Each pipeline step comes with its own instance of a commonPipelineEnvironment.
Properties stored on one instance was not shared with the other instances.
Now we strip down the commonPipelineEnvironment step and forward basically
everything to a shared singleton instance.
With that approach all instances of commonPipelineEnvironment shares the
same data and can now be really used for information exchange between the steps.
Before that change only the commonPipelineEnvironment instance associated with
the pipeline script itself could be used for that purpose.
* Remove unneeded commented line
* Changes:
- New YamlSubstituteVariables step to substitute variables in YAML files with values from another YAML
- New Tests, that check the different substitution patterns.
- Added test resources, including various manifest and variables files.
- Improved usage of JenkinsLoggingRule
- Improved JenkinsReadYamlRule to properly reflect the mocked library's behaviour.
- Added a new JenkinsWriteYamlRule.
* Changes:
- added a Logger that checks a config.verbose flag before it logs debug messages.
- changed error handling to rethrow Yaml parsing exception in case of wrongly-formatted Yaml files.
- changed JenkinsWriteYamlRule to capture Yaml file details of every invocation of writeYaml. This allows sanity checks at end of tests, even if there were multiple invocations.
- adjusted tests.
* Changes:
- Removed javadoc-code blocks from API documentation since they are not supported.
- Removed skipDeletion boolean.
- Added a new deleteFile script which deletes a file if present.
- Added a new JenkinsDeleteFileRule to mock deleteFile script and optionally skip deletion for tests.
- Adjusted yamlSubstituteVariables script.
- Adjusted tests to include new JenkinsDeleteFileRule.
- Changed code that deletes an already existing output file to produce better logs.
* Changes:
- Turned yamlSubstituteVariables into a script that works purely based on Yaml data (not files).
- Added a new cfManifestSubstituteVariables that uses yamlSubstituteVariables under the hood but works based on files.
- Adjusted tests, and added new ones.
* Adjusted documentation and a few log statements.
* Changed documentation to no longer include javadoc code statements.
* Made mocking of deletion of a file a default. Adjusted tests.
* Changed signature of yamlSubstituteVariables' call method to return void.
* Changes:
- Fixed naming issues in deleteFile.
- Renamed Logger to DebugHelper.
- Fixed some documentation.
* Changed implementation of deleteFile not to use java.io.File - which is evil when using it for file operations.
* PROPERLY Changed implementation of deleteFile not to use java.io.File - which is evil when using it for file operations.
* Changes:
- Added tests for deleteFile script
- Changed JenkinsFileExistsRule to also keep track of which files have been queried for existence.
* Changes:
- Removed java.io.File usage from cfManifestSubstituteVariables and using fileExists instead now.
- Adjusted tests.
* Wrapped file path inside ticks to allow spaces in file path when calling deleteFile.
* Removed null checks of mandatory parameters, and resorted to ConfigurationHelper.withMandatoryProperty
* Fixed a NullPointer due to weird Jenkins / Groovy behaviour.
* Changes:
- Turned yamlSubstituteVariables step into a utils class.
- Added tests
- Adjusted cfManifestSubstituteVariables to use utils class instead of step.
- Adjusted tests
- Adjusted APIs of DebugHelper.
* Re-introduced log statement that shows what variables are being replaced and with what.
* Changing API of YamlUtils to take the script and config as input.
* Test
* Test
* Test
* Test
* Test
* Fixing issue.
* Fixing issue.
* Changes:
- Refactored DebugHelper and YamlUtils to make usage nicer and rely on dependency injection.
- Removed Field for DebugHelper and turned it into local variable.
- Adjusted classes using the above.
- Adjusted tests where necessary.
* Added link to CF standards to YamlUtils also.
* Add docu for step cfManifestSubstituteVariables.md
* Added documentation.
* Added missing script parameter to documentation. Some steps document it, some don't. Right now you need it, so we document it.
* Fixed some layouting and typos
* Beautified exception listing.
* Removed trailing whitespaces to make code climate checks pass.
* Trying to get documentation generated, with all the exceptions to markup one should not use.
* cosmetics.
* cosmetics, part 2
* Code climate changes...
* Inlined deleteFile step.
* Added two more tests to properly check file deletion and output handling.
* Changes:
- adjusted API to take a list of variables files, as does 'cf push --vars-file'
- adjusted API to allow for an optional list of variable key-value-maps as does 'cf push --vars'
- reproduced conflict resolution and overriding behavior of variables files and vars lists
- adjusted tests and documentation
* Added missing paramter to doc comment.
* Re-checked docs for missing paramters or params that have no counterpart in the method signature.
* Adjusted documentation.
* Removed absolute path usage from documentation.
* corrected documentation.
* Changed javadoc comment to plain comment.
* Turned all comments to plain comments.
Before: complete scmInfo was handed over via method signature.
After: Only the relevant part (GIT_URL from scmInfo) is handed over.
All the other properties from scmInfo are not used in the method body.
With this appraoch it is more obvious what is used inside the method.
* dockerExecuteOnKubernetes - add stashBack configuration
For certain cases it is valuable to only bring back some of the files from an execution inside a container back to the workspace.
This is now added.
Closes#753
* refactor according to PR review
