This plugin lets you shelve projects so that they can easily be resurrected. "Shelving a project" is like deleting a project into a recycle bin. When you shelve a project, it will disappear from the list of projects and become inaccessible from Jenkins, just like how it goes when a project is deleted, with one difference — instead of getting deleted, the data is archived into a tar file and stored on the server. This allows the administrator to resurrect it later (aka unshelving), in an unlikely event that the job turned out to be necessary.
This feature is convenient when you have lots of old jobs lying around, and you are 99% sure you won’t need them but you can’t rule out 1% possibility that you might find them necessary later.
When you install this plugin, you get "shelve project" in each job page, as follows:
You can click this icon and shelve the project. The shelved projects can be resurrected from the Jenkins top page:
-
first click on the Shelved Project action:
-
Then choose the project you wish to unshelve:
|
Important
|
In order to unshelve, the user needs the ADMINISTER permission. |
Shelving a project requires the DELETE permission. Unshelving a project requires the ADMINISTER permission.
From version 2.5 on, changelog is automatically generated using release-drafter. See directly the GitHub release page for the plugin.
For older releases, have a look to the archive.
|
Note
|
This issue has been fixed in release 2.5 of the plugin however all the shelves created using an earlier version of the plugin will have the issue and you’ll need to apply the workaround. |
There is a currently a known issue in Core, making the tar function breaking the symlinks. Sadly, the Shelve Pipeline Plugin is using this tar function, and therefore the symlinks are lost during the shelving/unshelving process.
Up until Jenkins 2.90, this was mainly hidden from the end user, as Jenkins was silently fixing the symlinks during a build. But since this version, some changes made this issue visible.
This means that, when you unshelve a job, you will see a stack trace like this in all your build logs:
ln builds/lastSuccessfulBuild ***/jenkins-home/jobs/toto/lastSuccessful failed
java.nio.file.DirectoryNotEmptyException: ***/jenkins-home/jobs/toto/lastSuccessful
at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
at java.nio.file.Files.deleteIfExists(Files.java:1165)
at hudson.Util.createSymlink(Util.java:1333)
at hudson.model.Run.createSymlink(Run.java:1866)
at hudson.model.Run.updateSymlinks(Run.java:1847)
at hudson.model.Run.execute(Run.java:1725)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:421)While this won’t affect the output of your build, this is far from convenient. A workaround for this issue is to manually delete the wrongly created files using a script. Here is an example:
-
First make a dry run to ensure the script is not deleting something it shouldn’t:
find ${JENKINS_HOME}/jobs/ -type d \( -name lastFailedBuild -o -name lastSuccessfulBuild -o -name lastUnsuccessfulBuild -o -name lastStableBuild -o -name lastUnstableBuild -o -name lastFailed -o -name lastSuccessful -o -name lastUnsuccessful -o -name lastStable -o -name lastUnstable \)
-
Then, do the real cleaning:
find ${JENKINS_HOME}/jobs/ -type d \( -name lastFailedBuild -o -name lastSuccessfulBuild -o -name lastUnsuccessfulBuild -o -name lastStableBuild -o -name lastUnstableBuild -o -name lastFailed -o -name lastSuccessful -o -name lastUnsuccessful -o -name lastStable -o -name lastUnstable \) -exec rm -rfv "{}" \;
The plugin follows Jenkins licensing (exception listed below).
File manager icon (shelve-project-icon.png) was released into the public domain by the Tango! Desktop Project. The original image can be found here.
