WorkspaceBrowser should be extended (or replaced) to accept VirtualFile instead of FilePath. This way, we can provide more flexibility for deployments and systems that manage workspaces.
- is related to
-
JENKINS-20102 Directory browser cannot handle paths contain backslash on Linux
-
- Open
-
-
JENKINS-21819 Add 'tail' functionality for (log) files in the workspace
-
- Open
-
-
JENKINS-24677 Allow to manipulate workspace from the job page
-
- Open
-
-
JENKINS-20998 Add Timestamp to Workspace View
-
- Resolved
-
-
JENKINS-16454 extension point to browse workspace when build node is offline
-
- Resolved
-
- relates to
-
JENKINS-49635 Permit VirtualFile to serve external file contents
-
- Resolved
-
- links to
Taking VirtualFile would certainly help, though this means AbstractProject.getWorkspace cannot work—you would also need to introduce a new set of methods for finding the VirtualFile root to browse.
Also VirtualFile as written is not quite flexible enough, because it assumes that the master should be in charge of retrieving file contents (as bytestreams) and serving them to the client. What we found was necessary also for making an ArtifactManager based on, say, S3 was to allow VirtualFile to optionally designate a replacement URL that would be served directly to clients. (DirectoryBrowserSupport would need to call the new method.) In the context of workspace browsing, this would mean that the master could redirect workspace browse requests (from the root, from individual files, or just from certain subtrees) to other servers that could process the request more directly and efficiently.