* Add capabilities for checks if a file has been written
With the current file system mock we cannot assert if
a file has been written. E.g. we cannot distiguish between
files added to the virtual file system before the test and files
explicitly written. In contrast to that we can check for deleted
files.
With the change here we get a func HasWritteFile(name).
[Q] Wouln't it be possible to check based on the file content
if a file has been written (the new file should have another
content as the file registered before).
[A] We should not assert some file content here since the
produced file content can be created by another "class" which
is unit tested somewhere else. With that approach we would test
the producer here again.
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
* Add error category parsing to cmd execution
It is now possible to define `ErrorCategoryMapping` as a `map[string][]string` on a `Command`.
The format contains the category as key which has a list of error patterns assigned.
Example:
```
cmd := Command{
ErrorCategoryMapping: map[string][]string
"build": {"build failed"},
"compliance": {"vulnerabilities found", "outdated components found"},
"test": {"some tests failed"},
},
}
```
Setting this map triggers console log parsing when executing a command.
If a match is found the error category is stored and
it will automatically be added to the `errorDetails.json`.
* clean up go.mod
* fix test
* fix test
* Update DEVELOPMENT.md
* fix tests
* address long console content without line breaks
* scan condition update
* fix test
* add missing comment for exported function
* Update pkg/command/command.go
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
Co-authored-by: Christopher Fenner <26137398+CCFenner@users.noreply.github.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>
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).
* also reduce code duplication in token fetching
* concatenate classpaths from multi-maven projects
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
* 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>
* artifactPrepareVersion: additional options
it is now possible to use
* a Unix timestamp number
* a short commit hash
* Add dedicated Docker versioning scheme
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"],
```
* extract StepConfiguration generation to separate file
* add general options to parameter and config table
* fix test case
* remove telemetry flag from docs
* Revert "extract StepConfiguration generation to separate file"
This reverts commit df80dab8cd.
The TransportTimeout value is now applied to the "response header
timeout" and "expect continue timeout" as is. Previously there
was a hard limit of 10 seconds and 1 second respectively (originating
from the article I based the previous PR on). While this doesn't
allow for fine-grained control, it is reasonable to apply the meaning
of "transport timeout" to any state or phase of a HTTP connection.
This change should solve the needs of some Piper clients to configure
very long response header timeouts of 5 minutes and above.
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
* add code blocks
* set parameters name in code block
* change test cases
* set parameters name in code block
* add step configuratio caption
* remove details caption
* add code block for docker settings
* add code block for stash content
* add code block for defaults
* add code block for sidecar image & name
* correct test cases
* add code block for docker
* correct test cases
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>
* use sonar go in groovy
* use SONAR_TOKEN
* only use owner/repo if both are set
* trim version to major version digit
* fix code climate issues
* remove Sonar defaults
* use sonar go step
* use SONAR_TOKEN
* use certs from parameters
* use docker workspace & options
* add instance parameter
* implement branchName
* implement branchName
* remove duplicate default
* update docs
* fix TODOs
* remove merge mess
* fix code climate issue
* address comments
* respect custom defaults and custom config file name
* fix typo
* remove obsolete test cases
* disable CommonStepChecks
* check step config instead of context config
* remove TODOs
* respect jenkins PR envvars
* use value from stepConfig
* Update vars/sonarExecuteScan.groovy
* rename options to config
* correct type for options
* add test cases
* log sonar.options in debug message
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
* iterate over found pom.xml files for maven projects, deploy found artifacts
* classifiers are found by testing prefix/suffix of artifact
* Remove additionalClassifiers option
* Improve documentation
* Fix fallback for finalBuildName
* Ignore mvn modules with packaging != pom but no target dir
* Fail when main artifact is missing, add more tests
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
* Fix typos
* Support aliases also for secrets
* Adapt & extend Unit Tests
* Output deprecation warning for param/secret aliases
... if the alias is marked as 'deprecated'.
* Config and Defaults via http(s)
Add the possibility to use http(s) urls as path to
* config.yml
* defaults
* Remove comment
* Addressing PR feedback
* Fix error handling
* Replace the default maximum request deadline with a default timeout on the transport level.
* Keep the possibility to set a maximum request deadline.
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>
* 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
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
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.
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.
download settings file via http or copy from the local file system into either $M2_HOME/conf/settings.xml or into ~/.m2/settings.xml
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
* add download file function
* add test case
* Update pkg/piperutils/FileUtils.go
* correct test case
* remove FileUtils.Download
* add Downloader
* add Downloader
* fix error
* respect header and cookies
* add test case
* rename files
* correct test case
* remove SendRequest
* correct test case
* 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>
* Enhance telemetry reporting
* Use central telemetry data object
* Add duration
Co-Authored-By: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* Use commonPipelineEnvironment in go binary
* Update groovy part incl. tests
* Rework structure and naming
* Support influx resources in steps
* Update tests and some cleanups
* Add correct defer handling
* Address PR feedback
* Fix test
* Update resources.go
Co-authored-by: Sven Merk <33895725+nevskrem@users.noreply.github.com>
* Export general configuration - part 2
First part in #956 missed to export the elements of the struct ...
* Add comment for exported struct
* Add function for opening config files
