I’ve been chasing this for a few days. It appears that when I made changes to the Pre-deployment script (powershell) and save it, the newly changed script is not taking effect. It’s like the deployment is still running an old version of the script.
How can I see the ACTUAL powershell that is being run? I thought there was a setting to turn on more details in the output, but I don’t know where or what is is.
Hi Michael,
Thanks for reaching out. After you made the changes to your deployment process (when you updated the pre-deploy script), did you create a new release and then tried to deploy it? For the changes on your script to take effect, you need to create a brand new release and then deploy it.
Best regards,
Dalmiro
Yes, I always create a new release.
I think there’s an issue with one or both of the following:
Hi Michael,
Ok so the issue is not related to Pre-deployment scripts but to Step Templates. If you make the change to the step template and then manually update it on your deployment process without using Vanessa’s script, does it work as expected?
It would be really helpful if you could explain how your process works and what are your expectations vs what is actually happening.
Best regards
Dalmiro
RE your question: How can I see the ACTUAL powershell that is being run? I thought there was a setting to turn on more details in the output, but I don't know where or what is is. you can do that by following these steps:
Add these 2 variables to your project http://docs.octopusdeploy.com/display/OD/Debug+problems+with+Octopus+variables
Create a new release (so the new variables take effect) and deploy it.
Check the raw log of that deployment http://docs.octopusdeploy.com/display/OD/Get+the+raw+output+from+a+task .
Please also send this log to us.
The powershell pre-deployment script editor is flaky (I’ve noticed this for quite some time.)
The only process that reliably worked is:
So I hope your team can look at the editor.
Hi Michael,
On your first post you talk about pre-deployment scripts, then on the next one you mention step templates, and now back to pre-deployment scripts. I’m having a bit of a hard time trying to understand where are you exactly having this problem.
Could you send me screenshots of the screen where you are experiencing this issue?
Also please let us know which version of Octopus are you running. We had an issue a couple of versions ago where changes on the script editor were not being saved https://github.com/OctopusDeploy/Issues/issues/1974
Regards,
Dalmiro
Hi Dalmiro,
My first post is the main issue:
“I’ve been chasing this for a few days. It appears that when I made changes to the Pre-deployment script (powershell) and save it, the newly changed script is not taking effect. It’s like the deployment is still running an old version of the script.”
As I pointed out earlier, I’m not sure where the issue is – so I’m trying to debug OD (not my job) to figure out what is going on.
I’m running the very latest version of OD.
If you wish to try a skype call we can probably get there faster than with messages back and forth.
Michael
Hi Michael,
I’m gonna ask for a few things that will help me troubleshoot this:
Screenshots of where are you making the changes to the pre-deploy script.
Attach a text file with the script that you’d expect will be used in the deployment after your changes.
Follow the 3 steps on this other reply and send us the deployment log. http://help.octopusdeploy.com/discussions/problems/43728#comment_38848048
Regards,
Dalmiro
Hi Dalmiro,
Thanks for your note. Unfortunately we can’t spend any more time wrestling with the OD’s inline script editor. Suffice to say that I’ve been able to confirm, by examining raw output logs, that saved script changes do not reliably get picked up by the step(s) where used.
In the meantime, we need a working deployment, and thereore have decided to avoid the inline PS scripts altogether and instead embed them in the package, thus avoiding the inherent unreliability of the inline scripts.
We do prefer the inline scripts though, so if you get these issues fixed I’d like to hear about it.
Michael
Hi Michael,
I’m sorry but I’m still not sure how to reproduce this issue. If you’d like to have a call to walk me through it, please select a time on the link below.
https://calendly.com/dalmirogranias
Regards,
Dalmiro
Had the same issue as Michael W., made changes to a pre-deployment powershell script, created a new release and deployed, kept on erroring out and printing the line is the ps script I had changed. Commented out the entire line, created new release and deployed, same error showing the old script code. So followed Michael’s advice and deleted everything in the pre-deploy script and saved it, then copied in my changed script, saved it. Created new release and deployed, but got the same error!
Then on a whim I went to the Process and the step that was using that script, and I saw an orange-highlighted warning saying that something has changed and I needed to update the template to get the changes and viola! It worked. So to reiterate the issue with this bug: there is something wrong with the UI’s powershell editor where changes saved in the UI are not triggering a change within project templates so they use the old cached scripts.
Hi Paul,
Which version of Octopus are you running? Would you be able to schedule a call on the link below to show me step by step how to reproduce that error?
https://calendly.com/dalmirogranias
Thanks,
Dalmiro
We are using Octopus 2.6.5.1010. I scheduled a meeting on Wednesday at 11 AM MST. Thanks!
Hi Paul,
We fixed tons of things between 2.6.5 and the current version (3.3.4), and quite a few related to the Powershell script editors. The one that comes to my mind that might be bitting you is this one which we fixed in Octopus 3.2.4: https://github.com/OctopusDeploy/Issues/issues/1974
At this point the only thing left for you would be to upgrade Octopus to at least 3.2.4 to get a fix. I’m afraid there’s nothing that we’ll be able to do on a call to fix your issue on that old version. Sorry I went a bit ahead of myself when I told you to schedule a call. I should have asked for the Octopus version first.
Sorry for the crappy news
Regards,
Dalmiro
Paul -
We decided to avoid the inline PS scripts altogether and instead embed them in the package, thus avoiding the inherent unreliability of the inline scripts.
Actually, maintaining scripts outside of OD makes sense as they can be edited with IDE tools. We will eventially move all PS scripts to their own package to make maintenace easier.
Hope this helps.
Michael
No worries! We’ll be upgrading soon anyhow.
Except that it still may be broken in the current version.
Hi @Michael
Except that it still may be broken in the current version.
I’ve been testing this ever since we started this conversation, and it worked for me (and some of my teammates) all along. Yours was the only report of this being broken so far. Imagine that if this was widely broken, we’d be getting tons of reports about it.
I would be super interested in seeing the issue in action so I can give you a hand with it. If you’re up to it, we could have a call for you to show me this while sharing your screen. You can book a time on this link: https://calendly.com/dalmirogranias
Actually, maintaining scripts outside of OD makes sense as they can be edited with IDE tools. We will eventially move all PS scripts to their own package to make maintenace easier.
I totally agree with this one. Not because of the IDE, but because you can have the scripts on source control and properly versioned. I personally keep them on the same package as the app itself to avoid having to deal with 2 packages.
Regards,
Dalmiro
Dalmiro,
“Yours was the only report” – Honestly, it should not matter whether there’s 1 user or 1000, if it’s broken for any customers, it should be fixed. It’s also clear that at least two (myself and Paul) users are or were having the issue. Furthermore, others may be having the issue and not reporting.
Fact is, inline PS scripts were extremely buggy from the start.
At any rate, I’ve found a workaround and no it’s no longer an issue for my deployments.
Michael