Variables not being replaced during second deployment

Legacy Uncategorised
1

Hello,

I’ve having an issue within Octopus where variables are not being replaced if a release is rolled when either it’s cancelled or stopped due to a failure, and redeployed…the deployment rolls successful each time. The variables are replaced just fine if the release is deployed once. The replacement is done via PowerShell and not within the package, but as a PowerShell script imbedded within the deployment step. We are suing Octopus version: 2.6.5.1010.

Anyone know if this is a known issue?

2

Hi Mike,

I don’t know if I am actually understanding the problem here. Could you provide examples of your variables, how they are being set?
What exactly do you mean by rolled? Could you also provide some deployment logs?

Thanks!
Vanessa

3

Sure, basically if we deploy a brand new release in dev, it will deploy fine. If we promote that same release to another environment like production, it deploys fine. But it there was a timeout during a deploy or if it was cancelled (for whatever reason), if we try to deploy that same release again, it seems that we get powershell script errors with our post deploy script (which we setup in the deploy step) stating that our variables are null. It looks to me like it the variable snapshot gets lost deploying the same release twice in the same environment.

I have included log files for a successful deployment and one with a failure deploying the same release a second time.

deploy_error.txt (37 KB)

deploy_success.txt (37 KB)

4

Any update?

5

Hi Mike,

Nothing is holding this up apart from my ability to replicate it. So I will have some code checked with some ideas I might have to see if there is anything obvious there. But I haven’t forgot and will get back to you as soon as I have any information.

Vanessa

6

Thanks for the info Vanessa. We have a production roll next week and need to get this fixed by then. I was curious if you had found any information yet?

7

Hi Mike,

Not so far. We had a pretty long talk about what could possibly even cause something like this. We have some maybe thoughts. As you are the only one currently able to replicate can we schedule a call to watch what happens and look at some data? Pick the earliest most convenient time for you and we will do a screenshare.

Before then could you also turn on our variable values, replicate the process, and send both logs to me from the cancelled task then the subsequent task.
http://docs.octopusdeploy.com/display/OD2/Debug+problems+with+Octopus+variables
http://docs.octopusdeploy.com/display/OD2/Get+the+raw+output+from+a+task

Vanessa

8

Thanks, would either today or tomorrow work? I can make anytime work for myself. I’ll need to get the proper approvals to deploy in effort to duplicate again. The logs I sent over is the same no matter how many times I run the deploy, but will duplicate once more.

So far it’s only with this one octopus deployment (that I’ve noticed so far).

9

Hi Mike,

Please select a time that works for you on the link below. The meeting will show up in our teams calendar and Vanessa (or someone else) will take it.

Regards,
Dalmiro

10

Thanks, much appreciated. It seems that the times available I’ll be either traveling home (2 hours away), asleep, or traveling to work. Are other times available? If not, anything you can check on your side?

I attached the logs with the variables OctopusPrintEvaluatedVariables & OctopusPrintVariables set to true via the article. It seems to me that the variables have issues when the deployment folder has the extra “_1” on the end once it deploys more than once.

FP_Variable_not_working_1-19-2016.txt (195 KB)

11

I think I might have a lead, although I’m not 100% this is it yet. But in the post deploy, we have a line that points to the web.config has follows:

$wwwroot = “E:\inetpub\wwwroot” + $OctopusParameters[“Octopus.Environment.Name”] + “” + $OctopusParameters[“Octopus.Action.Package.NuGetPackageId”] + “” + $OctopusParameters[“Octopus.Action.Package.NuGetPackageVersion”]

I think it may be trying to hit the website directory without the “_1” when it’s deployed twice via $OctopusParameters[“Octopus.Action.Package.NuGetPackageVersion”].

Do you know if this variable value takes into account for the “_01” when it’s deployed multiple times? If not, what would be the best variable to use?

12

Hi Mike,

We set our support hours very generously to try to fit in with yours, we take calls from 7pm-10pm at night and majority of our calls are done outside of business hours for us, so if they don’t match with yours we can keep trying to solve this via email.

But I do think you are on to something. We do need to change the deployment folder with each release. I am surprised you haven’t run into this before. None of the values you are using take the ‘_1’ into account. But we do have other variables that have this path that are already solved for you to use further in your deployment such as:

[Octopus.Action[***.internal.com].Output.Package.InstallationDirectoryPath] = 'E:\inetpub\wwwroot\DEV\***.internal.com\1.0.2696.0_1'
[Octopus.Action[***.internal.com].Output[server1].Package.InstallationDirectoryPath] = 'E:\inetpub\wwwroot\DEV\***.internal.com\1.0.2696.0_1'
[Octopus.Action[***.preview.com].Output.Package.InstallationDirectoryPath] = 'E:\inetpub\wwwroot\DEV\***.preview.com\1.0.2696.0_1'
[Octopus.Action[***.preview.com].Output[server1].Package.InstallationDirectoryPath] = 'E:\inetpub\wwwroot\DEV\***.preview.com\1.0.2696.0_1'

If you replace the use of where you need the path with the above (depending on scope) this should work well for you and be dynamic when you do have to release the same release more than once.

Let me know what you think.
Vanessa