After a recent upgrade to version 2020.4.2, I have a deployment using an Azure Script that no longer works.
It references a script in a package called deploy.ps1, with some additional script parameters:
-Domain #{Domain} -Action #{Action}
When applying the OctopusPrintEvaluatedVariables and OctopusPrintVariables, I can see that my variables for #{Domain} and #{Action} are picked up and available during deployment.
Looking at a previous successful deployment before the upgrade, I can see an entry in the logs of:
Invoking target script “C:\Octopus\Work\20200827132655-157428-50587\deploy.ps1” with -Domain NewGen -Action Apply parameters
But with the recent failed attempts I get:
Invoking target script C:\Octopus\Work\20201006160713-169846-29073\staging\deploy.ps1 with parameters
I’ve gone through the settings and it all seems correct, plus I’ve not made any changes to this step, so wondering if there is a bug that’s been introduced with the recent version? If there is any other information I should provide, please advise.
Thanks for reaching out and the great detail on the issue.
Would you be able to privately message me the info I would need to reproduce the issue?
I would need screenshots (or the JSON) of the step causing the issue, and ideally the referenced script package as well. Also any other variables referenced that are used other than NewGen and Apply parameters.
For anyone else happening upon this thread with the same issue, the workaround is to rename the script file to something that isn’t deploy, predeploy, or postdeploy.
Please let me know if you have any other questions or concerns and I hope you have a great weekend.
Could you provide a bit more info on the intended behavior of the Deploy.ps1, etc. scripts in an Azure app service deploy?
We include a custom Deploy.ps1 in our packages for on-premise deploys. When we tried deploying the same package to an Azure app service (using Octopus Deploy 2020.3.4), it tried to run our Deploy.ps1 which obviously failed to upload the stuff to the app service.
Are you saying the intended behavior is that Azure deploys will ignore the custom Deploy.ps1 script, so once the issue is resolved we could use the same package for both on-premise (with our custom script) and Azure (with the default Octopus script)?
I spoke with the engineer working on the issue and we want to make sure it’s the same issue here. Would you be able to privately message me a failed task log with the behavior you’re seeing? Could we also get a deployment process JSON? To get this go to the Project, then the process section, then click the 3 dots to the right of add step and click download JSON.
Please let me know if you have any questions about the above.
I spoke with the engineer doing the fix and he said that what you’re seeing is by design and not part of the bug. However, you should be able to disable that script from running in the webapp step by creating the variable and value Octopus.Action.Package.RunScripts = false . If they are within the same deployment, you will need to scope this variable to the step where you want to disable the packaged deploy.ps1 from running.
Thanks! I had thought it was by design, hence my original question about what exactly the bug here was. It looks like that variable looks like it does the trick. I’ll have to look at the scoping options, but hopefully that will let us simplify our packaging process.
It looks like that variable looks like it does the trick. I’ll have to look at the scoping options, but hopefully that will let us simplify our packaging process.