-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
Currently the @Library annotation allows to specify only a fixed-string version of a library to be loaded. For pipelines that deal with branching (e.g. dev/qa/stage/prod or randomly-named feature branches as the pipelines and their libraries evolve) this causes either more configuration to separate jobs per folders with preloaded default library versions (and forfeiting benefits of e.g. Multi-Branch Pipeline and Organization Folders automagic), or needlessly deviating Git sources to reference a particular library branch.
This situation has certain historic reasons, including security (not allowing arbitrary code outside the sandbox, which the library step apparently imposes among other inconveniences like lame access to library src/* classes - being a post-compilation step in a pipeline) and Groovy->Java CPS (annotated @Library is loaded and compiled before general-purpose groovy scripting of the pipeline and so its variables can be used).
This issue states the desired ability to load at least same "version" (branch name) of the trusted globally configured library as that of the pipeline being executed, with little hassle to scale it on the pipeline coding and Jenkins configuration side.
PR posted as https://github.com/jenkinsci/pipeline-groovy-lib-plugin/pull/19 to allow literally requesting this (optionally, site-configured):
@Library('libname@${BRANCH_NAME}') _ import my.lib.name.class; ...
If the "version" requested in pipeline script is a literal string ${BRANCH_NAME}, the implementation would try to learn the "BRANCH_NAME" environment variable set for the current Run object. If that is present, it would validateVersion() as implemented by this or that LibraryRetriever backend (SCM here, HTTP in workflow-cps-global-lib-http-plugin, etc.) and if the string is not rejected, it would be substituted as the version to use. Otherwise the configured default version would be used as fallback.
[JENKINS-69731] Want @Library annotation to always load same version (feature branch name) of library as pipeline script from SCM
| Description |
Original:
Currently the @Library annotation allows to specify only a fixed-string version of a library to be loaded. For pipelines that deal with branching (e.g. dev/qa/stage/prod or randomly-named feature branches as the pipelines and their libraries evolve) this causes either more configuration to separate jobs per folders with preloaded default library versions (and forfeiting benefits of e.g. Multi-Branch Pipeline and Organization Folders automagic), or needlessly deviating Git sources to reference a particular library branch.
This situation has certain historic reasons, including security (not allowing arbitrary code outside the sandbox, which the {{library}} step apparently imposes among other inconveniences like lame access to library {{src/*}} classes - being a post-compilation step in a pipeline) and Groovy->Java CPS (annotated {{@Library}} is loaded and compiled before general-purpose groovy scripting of the pipeline and so its variables can be used). This issue states the desired ability to load at least same "version" (branch name) of the trusted globally configured library as that of the pipeline being executed, with little hassle to scale it on the pipeline coding and Jenkins configuration side. PR will be posted shortly, to (optionally, site-configured) allow literally requesting this: {code:java} @Library('libname@${BRANCH_NAME}') _ import my.lib.name.class; ... {code} If the "version" requested in pipeline script is a literal string {{{}${BRANCH_NAME}{}}}, the implementation would try to learn the "BRANCH_NAME" environment variable set for the current Run object. If that is present, it would {{validateVersion()}} as implemented by this or that {{LibraryRetriever}} backend (SCM here, HTTP in workflow-cps-global-lib-http-plugin, etc.) and if the string is not rejected, it would be substituted as the version to use. Otherwise the configured default version would be used as fallback. |
New:
Currently the @Library annotation allows to specify only a fixed-string version of a library to be loaded. For pipelines that deal with branching (e.g. dev/qa/stage/prod or randomly-named feature branches as the pipelines and their libraries evolve) this causes either more configuration to separate jobs per folders with preloaded default library versions (and forfeiting benefits of e.g. Multi-Branch Pipeline and Organization Folders automagic), or needlessly deviating Git sources to reference a particular library branch.
This situation has certain historic reasons, including security (not allowing arbitrary code outside the sandbox, which the {{library}} step apparently imposes among other inconveniences like lame access to library {{src/*}} classes - being a post-compilation step in a pipeline) and Groovy->Java CPS (annotated {{@Library}} is loaded and compiled before general-purpose groovy scripting of the pipeline and so its variables can be used). This issue states the desired ability to load at least same "version" (branch name) of the trusted globally configured library as that of the pipeline being executed, with little hassle to scale it on the pipeline coding and Jenkins configuration side. PR will be posted shortly, to (optionally, site-configured) allow literally requesting this: {code:java} @Library('libname@${BRANCH_NAME}') _ import my.lib.name.class; ... {code} If the "version" requested in pipeline script is a literal string {{{}${BRANCH_NAME\}}}, the implementation would try to learn the "BRANCH_NAME" environment variable set for the current Run object. If that is present, it would {{validateVersion()}} as implemented by this or that {{LibraryRetriever}} backend (SCM here, HTTP in workflow-cps-global-lib-http-plugin, etc.) and if the string is not rejected, it would be substituted as the version to use. Otherwise the configured default version would be used as fallback. |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| Description |
Original:
Currently the @Library annotation allows to specify only a fixed-string version of a library to be loaded. For pipelines that deal with branching (e.g. dev/qa/stage/prod or randomly-named feature branches as the pipelines and their libraries evolve) this causes either more configuration to separate jobs per folders with preloaded default library versions (and forfeiting benefits of e.g. Multi-Branch Pipeline and Organization Folders automagic), or needlessly deviating Git sources to reference a particular library branch.
This situation has certain historic reasons, including security (not allowing arbitrary code outside the sandbox, which the {{library}} step apparently imposes among other inconveniences like lame access to library {{src/*}} classes - being a post-compilation step in a pipeline) and Groovy->Java CPS (annotated {{@Library}} is loaded and compiled before general-purpose groovy scripting of the pipeline and so its variables can be used). This issue states the desired ability to load at least same "version" (branch name) of the trusted globally configured library as that of the pipeline being executed, with little hassle to scale it on the pipeline coding and Jenkins configuration side. PR will be posted shortly, to (optionally, site-configured) allow literally requesting this: {code:java} @Library('libname@${BRANCH_NAME}') _ import my.lib.name.class; ... {code} If the "version" requested in pipeline script is a literal string {{{}${BRANCH_NAME\}}}, the implementation would try to learn the "BRANCH_NAME" environment variable set for the current Run object. If that is present, it would {{validateVersion()}} as implemented by this or that {{LibraryRetriever}} backend (SCM here, HTTP in workflow-cps-global-lib-http-plugin, etc.) and if the string is not rejected, it would be substituted as the version to use. Otherwise the configured default version would be used as fallback. |
New:
Currently the @Library annotation allows to specify only a fixed-string version of a library to be loaded. For pipelines that deal with branching (e.g. dev/qa/stage/prod or randomly-named feature branches as the pipelines and their libraries evolve) this causes either more configuration to separate jobs per folders with preloaded default library versions (and forfeiting benefits of e.g. Multi-Branch Pipeline and Organization Folders automagic), or needlessly deviating Git sources to reference a particular library branch.
This situation has certain historic reasons, including security (not allowing arbitrary code outside the sandbox, which the {{library}} step apparently imposes among other inconveniences like lame access to library {{src/*}} classes - being a post-compilation step in a pipeline) and Groovy->Java CPS (annotated {{@Library}} is loaded and compiled before general-purpose groovy scripting of the pipeline and so its variables can be used). This issue states the desired ability to load at least same "version" (branch name) of the trusted globally configured library as that of the pipeline being executed, with little hassle to scale it on the pipeline coding and Jenkins configuration side. PR posted as https://github.com/jenkinsci/pipeline-groovy-lib-plugin/pull/19 to allow literally requesting this (optionally, site-configured): {code:java} @Library('libname@${BRANCH_NAME}') _ import my.lib.name.class; ... {code} If the "version" requested in pipeline script is a literal string {{{}$\{BRANCH_NAME{}}}}, the implementation would try to learn the "BRANCH_NAME" environment variable set for the current Run object. If that is present, it would {{validateVersion()}} as implemented by this or that {{LibraryRetriever}} backend (SCM here, HTTP in workflow-cps-global-lib-http-plugin, etc.) and if the string is not rejected, it would be substituted as the version to use. Otherwise the configured default version would be used as fallback. |