Details
-
Task
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
-
2.185
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.)
Attachments
Issue Links
- causes
-
JENKINS-58733 Cannot delete project
-
- Resolved
-
- is duplicated by
-
-
- Resolved
-
-
-
- Closed
-
- relates to
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
JENKINS-36088 Use NIO rather than JNR whenever possible
-
- Resolved
-
-
-
- Open
-
-
-
- Closed
-
- links to
- Wiki Page
-
Wiki Page Loading...
Activity
Merten Schumann
added a 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 ...
Merten Schumann
added a 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 ... Will Jenkins remove all the symlinks from existing builds after the upgrade?
No. See release notes for a script to do this manually if you care.
Merten Schumann
added a comment - good ... Thanx alot for your feedback, Jesse Glick.
Merten Merten Schumann
added a 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 
Merten Schumann
added a 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
The usual way of doing this is with the Copy Artifact plugin.