Library variables usage from Script Console
Currently (2.6.x) its not possible to use Octopus variables from the Script Console. It makes sense that Project variables cannot be used from the SC, but variables from Library Sets might be a good idea.
Josh Jones commented
I think this would be great, but I could see it being a bit of a pain to secure too. Maybe include a security setting where we can control who can use library sets through the script console. (Maybe even allow us to choose which library sets can be used through the console?) This could be very helpful in testing scripts.
Would be great to use this to push out new secrets / passwords when necessary. I'd want to use variables to keep the values hidden.
This feature is the only thing missing in my life...
I would use this feature regularly!
My scenario where this would help is debugging a powershell script to change the name of an IIS binding - it's losing the SSL certificate in the process. I think I need to change the script to re-apply the SSL certificate, but I do not know what the certificate variable in Octopus contains so I was trying to do this from the script console:
$cert = $OctopusParameters["Alphatec.SSL.Certificate"]
Write-Host "Certificate [$cert]"
(Alphatec.SSl.Certificate is a certificate variable in a library variable set).
Will Parry commented
This would be really useful to run a test after adding sensitive variables or later on to confirm the values are correct by run a test process, using runas or something from PowerShell to validate the credential username and password are correct. Thanks.
B Au commented
Useful when your need to test new/amended development process.
Bronwyn Andrews commented
I'm finding more and more scenarios where this would be really REALLY useful!
If there was an optional 'Include Variable Sets' for script console tasks - the way there is for individual projects - this would be extremely efficient for Project building, allowing many scripts to be tested and verified, prior to wrapping them into a full Project > creating a release > deploying etc - before you can see if something worked out or not.
Would make this super-cool product - even better! :)
Why not have a project dropdown to select the variables you want?
This would be a feature I use when I'm debugging scripts in a rapid re-iterative process.
Its a pain to have to deploy the whole thing every time just to iterate through some weird powershell issue you might be having...
CHRISTMAS IS RUINED!
Mark Evans commented
1. Testing scripts.
2. Manually running scripts on certain targets / tentacles.
Would be very handy to choose a project, then choose a build, then choose a target / environment and then it gets you all setup so you can run scripts, test variables, debug etc.
Currently every time i need to test a script, i have to create a new release 1.0.200.004, 1.0.200.005 etc.
I'd much rather define the setup and then say reload libs and vars.
Mark Evans commented
Would really love to be able to see my variables here. Triggering new builds just to retry a new script is painful.
Gary Carr commented
I use the script console to run lots of powershell scripts against a list of machines, It would be very cool to for example to run this successfully :
$serverName = $OctopusParameters["Octopus.Machine.Name"] + ".domain.com"
Write-Host "Listing Certificates for $serverName"
Get-ChildItem -Path cert: -DnsName $serverName
Andrew M commented
This would be useful for us.
When scripts are run against an enviornment/role combination, we would also need the environment (where applicable) as that is sometimes used in the Library variable sets.
eg, we have a Library variable something like: