* [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
* 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
When we register a closure as file, the closure will be exectutd.
Otherwise we return what is registered.
This gives us a maximum level of flexibility. We can throw exceptions (e.g. FileNotFound) as
as test setup requires this, in simple cases we provide the yaml as a string.
read yaml rule is a very frequently used rule. But having the rule in the common rules
means we cannot register text or files to that rule, which makes it less handy to work
with yaml files in the tests.
