|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
+1 for fixing this. A simple example for why the promote plugin should have the ability to tie to the same node where the build was executed is the Git publisher plugin which is an option in the list of tasks available to the promote plugin. If you want to treat merging/publishing a Git branch or tag created by your build up to the server (which is the point of the Git publisher plugin), then you need access to the workspace of the build.
Another example is running a script as part of a promotion, and that script is in the workspace/git repository. Sure, you treat the script as a build artifact, then grab it, etc. etc., but it makes a lot more sense to be able to tie a promotion to the same system.
Thanks for considering.