With the current approach we get a failure when the generated
content triggers a change. But we cannot see what was changed.
With this commit we can see the diff. In case there is not diff
we will not see anything, so there is in that case no real change
in the behaviour. But in case there is a change we will see that
change.
Without that we have to reproduce locally, which means additional
efforts.
From the current location inside "cmd" the npmExecutorMock cannot
be used from any coding inside "pkg".
When we would like to re-use the npm functionality we have also to
provide tests and this requires having a mock.
In order to be able to use the mock from pkg we move the mock from
"cmd" to "pkg" into package "npm".
With the shift from package "cmd" to "npm" a lot of fields in the mock
has been made public.
Up to now we get a message 'Requested resource could not be found' which is not very
helpul during troubleshooting based on the log. With this change we tell the reader
which resource could not be resolved.
First a bug fix is addressed in which the pull policy could not be configured to false by configuring the general configuration. It could neither be configured via dockerExecute or dockerExecuteOnKubernetes, even though this parameter is docker specific. Only by configuring the specific step where one wants to set the pull policy to false can it be configured.
As the bug stems from zero values being in the context config map, which is also addressed with this PR. That is the second part: Context config parameters are only set if they have a value.
* Don't set pull image if not configured
Otherwise, if the pull policy is not set explicitly for a step, dockerPullImage is set to true. Thus, before this change, it cannot be set in the general, or in dockerExecute or in dockerExecuteOnKubernetes configuration.
* Fix unit tests
* Add pullImage parameter test
* Do not place empty default values in context config
* Use putIfNotEmpty for sidecar container options
* Export common configuration
Keys that are set by both main and sidecar container can be exported
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
`piperExecuteBin` is called with a credentials list. Each list entry is a map consisting of
* the type of the credential (e.g. usernamePassword, token)
* the identifier which is used for resolving the credential.
* a list of environment variables which holds the resolved credentials.
Inside `piperExecuteBin` the id was resolved against the config and the result was used for resolving the credentials against the jenkins-credentials-plugin.
With this change here we introduce another key for the map mentioned above:
* resolveCredentialsId
When this key is provided with value `false` we do not resolve the credentials-id from the config. In that case the id is directly used for resolving the credential again the jenkins-credentials-plugin.
* Upload in Chunks
* fix unit tests for file upload in chunks
* upload in chunks review round 1
* Upload in Chunks - review round 2 - comments
Co-authored-by: Daniel Mieg <56156797+DanielMieg@users.noreply.github.com>
