In configurationLoader.md the reference to commonPipelineEnvironment.md
is wrong and will give you a 404, because commonPipelineEnvironment.md
lies in a separate folder called steps.
The change was already deployed to the gh-pages!
Caused by the missing nonCps annotation the unflatted configuration
tree of all the default values was returned.
After adding the nonCps annotation we get only the default for
either stages or steps and only for the required step/stage.
node() is not necessary in the LesFurets unit tests. This is especially
misleading for the pipelineExecute step, as the step itself opens a node
closure when loading a pipeline. If used like this in Jenkins
unnecessary executors will be used.
The methods a related to an outdated use case
It was intended for getting the coordinates of a payload repo when the
pipeline repo is specified in the pipeline job.
That has been changed so that the pipeline (or at least a stub pipeline)
is now always contained in the payload repo and the payload repo is
always specified in the pipeline job itself.
In case there is an error in another pipeline step inside a foreign pipeline we got
nevertheless an error explaining there is an issue inside the pipeline load step.
Mocking with LesFurets. Check that everything is at the right place.
1. Test with only the mandatory parameter 'repoUrl'.
1. Test setting all available parameters.
1. Test with no parameters throws Exception for missing mandatory
parameter 'repoUrl'.
A more convenient way to checkout the project sources. The idea is to
have a Jenkinsfile in the payload repository that only loads the shared
library and then runs this step. This step in turn loads a Jenkinsfile
from another repository.
The repo url, branch, Jenkinsfile path and credentials ID can be
provided to the step. The Jenkinsfile is first checked out to a
temporary folder, before it is loaded.
The payload repo must include a Jenkinsfile to be loaded with this
approach.
Without proper quotation characters with a special semantics
on shell level (e.g. "${}", "!", """ gets escaped on shell level
before handed over to the neo tool.
neoExecutable is surrounded by double quotes since we may have
shell ${variables} inside the groovy variable.
All other variables (user, host, account, password) are surrounded
by single quotes since we do not expect to be variables used here.
The neoExecutable is
- send "build failed" mail only when an exception has been received.
- provide a non empty mail message, since an empty mail body causes the build to fail.
Alejandra Ferreiro VidalandGitHub
Oliver FeldmannandGitHub
Marcus HollandGitHub
Daniel KurzynskiandOliver Nocon
Christoph SzymanskiandGitHub
