We are considering using ScriptCS for Script steps in our Runbooks. We would like to develop them locally and then generate packages when we check-in. Do you have any advice on how to best test these scripts on our local machines? How can we use the Octopus.XXXX functions on our locals while testing?
Hi Mike, thanks for reaching out. This is a great question and your idea about packaging your scripts so you can version control them is good practice. Let me do a little research on my end and see what the most appropriate way to test these things. I’ll get back to you as soon as I can.
Thanks for your patience!
Phil
Hi again Mike,
I did a little research and spoke to some colleagues on this. In my experience, it’s usually easier to “test” your scripts just in your Octopus instance itself. You can setup a separate project or runbook or something that doesn’t interfere with other projects - or you can use the Script Console: Script Console - Octopus Deploy
The challenge with trying to simulate the Octopus environment is just that there is some context that Octopus builds up before actually running your script. Octopus bundles variables, packages, script modules, and anything else required to run your scripts and sends that to the Tentacle before actually running it. What actually bootstraps your script and runs it is our open source Calamari software. If you were interested and motivated, you could read some of the Calamari source and figure out how to run it locally and simulate what Octopus does. There is a section here in our docs with more info: Custom scripts - Octopus Deploy. Unfortunately the Calamari.exe CLI is not super friendly like Octopus.exe or Tentacle.exe.
Hope this helps. Cheers,
Phil
Hi Phil,
Thank you for your advice. Is there a way to restore packages before the script executes, or should we bundle the scriptcs_packages folder?
Thanks,
Mike
Hi Mike,
I’m pretty sure you can restore packages before your script executes. There are some lifecycle hooks that you can use for these Run a Script steps in Octopus that allow you to define behavior before (and after) your script runs. Check our documentation on Package deployment feature ordering. You can even include files in your package with pre-defined conventions that Octopus will automatically use: Scripts in packages - Octopus Deploy
Hope this works for you,
Phil
Thank you for your help Phil.
Are there any plans to update the C# scripting engine? ScriptCS hasn’t been updated in 4 years and it’s nuget package support no longer works. I am running into problems using some 3rd party libraries because of how old it is.
Mike
Hi Mike,
Bundling tools with Octopus Server has been a double edged sword for us. When we first began including the built in tools it was great because it made using these tools inside Octopus a seamless experience, but then when we went to go upgrade some of the built in tools, inevitably some of them went through breaking changes and this broke some customers while others wanted the latest. In the end, we’ve sort of stopped updating built in tools like this and have developed other features that give users the ability to customize their environments.
We’ve developed support for Docker, and also allow you to use container images as the basis of your steps via Execution Containers. This is is basically the path we’ve been suggesting for users that want the latest tools or have unique requirements for their environments.
Thanks,
Phil
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.