Your problem is that you're misusing the 'software build' concept and job type for something that isn't strictly a software build, and its limitations become obvious.
Post-build steps usually fall into one of the categories 'recorder' (e.g. archive artifacts) and 'notifier' (email notifications), things that usually don't make sense before the actual work is done. I expect that very few actual build scripts need to SCP right in the middle, at least compared to those that upload things somewhere when they're finished. So that's what the plugin author decided should be the supported use case, and the reason you have difficulty achieving what you want. When I try do something like this, I usually try to get all the basic functionality going from a shell/batch script so it's usable outside Jenkins if there's a need to, reducing Jenkins to a fancy scheduler, log archiver and notifier. Passwords are provided by Jenkins as environment variables, SSH keys are stored on the slaves. Versioning of configuration is easier that way, and the job configurations don't become too complex. That said, have you tried Any Build Step Plugin? It might allow you to do what you want to achieve. The upcoming Workflow plugin probably also has the required flexibility of combining steps more flexibly in its job type. On 10.07.2014, at 00:53, Jeff <predato...@gmail.com> wrote: > This is a bit of a rant, but I'm unclear why it matters which steps are > available as a build step vs. a post-build step. > > I'm trying to create a simple job to grab debian packages archived from > various upstream "build" jobs and installing/configuring the debian packages > on a set of test servers as part of an "install" job. > > The "Install job" sequence would be: > * Copy artifacts from previous jobs > * SCP them to the specified server(s) > * Run the installers via SSH > * Update configuration > However, I am unable to use the Jenkins plugins to do step 2 and 3 in the > proper order because the "Publish artifacts to SCP Repository" plugin option > is not available as a "build step" and "Execute shell script on remote host > using ssh" plugin as it's not available as a "post-build action". (chicken > or egg paradox). > > The motivation to use these plugins is to help manage the hosts/passwords > required to use SCP/SSH. > > Thus, the question is ... why does Jenkins need to differentiate between a > build step and a post-build action? Why not allow a mix of any type of > operation/step, regardless if it's type? > > It seems job creation flexibility would be enhanced if all tasks could be > used, particularly for jobs that don't really do builds (in the traditional > sense) such as creating a "pipeline" of phases/steps (continuous delivery, > etc.) deploy-dev --> functional test --> deploy-staging --> integration test > --> deliver release candidate. > > Has there been consideration around allowing any step to be added in any > order? > > -- > Jeff Vincent > See my LinkedIn profile at: > http://www.linkedin.com/in/rjeffreyvincent > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jenkinsci-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
