* add APIs for getNodes, getExtDescriptor, putExtDescriptor and uploadExtDescriptor
* add new params and extend the logic to enable upload or update extension descriptor to node
* extends unit tests
Co-authored-by: Zihe Cheng <zihe.cheng@sap.com>
Co-authored-by: Marcus Holl <marcus.holl@sap.com>
Ensure npm dev dependencies are available after mtaBuild as they are required by certain tests.
Co-authored-by: Kevin Hudemann <kevin.hudemann@sap.com>
Co-authored-by: Daniel Kurzynski <daniel.kurzynski@sap.com>
This change adds linting support for Java-/TypeScript projects based on the checkDefaultLint and checkUserLint steps from Cloud SDK Pipeline.
Following options are supported:
1. Define a linting script named ci-lint in the package.json file(s) of the project
2. Provide a configuration for ESLint as part of the project
3. If none of the above: ESLint is executed with a general purpose configuration.
Co-authored-by: Daniel Kurzynski <daniel.kurzynski@sap.com>
* Add possibility to add category to failures
It is now possible to set the error category within the flow.
When exiting the program the error category can be used.
There is a convenience function available for exiting with a previously set category,
for example
```
log.SetErrorCategory(log.ErrorCompliance)
...
log.FatalError(err, "configuration error")
```
* extend test
* go mod tidy
* add missing comment
* update information about error categories
* Update DEVELOPMENT.md
This change refactors the npm pkg and npmExecuteScripts implementations
to be reusable for future steps, e.g., npmExecuteLint.
In addition, it fixes few small bugs related to unit test execution on
Windows and the fileUtils mocking implementation.
Co-authored-by: Daniel Kurzynski <daniel.kurzynski@sap.com>
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
* 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.
