-
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
[JENKINS-49635] Permit VirtualFile to serve external file contents
Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
Link | New: This issue relates to JENKINS-25224 [ JENKINS-25224 ] |
Link |
New:
This issue relates to |
Remote Link | New: This issue links to "core PR 3302 (Web Link)" [ 20105 ] |
Link |
New:
This issue relates to |
Status | Original: In Progress [ 3 ] | New: In Review [ 10005 ] |
Remote Link | New: This issue links to "copyartifact PR 100 (Web Link)" [ 20194 ] |
Remote Link | New: This issue links to "workflow-api PR 67 (Web Link)" [ 20195 ] |
Remote Link | New: This issue links to "workflow-basic-steps PR 60 (Web Link)" [ 20196 ] |
Remote Link | New: This issue links to "compress-artifacts PR 7 (Web Link)" [ 20207 ] |