* make use of new read,writePipelineEnv Steps in groovy
* remove unused cat
Co-authored-by: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* update data type of influx measurements
* Update checkmarx.yaml
* pick changes from #1885 for testing
* update generated code
* update to new datatype
* adjust to type changes
* change back to string type
* Update fortifyExecuteScan.go
* add typo to be backward compatible
* change type to int for files_scanned and lines_of_code_scanned
* add typo
* add measurements to whitesource
* update generated sources
* adjust test cases
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
`piperExecuteBin` is called with a credentials list. Each list entry is a map consisting of
* the type of the credential (e.g. usernamePassword, token)
* the identifier which is used for resolving the credential.
* a list of environment variables which holds the resolved credentials.
Inside `piperExecuteBin` the id was resolved against the config and the result was used for resolving the credentials against the jenkins-credentials-plugin.
With this change here we introduce another key for the map mentioned above:
* resolveCredentialsId
When this key is provided with value `false` we do not resolve the credentials-id from the config. In that case the id is directly used for resolving the credential again the jenkins-credentials-plugin.
* 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
* 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>
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
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>
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>
