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
* 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
This step allows to easily create a new release for your GitHub repository
* include PR review feedback - add additional labels
* consider return status of api call
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
This step allows to perform a basic health check on an installed application.
It verifies that your app has a simple health endpoint available and that there is no error when calling it.
since now handlePipelineStepError does not return anything anymore we need to put the
corresponding return statement inside createTransportRequest outside the handlinePipelineStepError
closure.
* simplify parameter handover
* extract default contaner name and map
* condense pod execution methods
* simplify closure handling
* fix map issue
* simplify
* stash only if needed
* fix test case
It comes with an extension to executeDocker and executeDockerOnKubernetes to run sidecar containers.
This helps to execute Selenium tests using two Docker images:
1. Execution runtime for tests (e.g. node image)
2. Selenium instance which holds Selenium server + browser
* add documentation & some name cleanup
* include PR feedback
* add step documentation to structure
Up to now we checked for git commands, but the order was not taken into account.
Test would pass even if the commit happens before git add.
Now the order of the git commits is asserted.
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.
if we don't mock the GitUtils here changes inside GitUtils affecting the git commands
issued at the command line requires changes here. In fact we have to react on
implementation details of the GitUtils here. It is better to be independent from that
implementation details here since this leads to more focused and smaller commits.
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
- there is no need to do the git commit inside the body of sshAgent
- there is no need to do the git tag inside the body of sshAgent
- side catch: availablility of git user name and git user email is
checked at its own. If one is missing the other may be present
~somehow~ in the configuration.
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.
We can now registering files to JenkinsReadYamlRule by
providing the file name alongside with the expected content
(or e.g. an expception)
With that change it is possible to remove pwd statements
from mtaBuild. These statements was used in order to pass
a temporary directory inside the mtaBuild (code under test).
This is not needed anymore since we can register the files
directly.
Having pwd implies working with absolute pathes which is
also a no-go when working with docker, since the absolute
pathes inside and outside docker are normally not the same.
For pathes relative to a build root directory it is rather
easy to keep the pathes consistent the same.
Adjust sources according to registering yaml file to jenkins rule.
For mtaBuild this means also: get ride of absolute pathes for denoting the yaml file.
Having absolute pathes makes it difficult/impossible to work also with dockerized versions
of mtaBuild since the absolute pathes are most probably not the same inside and outside
the docker container, but the relatives pathes can be kept the same easily.
up to now we check some values provided by the DefaultConfigurationCache. This is some kind
of plausibility check, but this is not really a check that the instance did not change.
With the tests as they are now we check in fact for a new instance.
In the free wild it is the duty of libraryResource to provide some resource as text
and it is the duty of readYaml to parse a text (... would also be possible to read
a file instead just parsing text, but that is a different story).
In our setup we just forwarded the resource name in libraryResource and reacted on
that resource name inside read yaml. There was no yaml parsing at all, the yaml 'as
it' was returned.
The approach now is much closer to reality. Library resource now provides the
text 'behind' the resource and yaml parses it. There is now a real yaml parsing.
Read yaml is now not registered explicitly anymore. It is just the readYaml closure
which is registerd by default for our tests.
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.
* Create executeDockerOnKubernetes.groovy
* Update dockerExecute.groovy
* Create SysEnvTest.groovy
* Update default_pipeline_environment.yml
* Update executeDockerOnKubernetes.groovy
* Create utils object
* update docker image
* Update mavenExecute.groovy
* Use pipeline-lib than piper
* Check container name
* Always change ownership to 1000
* Check for map
* Fix command
* Move chmod to docker execute
* Use generic name for the pod
* runAsPod has been added
* Return false if script has no k8smapping
* fix syntax error
* Null checks
* Returnn dockerImage name
* Check method body
* Return container name
* Cleanup echos
* Use runAsPod
* Rename step
* Use official jenkins JNLP agent image
* Construct containersMap
* Check if kubernetes plugin is active
* Support JaaS
* pass script object
* Move configuration to default section
* Use generic flag to check if running in k8s
* fix jnlp agent name
* Solve travis errors
* Improvements to config and changes to name of the method
* Improvements to config
* Fix type
* Rename stash config
* add import
* Fix map order
* Fix jnlp agent name
* cleanup config usage
* Check if config is enabled
* Use nested k8s mapping
* Support custom docker workspace and move flag to env
* Feature/k8s stage (#1)
* Use nested k8s mapping
* Support custom docker workspace and move flag to env
* Check dockerOptions value
* Support local execution
* Add tests for dockerExecute
* Move config to step and Fix tests
* Use step configuration while running as a pod
* Streamline parameter and config initialization
* Streamline parameter and tests
* Cleanup and align variable name
* Use default JNLP agent if one not defined in config
* Add tests for runInsidePod. Ensure lowercase container names.
* Improve tests and remove unused code block
* Fix permission issues
* Perform stashing and unstashing inside container
* Use custom jnlp agent due to user id restriction
* Fix tests after jnlp agent change
* Address review comments
* Initialize script to default value if null
* Address review comments
* Update exeception handling and documentation
* Improve documentation
* correct indent
* Link documents to the index page
* Merge containerExecute and dockerExecuteOnKuberenetes step and address comments.
* Update dockerExecute.md
* Update dockerExecuteOnKubernetes.md
* Update default_pipeline_environment.yml
* update documentation
* Update documentation. Use annotation for singleton
* Update DockerExecuteOnKubernetesTest.groovy
* Update dockerExecute.groovy
* Update dockerExecuteOnKubernetes.groovy
* Improve documentation and test case names
* neoDeploy: switch to chained ConfigurationHelper (#244)
* switch neoDeploy to chained ConfigurationHelper
* update imports
* Improve tests
* Address review comments
* Improve documentation
* made dockerImage non-mandatory parm, improved test
* add comment regarding userid assumption
This allows the steps to interact without using return values (which is not possible in
declarative pipelines). On the other hand we have depencencies between the steps based
on the status of the commonPipelineEnvironment.
The old naive check fails if an argument starts with '-B'. Now we use a
regular expression, which should correctly match if batch mode was
already supplied, and add it if not.
Instead of configuring the credentials setup
o withCredentials
o usename
in each of our tests (for the moment change-management related)
we collect the common coding in a JUnitRule.
registerAllowedMethod for sh call not used anymore since we mock the ChangeManagement utils class.
The sh calls was triggered from the utils class. Since we mock that class, there is no sh call
anymore.
- In case a parameter is missing we do not thrown and AbortException
anmore, but an IllegalArgumentExcpetion, since that exception is
thrown by the configuration helper. The difference is: AbortExceptions
are contained in the log without stacktrace, other exceptions are
printed with stack trace.
- Exception messages are changed to the standard error message triggered
inside the configuration helper. In case the changeDocumentId is
retrieved also from the commit history we keep an exception message
pointing to that.
- Having references to the parameters is droped. Instead the parameters
are directly used from the configuration map.
- in case of long signatures line breaks are inserted in order to
simplify reading the code.
With the current approach of checking log entries we are not able to
check log entries in case of a failure. But is is important to assert
log messages in case of a failure. Having reasonable log messages
simplified troubleshooting.
Hence we add JenkinsLoggingRule.expect(substring) and check after the
base of that rule has been called.
This interfears with other rules also working with an expect approach,
like e.g. ExpectedException. Which violation is presented depends on
the order or the rules around the test case.
