-
New Feature
-
Resolution: Fixed
-
Major
Extracting a comment from JENKINS-25224:
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.)
- relates to
-
JENKINS-17236 Pluggable artifact transfer & storage
-
- Resolved
-
-
JENKINS-25224 Use VirtualFile for workspace browser
-
- Open
-
-
JENKINS-51033 Use incrementals from workflow-api PR 67 and downstream
-
- Resolved
-
-
JENKINS-26810 File attribute/symlink support in VirtualFile
-
- Resolved
-
- links to
Code changed in jenkins
User: Jesse Glick
Path:
core/src/main/java/hudson/model/DirectoryBrowserSupport.java
core/src/main/java/jenkins/util/VirtualFile.java
test/src/test/java/hudson/model/DirectoryBrowserSupportTest.java
http://jenkins-ci.org/commit/jenkins/3f01a774662d0e6e3d4f644e6a3197009f0c7b14
Log:
JENKINS-49635Defining new VirtualFile methods to better support external artifact storage.