* Implemented validation for the option possibleValues
* Has been added the option mandatoryIf to config with validation
* Fixed issues found during code review
* improved golang template
* Fixed tests. Added validation for mandatoryIf option
* Fix typo
* Fixed tests
* Validation was refactored. Added options
* Added default value for parameters with possibleValues option
* Validation was moved after the configuration resolution
* Canceled some default values
Co-authored-by: Sven Merk <33895725+nevskrem@users.noreply.github.com>
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
* feat(config):read config/defaults with authentication
This change allows to use defaults and config files from a protected GitHub repository.
The options `--customConfig` and `--defaultConfig` already allowed to provide a link to an uprotected file.
Now, by passing a value in the form `<hostname>:<token>` to parameter `gitHubTokens` (this parameter can be passed multiple times) a token can be provided for dedicated hosts.
This makes it possible to use a link like
`https://api.github.com/repos/SAP/jenkins-library/contents/resources/my-defaults.yml?ref=master`
as reference to a default file or similarly as reference to a configuration file.
* update generation to allow protected config/defaults
* fix CodeClimate issues
* update missing generations
* Adds headCommitId, which stores the head commit has of the current build, includes tests and generated files
* Adds headCommitId, which stores the head commit has of the current build, includes tests and generated files
* Go fmt fix
* Fixes artifactoryPrepareVersion test
* Removes xMake CommitId
Up to now the code generator is not able to handle the type
map[string]interface{} which is important for nested
configurations.
With that change we support such nested configuration.
Fo now parameters with a map type are not supported via
command line parameters. Those parameters are simply
ommitted. But with this change is it possible to read
such nested structures from the pipeline configuration
(.pipeline/config.yml).
As a next step we can discuss if we would like to support
such values also via command line parameters. One possible
approach could be
```
./piper <command> -myParam key1=val1 --myParam key2=val2
```
which gets finally collected inside our map:
```
map["key1"] = "val1"
map["key2"] = "val2"
```
This is of course hard to do for deeper nestings. In that case
providing a pointer to a file might be more suitable.
In that context we need to consider how to
- declare the default values for map like parameters in our
metadata files.
- deal with the different types we have for the parameter
itself wrt the yaml like config on the one hand and on the
level of the command line parameters on the other hand. Maybe for
that we have to extend the metadata format (e.g. describe an
alternate type receiving the values from the command line, like
[]string. With that approach values for simple nested (... not deep
nested) params can be provided like described above, it would be
possible to represent these parameters for the command line parser
as string slice entries like "[]string{key1=val1, key2=val2". These
parameters needs in this case transformed "by us" into the map we
use further down the road.
In case we agree in principle on an approach as outlined here we should
adjust the golden files reflecting this use case.
* add vaultSecretFileReferences
* fix test
* fix test
* go generate
* remove code duplication
Co-authored-by: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* add type to sonar field
* respect type of influx fields
* update generated code
* switch type
* copy changes from #1885
* log JSON data
* read simple values from json
* Update InfluxData.groovy
* Revert "Update InfluxData.groovy"
This reverts commit c8cfdf381f.
* Revert "read simple values from json"
This reverts commit 94b69866d2.
* Revert "copy changes from #1885"
This reverts commit 2471b4475e.
* update TODO
* handle non-string values as JSON
* change value type to interface in resources
* regenerate code
* add test cases
* handle reading of json files
* write json data to json files
* fix assignment
* use GetResourceParameter
* add test case
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
* remove docs generator code from step-generator
* add docs generator to dedicated package
* add test cases
* add entry point for docs generation
* make output more readable
* remove dead code
* 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>
* 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.
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
* 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
