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
This step allows to restart a set of steps in order to retry in case of e.g. infrastructure failures which first need to be fixed.
* update documentation
it is the duty of the configuration helper to build a map
providing the configuration. Having facilites to use the
ConfigurationHelper as some kind of configuration registry
makes life more complicated.
there is only one test class making use of it left. This test class is the
GitUtilsTest itself.
Hence moving this member downwards in the test class hierarchy into GitUtilsTest.
I doubt it makes sense to make use of a generic git utils mock somewhere else since this basically
means to test the GitUtils class in the conxtext of other examinees. For that there is no need.
The GitUtils class should be tested by the corresponding test class, but not in a transive manner
by other tests. For all other tests a specific git utils mock should be provided mocking the corresponding
method class. This is already the case today, otherwise we would have more test classes making use
of the generic git utils mock.
- In ArtifactSetVersionTest the method was declared,
but not used at all.
- In MtaUtilsTest there was a particular Object created
for the sole purpose of serving as script.
For that we have the nullScript.
- In DockerArtifactVersioningTest 'this' was configured to
serve as script. There is basically no reason why the
instance of the JUnitTest should serve as script.
Instead we have the nullScript for that purpose.
GStrings might be handed over e.g. via signature to steps.
GStrings in configuration makes it harder to deal with configurations.
E.g.
```if(param == 'a' || param == 'b')``` returns true if a is a GString representing 'a'
but
```if(param in ['a', 'b'])``` returns false.
It would be possible not to use the ```in``` notation in our code. But this
increases readability.
GString are not significant and can be replaced by the corresponding java.lang.String
representation without loss of information. Hence it is justified IMO to ensure
there are no GStrings contained in the configuration map.
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
