Details
-
Improvement
-
Status: Resolved (View Workflow)
-
Minor
-
Resolution: Fixed
-
-
workflow-step-api 2.19, workflow-support 3.2, workflow-cps 2.63
Description
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
Attachments
Issue Links
Activity
Thomas Weißschuh
created issue -
| Field | Original Value | New Value |
|---|---|---|
| Description |
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 |
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. Thomas Weißschuh
made changes -
| Status | Open [ 1 ] | In Progress [ 3 ] |
Thomas Weißschuh
made changes -
| Assignee | Sam Van Oort [ svanoort ] |
| Status | In Progress [ 3 ] | In Review [ 10005 ] |
| Remote Link | This issue links to "jenkinsci/workflow-step-api-plugin#36 (Web Link)" [ 22337 ] |
| Remote Link | This issue links to "jenkinsci/workflow-support-plugin#62 (Web Link)" [ 22338 ] |
| Remote Link | This issue links to "jenkinsci/workflow-step-api-plugin#36 (Web Link)" [ 22339 ] |
| Remote Link | This issue links to "jenkinsci/workflow-cps-plugin#229 (Web Link)" [ 22340 ] |
| Remote Link | This issue links to "jenkinsci/workflow-step-api-plugin#36 (Web Link)" [ 22337 ] |
This extension point is now available as of Pipeline Step API 2.19, Pipeline Supporting APIs 3.2, and Pipeline Groovy 2.63.
| Released As | workflow-step-api 2.19, workflow-support 3.2, workflow-cps 2.63 | |
| Assignee | Sam Van Oort [ svanoort ] | Thomas Weißschuh [ t8ch ] |
| Resolution | Fixed [ 1 ] | |
| Status | In Review [ 10005 ] | Resolved [ 5 ] |
Scott Hubbard
added a comment - 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.
Scott Hubbard
added a comment - 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.