Save entered runbook parameters to Project variables

Advice
1

Does anyone know if you can save entered runbook parameters to Project variables?

I have Project with a Runbook. When I run the Runbook I am prompted for various input parameters which are initialized to corresponding project variables. When I run the Runbook my entered parameters are used which is what I want. However they are not saved anywhere. I would like to be able to update the corresponding project variables if that is at all possible?

Thanks for your help
Paul

5

Hello Paul,

What you’re asking is certainly possible! Using a combination of output variables and the Save Octopus Output Variable library step template, you can designate an output variable from any step to be saved as the value of the project variable.

I was able to test this earlier using a runbook with a single prompted variable called VarMessage - I used this bit of PowerShell from the the link above to set the value to the current run:

Set-OctopusVariable -name "VarMessage" -value #{VarMessage}

In my test runs, I was able to validate that when I set the empty prompted variable to “Hello World”, when I looked at the project variables after, the value was set correctly. You’ll also still be prompted for a new value when you run the runbook again.

Note that this does require that your output variable name matches your prompted variable for the step template to properly write it out so it’ll show up for reuse.

Beyond that option, I’m interested in what you’re using these variable values for. Prompted variables offer the ability to provide default values - are some of your values changing more frequently than others?

Thanks,
Cory

6

Hi Cory,

Thanks for the response. I am not sure your solution solves my problem. I have more than one variable and the step where I use these parameters is a sql step.

My runbook prompts for 4 parameters. These parameters are using a sql script step to update records in a database. The user typically runs the runbook on the review environment then at some later stage when they have completed their testing, runs the runbook again targeting the production environment. When they do this they have to re-enter the 4 parameters. I would like to be able to either save these prompted parameters to their corresponding variables or alternatively save these variables in the review snapshot so I can re-use them.

Are any of these approaches possible or is there another way I could achieve the same thing?

Thanks for your help
Paul

7

Thanks for the additional clarification Paul, sorry my initial recommendation wasn’t much help.

The user typically runs the runbook on the review environment then at some later stage when they have completed their testing, runs the runbook again targeting the production environment

With the process you’re describing, I don’t think runbooks are a great fit currently. The nature of runbooks is intentionally split from the lifecycle/environment pipeline, so promoting database scripts through the environments that way is why there’s so much friction when trying to use the runbooks.

That said, there are a couple of options -

  1. Are there specific benefits you’re getting from runbooks that you wouldn’t get from a traditional deployment project? That would be the easiest/most natural transition for the process at this point. You should be able to keep those variables better aligned and visualize the promotion through each environment.

  2. Beyond that, there’s a blog from last year specifically around handling ad hoc database scripts with some other good options for working with the workflow you’re describing.

Let me know if either of those help - if runbooks are a requirement, I think you’ll need to look at the very least at using a referenced package with that data instead of the prompted variables. Hopefully one of those can provide some lift, happy to keep working with you on this if you need more help!

Thanks,
Cory

8

Hi Cory,

Thanks for your help. I used the info from the blog link you posted and developed a similar process that solves the problem.

Thanks
Paul

9

I’m glad to hear it Paul!

Let me know if there’s anything else I can help with.

-Cory