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()`.
* If a step declares a parameter of type string, depending on how the config is written, it is no longer ignored, if it is interpreted by the yaml parser as integer or float value.
* If an expected parameter is present in the configuration, step execution will consistently fail if the parameter has the wrong type, no sensible conversion can take place, and it is known that the parameter will be ignored.
* For all type-mismatches that have no implemented conversion, a warning is logged. (It isn't known whether the conversion actually works, since it depends on both the yaml and json packages and future changes there.)
* Entries in the evaluated config with a value of nil are ignored.
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"],
```
* same behaviour for shellRunner and execRunner wrt errors and stdout
* replace shouldFail with shouldFailOnCommand
* [formatting only] format struct
* Move to regex for execptions and stdout
* shrink code
* Support yml and yaml extension of config files
* Update cmd/piper.go
Co-Authored-By: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
Co-authored-by: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* Read the project config only if it exists
This avoid trying reading the file and have the control flow based
on errors. Beside that it helps troubleshooting when we have some
logging (debug level only).
* formatting only
* Adjust log level
There was some command parsing with failure in case it started with fail. That is
IMO less transparent. Now we prepare more explicit with a failure from outside. This
enables us to prepare an error like we expect it in the free wild.
* 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
