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.
The following features were added:
Lock resources for deployment
New parameters: environment, vmArguments
Assert password does not start with @
Link to cloud cockpit
Only execute rolling update if app is running
Show logs if deployment failed
Restart app after normal deployment
Use neo namespace for parameters
Align parameter names with neo sdk: size, application, source
Remove vmSize check as done by the tool itself
command `which` requires a dedicated OS package to be installed.
In case a Jenkins Master or Jenkins Slave Image does not contain `which`, although `docker` command is available the step took a wrong turn.
This removes the check using `which` since checking `docker ps` is sufficient.
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
* influxWriteData - support Influx tags
In order to better query data in Influx, tags needs to be written.
This change allows filling tag data via the Influx plugin.
influxWriteData requires a node to be executed.
In a declarative pipeline the POST section by default does not provide a node/agent.
This adds a parameter to force creation of a node/agent.
a lot of code can be replaced by configuring the JenkinsShellCallRule accordingly. At the time when
this test was provided there was not JenkinsShellCallRule ...
* add wrapper for stages contained in library
`piperStageWrapper` provides a wrapper for stages which we may include into the library.
It will take care about extension capabilities, locking, node handling, ... which should be a capability of every stage contained in the library.
* toString is helpful for troubleshooting during developing tests
* equals/hashCode are required in case somebody would like to register
some responses again (e.g. register something valid almost all the time, and
register something more specific for a certain test).
- don't log a message and continue when it is clear that we cannot succeed
together with error raised later during attempt not parse a non-existing
file
- More log output in order to clarify what happens with mta.yaml
