What feature do you want to see added?
While working on #644 and the Jenkins-Dynamatrix project across a fleet of nodes doing Git, I came up with the idea that currently a job configuration (e.g. in an Organization Folder which generates Multi-Branch Pipeline folders and ultimately leaf jobs) is the one place to specify the git reference repository location. PR #644 addresses that such a location can become parameterized, to serve in fact multiple (bare) git index caches hosted under the specified location, however the location itself is assumed to exist at the specified path on all nodes doing checkout operations.
To avoid creeping the scope of that long-awaiting PR even further, I post the new idea separately. It is simple: allow the controller and build agents or even individual jobs to define an environment variable (tentatively namespaced like JENKINS_GIT_REFERENCE_REPO_DIR) and teach the git-client-plugin to resolve it (or throw an exception if present in the refrepo location string and not set in current node's env).
Also consider honouring such envvar if no (empty/null) location was passed by the job configuration, and perhaps not by checkout scm or $class: GitSCM settings - but then for these we should somehow support the case of "explicitly set to empty/null means to not use it". This would allow (persistent) build agents to use their caches without a special effort on job authors' side.
Upstream changes
Loosely related to #644, may touch on nearby lines when parsing the refrepo location string. Maybe this issue is better addressed after that PR gets merged.
Are you interested in contributing this feature?
Yes, but it seems to be a low-hanging fruit anyone can reap.
What feature do you want to see added?
While working on #644 and the Jenkins-Dynamatrix project across a fleet of nodes doing Git, I came up with the idea that currently a job configuration (e.g. in an Organization Folder which generates Multi-Branch Pipeline folders and ultimately leaf jobs) is the one place to specify the git reference repository location. PR #644 addresses that such a location can become parameterized, to serve in fact multiple (bare) git index caches hosted under the specified location, however the location itself is assumed to exist at the specified path on all nodes doing
checkoutoperations.To avoid creeping the scope of that long-awaiting PR even further, I post the new idea separately. It is simple: allow the controller and build agents or even individual jobs to define an environment variable (tentatively namespaced like
JENKINS_GIT_REFERENCE_REPO_DIR) and teach the git-client-plugin to resolve it (or throw an exception if present in the refrepo location string and not set in current node'senv).Also consider honouring such envvar if no (empty/null) location was passed by the job configuration, and perhaps not by
checkout scmor$class: GitSCMsettings - but then for these we should somehow support the case of "explicitly set to empty/null means to not use it". This would allow (persistent) build agents to use their caches without a special effort on job authors' side.Upstream changes
Loosely related to #644, may touch on nearby lines when parsing the refrepo location string. Maybe this issue is better addressed after that PR gets merged.
Are you interested in contributing this feature?
Yes, but it seems to be a low-hanging fruit anyone can reap.