I suggest you...

Ability to run a powershell script **once** before and/or after the deployment

Sometimes you need to run a script notify other systems before or after a deployment, such as monitoring systems load-balancers etc. (currently we ping NewRelic when we deploy).

To do this in the current powershell script model you have to be creative by somehow running the script on one of the tentacles. Though there are several ways of doing this they all lead to annoying management issues since you essentially have to choose a tantacle to run the script on. One issue could be that if the tentacle is decommissioned the script stops running (without warning). It would be nice if it were simpler to do this.

So I'm basically asking you to make it easier to run a script once before and/or after the deployment, without having to figure out where to run the script. Maybe it could be run on the octopus server, or maybe octopus could automatically choose an arbitrary tentacle to run the script.

98 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Johannes Hansen shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Chris McKenzie commented  ·   ·  Flag as inappropriate

    Our scenario is:
    1. We use a service account on the Octopus Server that is essentially neutered. It can't do much beyond communicate with Tentacle Instances.
    2. Tentacle Service Accounts are constrained to doing what they need to in their own environments. I.E., environments have their own tentacle service accounts.

    Given these criteria I may need to place a file in a specific network location, or run a SQL script. I only want this to happen once but the Octopus Server will not have rights to do either of these things as it doesn't operate "in the environment."

    The need is for one of the deployment agents to handle this but for it to only happen once (avoiding things like database deadlocks).

  • Wenzel, Toni commented  ·   ·  Flag as inappropriate

    My scenario:
    1.- 200+ Octopus projects
    2.- Each of those projects has a update DB step configured to run on "database-updater" target role.
    3.- Production environment has 5 targets with the "database-updater" role.

    My requirements:
    1.- For each project, the updated DB step needs to run once on one target only.
    2.- When many projects are deploying at the same time, I want the work to be distributed among the 5 targets (so if I deploy 100 projects at the same time, each "database-updater" target would run 20 projects' update DB step).

    At the moment this is only possibly by creating multiple roles "database-updater1" etc and assign those roles fix to the projects.

    Please provide an option to define either a target or a role act like a queue.

  • Ben Aves commented  ·   ·  Flag as inappropriate

    +1, We have automated UI tests that need only be run once per deployment across N physical machines.

  • Chris McKenzie commented  ·   ·  Flag as inappropriate

    The use case for us is that we have octopus packages that contain msi's to be deployed to several workstations. We also need to copy the msi's to a network share. We routinely get failed deployments due to multiple tentacles attempting to copy the msi to the network share even though we check for the existence of the file first. Ideally, we'd be able to specify that a step should only run on one of the available tentacles. I can see how this would be useful for database migrators or other "do once and forget" jobs.

  • Chris Camburn commented  ·   ·  Flag as inappropriate

    My specific use case is to not just run something once, but to have it run on one tentacle from a pool of tentacles. We have a handful of server-intensive processes that can be run from any server, but must only be run once. What we'd like to do is have a handful of tentacles with the same role, and each deployment would select one tentacle with that role and run the steps. That allows us to do something similar to TeamCity build agents, and offload the work on the first available tentacle.

  • Silas Hansen commented  ·   ·  Flag as inappropriate

    In the "Run on" section of a step setup, it would be great to have a dropdown with two choices:

    "Run on all matching tentacles" (default)
    "Run on first matching tentacle"

    If mores specific usecases should pop up later, you can add them to this dropdown successively. Maybe something like "Run on random matching tentacle".

  • Andrew Armstrong commented  ·   ·  Flag as inappropriate

    The problem with an "octopus" role is that if that machine is offline then the step (I assume) does not run, and makes it a little bit more complicated to reason about than a step that is just "We run this only once (on whatever tentacle is chosen at random during deployment)".

  • Brannon Jones commented  ·   ·  Flag as inappropriate

    We are running a tentacle on the Octopus server to do this. The downside is that you must add the "octopus" tentacle to each environment, which seems weird. It would be nice if you could just have a "global" step that runs implicitly inside the Octopus server, without requiring an explicit tentacle.

  • Andrew McClenaghan commented  ·   ·  Flag as inappropriate

    There could be a few options for this. Once per deployment for this exact case which could be ran on the Octopus Server itself. Though there is another option once per role where a script might get ran once on a database server or once on a web server. Ideally both options would be great as sometimes your Octopus server can only talk to the tentacles via 10933 and not via SQL or file shares.

  • racingcow commented  ·   ·  Flag as inappropriate

    I am doing the exact same thing with New Relic notifications and alas, my PowerShell script runs once for each machine in the environment to which I deploy. If my web farm has three machines in it, this results in New Relic being notified of three deployments instead of one.

    As such, I'd also love for some way to run a script once for the entire deployment.

Feedback and Knowledge Base