Enable multi-branch remote polling #1721
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This essentially reverts 3b7cdff. In 2024, git ls-remote on a local repo works and the tests already depend on it in testPolling_CanDoRemotePollingIfOneBranchButMultipleRepositories. Add an assertion in testBasicRemotePoll to ensure that it's really testing remote polling.
When a single empty branch is encountered, getSingleBranch converts it to the ** wildcard spec like BranchSpec. Since that's not null, requiresWorkspaceForPolling says it can be used with remote polling. However, remote polling doesn't work well for wildcard branches since it doesn't have access to the remote history to prune old branches. Detect this special case and require workspace polling for it. I'm not sure why getSingleBranch goes to such effort to reject wildcard branches but then treats allows an empty branch as a wildcard. It seems like it should return null for an empty branch, but it also gets passed to getCandidateRevisions, which may expect those semantics.
As long as the branch specs can't match multiple remote branches, then remote polling can be used since it can (and already does) match each branch spec against the map returned from `git ls-remote`. Add a separate helper to determine if all branch specs are simple and use that to determine if workspace polling is required.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
For as long as we've been using Jenkins, workspaces have been required for polling on jobs with multiple branches. We have a bunch of jobs where the git repo has a code branch and a packaging branch. The job is set to trigger on changes from either branch, and then build merges them together. Since workspace polling automatically triggers a build if there's no workspace, the build script has to be prepared for the case where it's building the same code and should do nothing.
This works fine except that every time we replace our worker nodes, any event on the remote repository triggers the workspace polling and a build to be run. This is multiplied since we often have multiple sets of stable branches from the repositories that have associated Jenkins jobs. It's a lot of pointless busy work when it should be easy to tell that the two fixed branches configured in each job haven't changed.
This PR enables remote pulling for multiple non-wildcard branches. The code was already there to loop over requested branches, but the mode was only triggered for a single non-wildcard branch. I included two other fixes I came across while running the test suite to ensure I was exercising as I expected.
I found several similar issues but not one that was specifically about remote polling being used for multiple branches. I'm happy to update the PR or commit messages if there is one. Here is a search for all git-plugin issues containing
ls-remote.Testing done
Testing has been done with new unit tests and passing of the existing tests. I haven't had a chance to test this on our instance.
Submitter checklist