I wouldn't call it "misusing". I'm simply working with what is there (that I knew about). Since I can't do SSH in post-build I am limited to what I can do, hence my frustration. With the emergence of Continuous Delivery/Deployment, I wish a job could be defined more broadly and tasks or steps within a job more fluidly to include any step in any order without having to resort to writing/installing all sorts of plugins or having to fence an operation to an explicit "type" of job or build phase.
As for the current job definition I've been working with, I would likely do more things in a post-build action if I were allowed to, thus the point of my frustration. I missed the "Any Build Step Plugin" but I will definitely give it a try. As for using environment variables to handle user/passwords, does that allow restricted access, including obfuscation in build logs? I'm unaware of the mechanism for managing/obfuscating users/passwords in a secure way outside of using the plugins. I'll look into that as well. Thanks for the feedback and I'm looking forward to trying the Workflow plugin. Is there any information or designs I can look at? On Wed, Jul 9, 2014 at 5:21 PM, Daniel Beck <m...@beckweb.net> wrote: > 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. > -- 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.
