-
Improvement
-
Resolution: Fixed
-
Minor
-
-
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
[JENKINS-51170] Workflowstep-specific environment variables
Thomas Weißschuh
created issue -
| Description |
Original:
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. Cc [~svanoort], [~abayer] Previous discussion: https://groups.google.com/forum/#!topic/jenkinsci-dev/VBYvIv3S_r4 |
New:
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. Cc [~svanoort], [~abayer] Previous discussion: https://groups.google.com/forum/#!topic/jenkinsci-dev/VBYvIv3S_r4 |
Thomas Weißschuh
added a comment - 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).
Thomas Weißschuh
added a comment - 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.
Thomas Weißschuh
added a comment - There are now the following PRs:
https://github.com/jenkinsci/workflow-step-api-plugin/pull/36
https://github.com/jenkinsci/workflow-support-plugin/pull/62/
https://github.com/jenkinsci/workflow-cps-plugin/pull/229
Thomas Weißschuh
added a comment - 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.
Thomas Weißschuh
added a comment - 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. Thomas Weißschuh
added a comment - The git-changelist-maven issue is tracked at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=528973
Thomas Weißschuh
added a comment - The git-changelist-maven issue is tracked at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=528973 Thomas Weißschuh
added a comment - 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.
Thomas Weißschuh
added a comment - 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.
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.