Support workspace cloaking through a delimited list of server paths #28
Conversation
|
Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests |
|
@olivierdagenais In reference to bd98b91 you indicated that a new release might be on its way. Will feature pull requests (such as this one) be included in that release? Is there anything I can do to help get this PR included?" |
|
I'm very interested to see this PR come through. It's a big item for my team and I'm using @ajalexander's repo until the jenkins team integrates his changes. |
|
Sorry for the very long delay; when I first got commit access to this project, I had been only tackling my immediate needs at $DAYJOB. I am planning to review these changes for release 3.3.0. |
|
Awesome! |
|
Any plans on getting this merged? This is a big request for my team too :) |
|
Yes, all in good time. Please stand by. |
|
It seems that it might be better to have this be a more general mapping feature (selective cloaking and syncing). The issue here is that in really large repositories, it's a lot easier to start with "I need X, Y and Z" in general, but "don't sync X\A or Y\B". I may end up having to do this feature for the Jenkins instance I'm bringing up. I may lay most of the work on top of this sem's PR. |
|
@mmitche Are you proposing a different (or additional) way to configure what is mapped while still using the same cloaking mechanism behind the scene? Or did you have a different idea of how you planned to setup the workspace mapping? |
|
I think I'd like to have a general workspace mapping (would require changes to the cloaking code in the PR) so the synced folders were defined more closely to the way the TFS defines them (sync X, Y and Z but not Z/Y or X/Q), rather than syncing everything under a project (which is just a TFS folder) except for what we cloak. The issue is that for really big projects, the list of things cloaked can be much larger than a list of selective maps and cloaks. |
|
@ajalexander this change works great in our environment. Thank you. |
| @@ -178,7 +197,7 @@ private String substituteBuildParameter(Run<?,?> run, String text) { | |||
| public boolean checkout(AbstractBuild<?, ?> build, Launcher launcher, FilePath workspaceFilePath, BuildListener listener, File changelogFile) throws IOException, InterruptedException { | |||
| Server server = createServer(new TfTool(getDescriptor().getTfExecutable(), launcher, listener, workspaceFilePath), build); | |||
| try { | |||
| WorkspaceConfiguration workspaceConfiguration = new WorkspaceConfiguration(server.getUrl(), getWorkspaceName(build, Computer.currentComputer()), getProjectPath(build), getLocalPath()); | |||
| WorkspaceConfiguration workspaceConfiguration = new WorkspaceConfiguration(server.getUrl(), getWorkspaceName(build, Computer.currentComputer()), getProjectPath(build), cloakPaths, getLocalPath()); | |||
There was a problem hiding this comment.
cloakPaths here should have its build variables replaced.
There was a problem hiding this comment.
The new version of this (PR #60) does the build variable replacement.
|
This PR has been obsoleted by PR #60 (which uses the Java SDK to accomplish the same goal). |
This change adds support for cloaking in the TFS workspaces. Along with providing the server path, a delimited list of server paths can optionally be included for cloaking. During workspace creation, each of the cloak paths are cloaked after the workspace is initially mapped.
This should resolve JENKINS-4709.
For those wanting to specify multiple paths without changing the folder name or relative layout of the files, this also handles JENKINS-4542 and JENKINS-11007.