* 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.
