JENKINS-60630: Add GitSCMFileSystem support for EnvVar expansion #1040
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
JENKINS-60630 - Perform EnvVars expansion on GitSCMFileSystem BranchSpecs
Updates the GitSCMFileSystem class to support expanding environment variables on provided BranchSpecs.
Checklist
Put an
x
in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. This is simply a reminder of what we are going to look for before merging your code. If a checkbox or line does not apply to this pull request, delete it. We prefer all checkboxes to be checked before a pull request is mergedTypes of changes
What types of changes does your code introduce? Put an
x
in the boxes that apply. Delete the items in the list that do not applyFurther comments
One concern that I have is the approach for retrieving Environment Variables for the running job. I referenced the
lastBuild
whenisBuilding()
is true. This will create a race condition during concurrent builds (depending on how the SCM API is used) where all running builds will only use the environment variables for the last one initiated. I've confirmed this on my local Jenkins server.The only way I see to resolve this is to update the SCM API's SCMFileSystem.Builder.build api to allow for a new override:
This would allow anyone to reference the exact build that's being executed and easily infer the Item needed as well. In addition, the existing method can use the lastBuild as a
best effort
.Before diving into dependent libraries, I wanted to get another eye on this. As is, this works great aside from the potential issue of concurrent jobs.