* Add Changes for value of docker image
* Get docker image value
* Fix
* Fix unit
* Add chnages for kaniko and mta builds
* Fix
* Test changes
* Test
* Move func ResolveMetadata to stepmeta.go
* Fix
* Change getConfig.go
* Fix getting docker value for mta, npm and kaniko
* Fix according to suggestions
* Add func to get only value of docker image
* Test empty value of docker image
* Fix for getDockerImageValue
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
* kanikoExecute: improve user experience
* ensure proper tags
* update permissions
in case a container runs with a different user
we need to make sure that the orchestrator user
can work on the file
* update permissions
* ensure availablility of directories on Jenkins
* (fix) clean up tmp dir in test
* add resilience for incorrect step yaml
* incorporate PR feedback
stageName from parametersJSON was ignored up until now and there was a TODO in the code. The precedence from the TODO is not clear to me. It said "first env.STAGE_NAME, second: parametersJSON, third: flag". So maybe I implemented it wrongly, but it would be easy to change. Right now, STAGE_NAME is always in the ENV when piper is called from Jenkins, but to mimic the behavior of being able to pass `stageName` in the parameters and override the ENV value, this is what happens in go as well now.
The reason why `stageName` needs to be evaluated before other step parameters is that it affects config evaluation. So I've added a function which is called first in `PrepareConfig()`.
* 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>
* 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
* 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
* 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>
* Remove redundancy: no duplicate stepName
Up to now: provided explicity via command line argument and also contained in the
step metadata (which are as a file also provided as command line argument).
Now it is retrieved from the metadata file.
* Step name is not a required parameter anymore
Since the step name is derived from the config file
* Adjust method signature in test
* 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
