Status: Resolved (View Workflow)
workflow-step-api 2.19, workflow-support 3.2, workflow-cps 2.63
For monitoring purposes it can be useful to be able to have access to the current FlowNode/Step via environment variables.
This could be done by only injecting the current FlowNode id as environment variable.
A more flexible approach would be a new extension point, similar to an EnvironmentContributor, but called with the current StepContext.
If this idea gets a general go-ahead I will present a prototype.
Previous discussion: https://groups.google.com/forum/#!topic/jenkinsci-dev/VBYvIv3S_r4
There is now a prototype. Should I just open PRs against workflow-step-api, workflow-support (and workflow-cps) or only against the API for now?
(I did not find explicit docs about contributing to (multiple) plugins (at once).
A complete step of PRs—API and usage(s). JEP-305 makes it easier to synchronize PRs across multiple repositories.
There are now the following PRs:
jglick also it seems that git-changelist-maven-extension ignores the contents of $HOME/.config/git/ignore when determining if the workdir is clean.
This leads to errors when IDE configuration files are in the workdir. These are ignored by "normal" git.
If you want I can take a look.
The git-changelist-maven issue is tracked at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=528973
Add your IDE files to .gitignore.
I normally try top keep stuff specific to my setup in the system wide gitignore.
(For the time being I put it in .git/info/exclude).
The problem was mostly my confusion about the plugin asking me to run "git status -s" which did not show any changes.
This extension point is now available as of Pipeline Step API 2.19, Pipeline Supporting APIs 3.2, and Pipeline Groovy 2.63.
My Jenkins server is showing a warning for the plugins listed above: "Warning: the new version of this plugin claims to use a different settings format than the installed version. Jobs using this plugin may need to be reconfigured, and/or you may not be able to cleanly revert to the prior version without manually restoring old settings. Consult the plugin release notes for details."
I don't see any information in the bug that indicates what changes need to be made in the pipeline to be compatible with this update.
shubbard Probably you are seeing that error because of Pipeline Supporting APIs 3.2 (my guess is that you are running 2.x). See the wiki page for that plugin for details about that compatibility issue. If you are running Pipeline Supporting APIs 3.x already, then please list the versions of those plugins you have installed.
I suggested the general approach FTR. EnvironmentExpander.getEffectiveEnvironment could get a new overload (deprecating the original), to be called from DefaultStepContext, which would take a StepContext argument and call the extension point.