I suggest you...

allow the Run Condition of a step to be based on a variable not just whether a previous step has been successful or not

At the moment the run condition of a step is based on the success of failure of previous steps. It would be useful if this could be based on custom variable.

In our case, we have a step to check if there are any database changes required, if there are then we take a backup else we don't bother. Whilst this could be all done with in a single step template as there were some already available that did most of what we wanted this process takes three steps in our deployment.

1. compare for differences
2. run backup if differences exist
3. run db upgrade.

The first step sets a variable to indicate whether the next to should run or not. I've then added an extra parameter to these steps to indicate whether they should be run or not and then have some powershell at the start of the steps to check this variable for true or false.

As this powershell is the same across all my steps which require a check to run or now. I figured it might be useful to have this ability within octopus itself.

245 votes
Vote
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Huw Jenkins shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

14 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • Chris Camburn commented  ·   ·  Flag as inappropriate

    Perhaps adding a new parameter to Set-OctopusVariable for -Type and the ability to specify either string (default) or boolean. Then, once boolean variables can be passed between steps, use that as the trigger for a step running or not.

  • Carsten Jørgensen commented  ·   ·  Flag as inappropriate

    +1 for this feature

    We're running a Saas application in a high-density environment with alot of tennants. If we're deploying to 50 tenants, we only need to deploy a single fileset. A condition checking if a given site exists, could be very helpful in our situation

  • Dhananjaneyulu Dasari commented  ·   ·  Flag as inappropriate

    Part of our deployment process we are deploying 3 packages. But not all the packages are required to deploy. So it would be nice to have an option based on variable value to decide whether to execute a step of not

  • David Brower commented  ·   ·  Flag as inappropriate

    Part of our deployment process involves an email being sent to our support desk and a manual intervention. I am currently testing our deployment and would like to be able to disable these steps until I am sure that the other deployment steps work correctly.

    It would be great to be able to toggle a step like that on/off - rather than having to delete and later re-add the steps in question.

  • Anonymous commented  ·   ·  Flag as inappropriate

    I would really like this feature. Is there any news on actual implementation? Or any work arounds? I want to make a 'manual intervention' step conditional on the value of a variable emitted by a custom script step.

  • James Connor commented  ·   ·  Flag as inappropriate

    Would be great to have this for database migration scripts - my scenario is that I have a binary with an environment argument that I run - the exit code represents whether or not the database for that environment needs any database migrations performed (our database schema is in our codebase). If a migration is required, I want to ask the user if he is sure he wants to run the database migration script before continuing with the deployment process. Currently I can only fail my entire deployment if a database migration is required

  • dan clarke commented  ·   ·  Flag as inappropriate

    I've got 2 example scenarios where I think this could be quite handy in our implementation (hence it get's 2 votes from me :) )
    1. We have a manual step to set the credentials for any users added in the deployment in the variables (only our sys admins should know our credentials), it would be useful to have this step dependent on whether our deployment process created new users
    2. We have automated smoke tests, if they fail I'd like to be able to trigger a manual step to run the smoke tests manually, this way we can catch any false negatives that could occur

  • Dave Hahn commented  ·   ·  Flag as inappropriate

    Having the NuGet installation step prevent running ANYTHING if that version is already installed is a must. This is standard for any ARA product.

    With 73 votes what does this look like as far as getting on the roadmap and when?

  • Mike Burns commented  ·   ·  Flag as inappropriate

    A conditional manual step would be great to run if based on the environment - for example when deploying to production a manual step with a "Are you sure? Are you really really sure?" step would be great.

Feedback and Knowledge Base