* [refactoring] condence common coding for cf deploy
Small change beyond refactoring: for mtaDeploy the user is now quoted.
* more general name: logoutAction -> postDeployAction
* Provide additional opts for cf deploy
Inside cloudFoundyDeploy we use these cf commands
o login
o plugins
o blue-green-deploy
o push
o deploy
o bg-deploy
o stop
o logout
o logout and stop does not provide any options
o plugins provides options (--checksum --outdated) but it is unlikely that
these options can be used in a reasonable way during the deploy process.
o login now uses `loginOpts`
o The other commands uses now `deployOpts`
* provide additional opts also for cf api calls
* Provide more log when verbose
* re-use mtaDeployParameters and adjust names of other params (api, login) accordingly
* Streamline naming
* distinuish between cfNative and mta deploy params
* Add cfNativeDeployParam default
* login and api paramters are not under cloudFoundry
If there was no instance deployed in CF and blue-green deployment was activated stopping the old instance caused a failure of the pipeline, even if the application was deployed successfully.
With that change the failure of the pipeline will be avoided in case of no old application is available.
mta deploy plugin has flag:
` --no-confirm` which is described as _"Do not require confirmation for deleting the previously deployed MTA apps"_
This flag is essentials for performing fully automated blue-green deployments.
Add reporting of operations-related data to Influx (if configured), like:
* Version of deployed artifact
* Deployment time
* Target infrastructure for deployment
This change fixes an error which only occurs in a Kubernetes landscape.
When initial stashes are filled, the deployment will fail since it misses the artifact to be deployed.
When providing an empty stash as default, Docker execution on Kubernetes will respect all content in the current workspace.
* cloudFoundryDeploy - blue-green plugin extensions
* support blue-green application cleanup with new plugin flag
* enhance error reporting in case no app name is available
* include PR feedback
Up to now we had two constructors, one with a Script and the other one with a map holding some defaults.
In case the constructor with the map was called the step name was uninitialized
