-
Improvement
-
Resolution: Unresolved
-
Major
-
None
-
Platform: All, OS: All
It would a great plus if deploying previous builds from the hudson manager could
be introduced.plus a way to browse the previous builds (war files or what ever)
through the manager itself.So a user can simply select a previous build
depending on his requirements and simply push it to the container.
regards
Sam
[JENKINS-3892] Deploy Previous builds ..
samuelz
added a comment - Ive tried installing this Promoted build plugin bt its status is always pending
n never come back , plus after reading about this plugin it feels like that this
doesnt serve the exact purpose of the issue said above.
This is not doubt a marvellous addition bt works with stable builds...where as
i or many in future would be looking to deploy any previous build to container
directly from hudson manager rather than hvn an option of just deploying a new one.
Thnks for quick response.God bless ya...
samuelz
added a comment - Ive tried installing this Promoted build plugin bt its status is always pending
n never come back , plus after reading about this plugin it feels like that this
doesnt serve the exact purpose of the issue said above.
This is not doubt a marvellous addition bt works with stable builds...where as
i or many in future would be looking to deploy any previous build to container
directly from hudson manager rather than hvn an option of just deploying a new one.
Thnks for quick response.God bless ya... It seems that this feature is still lacking.
The deploy plugin and the promoted builds plugin do not work in synch, as the deploy plugin is relative to the workspace root, which seems to be the latest build artifacts. Therefore, the deploy plugin does it's thing with the latest build, and the promoted builds plugin thinks it re-promoted the previous build, but this is not the case.
It'd be nice if instead of deploying from workspace, it deployed from that particular build's artifacts instead. I don't know if this is a fault of the promotion or the deployment plugin.
For now, I've been trying to hack it to use the BUILD_ID environment variable in the URL for the deployment but I am not getting anywhere. I'm not sure if it's unable to go up one level or what.
lucasgray
added a comment - - edited It seems that this feature is still lacking.
The deploy plugin and the promoted builds plugin do not work in synch, as the deploy plugin is relative to the workspace root, which seems to be the latest build artifacts. Therefore, the deploy plugin does it's thing with the latest build, and the promoted builds plugin thinks it re-promoted the previous build, but this is not the case.
It'd be nice if instead of deploying from workspace, it deployed from that particular build's artifacts instead. I don't know if this is a fault of the promotion or the deployment plugin.
For now, I've been trying to hack it to use the BUILD_ID environment variable in the URL for the deployment but I am not getting anywhere. I'm not sure if it's unable to go up one level or what. 
Steve Prior
added a comment - Tonight I was showing Jenkins to a friend and potential Jenkins user and fell on my face when he asked how to deploy a previous build with promoted builds and the deployment plugin. I've now read on the suggestion to use the copy archived builds plugin and think that's a really bad idea. In my opinion every plugin that adds an action that can be executed in the process of promoting a build should allow the option to switch between being based off the workspace directory to based from the build directory. Then you would turn on the "archive build artifacts" option and then when promoting a build you would be deploying the archived artifact instead of the artifact out of the workspace. This would eliminate any race conditions as well as naturally give you the ability to re-execute the promotion of a previous build to redeploy it or perform any other promotion actions.
Steve Prior
added a comment - Tonight I was showing Jenkins to a friend and potential Jenkins user and fell on my face when he asked how to deploy a previous build with promoted builds and the deployment plugin. I've now read on the suggestion to use the copy archived builds plugin and think that's a really bad idea. In my opinion every plugin that adds an action that can be executed in the process of promoting a build should allow the option to switch between being based off the workspace directory to based from the build directory. Then you would turn on the "archive build artifacts" option and then when promoting a build you would be deploying the archived artifact instead of the artifact out of the workspace. This would eliminate any race conditions as well as naturally give you the ability to re-execute the promotion of a previous build to redeploy it or perform any other promotion actions. 
You can do this now with the Promoted Builds plugin.