* 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
* 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>
This might provide useful context to the user.
For example when you try to upload a SNAPSHOT jar to a maven-release
repo in nexus, this will print an error like
returned with response 400 Repository version policy: RELEASE does
not allow version: 1.0-SNAPSHOT
instead of
returned with HTTP Code 400
* 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
The nexus package implements uploading artifacts to a Nexus repository manager version 2 or 3 via HTTP. It also generates the MD5 and SHA1 hash files for the uploaded artifacts in the Nexus repository.
* chore: streamline GH actions
* force use of local piper
* look for piper in project root
* use local piper
* Update .github/workflows/verify-go.yml
* remove chmod
Have strategy for environment variable handling only once
And provide also a test checking if the environment variables
are present in the forked process.
The strategy applied for setting the environment variables is now
different from what it was before. Before the environment was
fully replaced by the new environment variables. Now we append
our environment variables to the list of environment variables available
by default for the forked process.
Co-authored-by: Florian Geckeler <43751896+fgeckeler@users.noreply.github.com>
ExecMockRunner and ShellMockRunner both needs an environment. "Extending"
here leads to "subclasses" for both cases. That is more long-winded since
it could be.
I don't understand why there should be a two dimensional array.
When dealing with envs we have normally a list containing entries like
[]string{"DEBUG=true", "HOME=/home/me"}
Having two dimensional env arrays would mean to have several alternate
environment in the tests at the same time. Don't think there is a need
for that.
This change allows a development workflow where you don't need to set the `PIPER_INTEGRATION_EXECUTABLE` variable if your executable is available in the CWD. This should make it non-required to set the variable for most cases of local development.
