Repository navigation
[JENKINS-37862] Extract build symlink handling to a plugin #17491
Description
There are many bugs and limitations which arise mainly on Windows related to use of symbolic links for build directories (Run.createSymlink for lastSuccessful -> builds/lastSuccessfulBuild, and PeepholdPermalink.writeSymlink for builds/lastSuccessfulBuild -> 99).
Under the assumption that few users even know about, let alone care about, the longstanding Jenkins feature of allowing you to refer to, say, a particular artifact from the last stable build of a job using a fixed file path on the master node (for use from external systems), I think it is reasonable to split this out into a plugin for the tiny set of people who need it, and not bother everyone else with these bugs.
PeepholePermalink.resolve does use symlinks as a kind of cache, useful for example to avoid massive build loading when resolving lastFailedBuild when the past several hundred builds in fact succeeded. But perhaps this can be done in some other way, like a simple $JENKINS_HOME/jobs/$job/permalinks.properties. That would anyway result in better performance for those Windows users who cannot create symlinks.
(Even Unix users are occasionally hit by problems when they use, e.g., cp -r to back up $JENKINS_HOME. IIRC it is a filed bug that this results in cryptic exceptions.)
Originally reported by 
jglick, imported from: Extract build symlink handling to a plugin
- assignee: jglick
- status: Resolved
- priority: Major
- component(s): core
- label(s): robustness, split-plugins-from-core, symlink, windows
- resolution: Fixed
- resolved: 2019-07-11T19:08:34+00:00
- votes: 2
- watchers: 7
- imported: 2025-11-24
Raw content of original issue
There are many bugs and limitations which arise mainly on Windows related to use of symbolic links for build directories (Run.createSymlink for lastSuccessful -> builds/lastSuccessfulBuild, and PeepholdPermalink.writeSymlink for builds/lastSuccessfulBuild -> 99).
Under the assumption that few users even know about, let alone care about, the longstanding Jenkins feature of allowing you to refer to, say, a particular artifact from the last stable build of a job using a fixed file path on the master node (for use from external systems), I think it is reasonable to split this out into a plugin for the tiny set of people who need it, and not bother everyone else with these bugs.
PeepholePermalink.resolve does use symlinks as a kind of cache, useful for example to avoid massive build loading when resolving lastFailedBuild when the past several hundred builds in fact succeeded. But perhaps this can be done in some other way, like a simple $JENKINS_HOME/jobs/$job/permalinks.properties. That would anyway result in better performance for those Windows users who cannot create symlinks.
(Even Unix users are occasionally hit by problems when they use, e.g., cp -r to back up $JENKINS_HOME. IIRC it is a filed bug that this results in cryptic exceptions.)
Activity
jenkins-infra-bot commentedon Aug 31, 2016
Remote links associated with this issue:
jenkins-infra-bot commentedon Dec 5, 2017
Raw content of original comment:
Discussed this with dnusbaum in the context of
JENKINS-36088.jenkins-infra-bot commentedon Apr 11, 2019
Raw content of original comment:
jglick I like this idea (and also I need it to fix symlink issues of the shelve plugin once and for all). I'm happy to start working on it, but cannot commit to any timeline. Would this be ok for you or do you intend to tackle it soon?
jenkins-infra-bot commentedon Apr 12, 2019
Raw content of original comment:
I will give it a shot.
jenkins-infra-bot commentedon Aug 6, 2019
mertens:
Raw content of original comment:
> allowing you to refer to, say, a particular artifact from the last stable build of a job using a fixed file path on the master node
we do use exactly this to refer build results of build jobs from test jobs ... I think we had no wget at time of creating such jobs
- well, so I'll (have to) give the Build Symlink plugin a try, when these changes appear in the LTS release ... thanx for not just removing this feature 
no one else relying on good old symlinks in the Jenkins filesystem?
jenkins-infra-bot commentedon Aug 6, 2019
Raw content of original comment:
The usual way of doing this is with the Copy Artifact plugin.
jenkins-infra-bot commentedon Aug 7, 2019
mertens:
Raw content of original comment:
... Copy Artifact plugin, one approach, sure
we've got (the same) scripts running in Hud aeh Jenkins + in other environments - Ux shell or Cygwin - and then it's good not to say required to have the same preconditions, I mean, just copy command instead of a plugin available in Jenkins environment "only" ...
I've got a question: so when I upgrade Jenkins to a newer release with this behavior for new builds no symlinks will be created (as long as the Build Symlink plugin is not installed/active) - what about existing builds? Will Jenkins remove all the symlinks from existing builds after the upgrade? Hopefully only when the "Manage Old Data" action is invoked ...
jenkins-infra-bot commentedon Aug 7, 2019
Raw content of original comment:
No. See release notes for a script to do this manually if you care.
jenkins-infra-bot commentedon Aug 8, 2019
mertens:
Raw content of original comment:
good ... Thanx alot for your feedback, Jesse Glick.
Merten
jenkins-infra-bot commentedon Oct 10, 2019
mertens:
Raw content of original comment:
just updated our Jenkins to 2.190.1 - made test builds, Build Symlinks plugin enabled and disabled - thanx to the plugin the symlinks are still there, thanx alot again