* Fix docker.includes in WhitesourceConfigurationHelper
Not sure, but it seems the [`docker.includes` parameter](https://whitesource.atlassian.net/wiki/spaces/WD/pages/804814917/Unified+Agent+Configuration+File+and+Parameters#UnifiedAgentConfigurationFileandParameters-DockerImages) needs to be a regex.
Our pipeline is failing with:
```
10:22:33 [ERROR] [2020-06-15 08:22:33,740 +0000] - Resolve DockerEntity Exception Dangling meta character '*' near index 0
10:22:33 *.tar
10:22:33 ^
10:22:33 [DEBUG] [2020-06-15 08:22:33,743 +0000] - Resolve DockerEntity Exception {}
10:22:33 java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
10:22:33 *.tar
10:22:33 ^
10:22:33 at java.base/java.util.regex.Pattern.error(Unknown Source)
10:22:33 at java.base/java.util.regex.Pattern.sequence(Unknown Source)
10:22:33 at java.base/java.util.regex.Pattern.expr(Unknown Source)
10:22:33 at java.base/java.util.regex.Pattern.compile(Unknown Source)
10:22:33 at java.base/java.util.regex.Pattern.<init>(Unknown Source)
10:22:33 at java.base/java.util.regex.Pattern.compile(Unknown Source)
10:22:33 at org.whitesource.utils.WssStringUtils.isMatchingPattern(WssStringUtils.java:49)
10:22:33 at org.whitesource.agent.dependency.resolver.docker.DockerResolver.filterTarImagesToScan(DockerResolver.java:296)
10:22:33 at org.whitesource.agent.dependency.resolver.docker.DockerResolver.resolveDockerEntities(DockerResolver.java:186)
10:22:33 at org.whitesource.fs.scanOrigins.DockerEntityScanOrigin.scan(DockerEntityScanOrigin.java:66)
10:22:33 at org.whitesource.fs.scanOrigins.ScanOrigin.runOriginScan(ScanOrigin.java:36)
10:22:33 at org.whitesource.fs.FileSystemAgent.createProjects(FileSystemAgent.java:132)
10:22:33 at org.whitesource.fs.Main.scanAndSend(Main.java:157)
10:22:33 at org.whitesource.fs.Main.main(Main.java:102)
10:22:33 [WARN] [2020-06-15 08:22:33,744 +0000] - Resolve DockerEntity Exception Dangling meta character '*' near index 0
10:22:33 *.tar
10:22:33 ^
```
* Switch docker.includes to slashy string
* Fix docker includes pattern in tests
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
Co-authored-by: D070410 <srinikitha.kondreddy@sap.com>
There are use cases where we need to run `GetStepConfig()` multiple times.
In such cases it is more efficient to load the files once and then resolve the
respective step configuration.
Extend mta build step to install maven artefacts after build to allow re-using them in later stages (additional unit or integration tests which might not be running as part of the "build" life-cycle).
* 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.
* Provide test for yamlUtils substitution with boolean value false
* Fix: handle booleans with value 'false' in yaml substitution
* Improve variable naming
Provide a timeout parameters to malwarescan step. This is forwarded to the piper http layer. The default used there is 10 seconds with is not useable for that use case for larger files.
* Update fortify.yaml
* src, exclude and pythonAdditionalPaths are now lists of strings
* Re-implement pythonIncludes and pythonExcludes as aliases of src and exclude
* Fix using the correct separator (; on windows, : on everything else)
* Tokenize also python "includes"
* mvnCustomArgs was removed
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
* also reduce code duplication in token fetching
* concatenate classpaths from multi-maven projects
Co-authored-by: Daniel Kurzynski <daniel.kurzynski@sap.com>
* increase retry time
* Update src/com/sap/piper/PiperGoUtils.groovy
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
Co-authored-by: Kevin Hudemann <kevin.hudemann@sap.com>
Co-authored-by: Daniel Kurzynski <daniel.kurzynski@sap.com>
* Include error in the log.
In case the default text formatter is used, the error
will be contained in the log, too.
* Avoid stupid nil token printed in error message
* 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
* streamlined error category with standard term
* remove unused import from test
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
