We are experiencing some deployment weirdness, where on some occasions a deployment process is failing on a particular step (a step template), and on other it’s working, but after a change to some other part of the deployment process.
For example, we have a failing deployment that states the following error. This deployment fails on step 1 (Check Variables 2) -
System.ArgumentNullException: Value cannot be null.
Parameter name: key
Now after deleting all subsequent steps (leaving only step 1, Check Variables 2) and creating a new release, the deployment is succeeding.
To the layman, it seems as though the failure is happening before the PowerShell script of the step Check Variables 2 (which is a step template) is run, but the error is not particularly human friendly. This theory is supported by the fact that there is no use of a parameter ‘key’ anywhere in the PowerShell script of the step.
How can we further debug what is going wrong here?
We’re happy to provide any further logs or information that you may require.
As part of our deployment process we must create a Deployment Target for the Function App. To achieve this, we have a step template that creates the Deployment Target based on a number of parameters, including the Target Roles.
In this case, a developer had used a replacement toke #{DeploymentTargetRoles} within the step template to specify the Target Roles, but had not added a variable called DeploymentTargetRoles. This meant that the Deployment Target was created with the role #{DeploymentTargetRoles}, and it was that which was causing the failure.
Simply deleting the erroneous Target Role #{DeploymentTargetRoles} fixed the issue.
Note: this process is only required because of the daft changes to Octopus from around 18 months ago, whereby we now have to deploy to a Deployment Target rather than being able to target a Functoin App from within the ‘Depoy a NuGet Package’ step).
So if any one from Octopus happens to read this -
Perhaps add some validation to the New-OctopusAzureWebAppTarget cmdlet to ensure that invalid Target Roles cannot be added.
Please make the error message a little more human friendly, so that it’s easier to track down the error.
Undo the daft changes from around 18 months ago, so that we don’t have hundreds of cloud Deployment Targets hanging around, making the place look untidy, and making life more difficult for anyone that creates an Octopus deployment .
Thanks for getting in touch. This is can be a bit of a catch with the step templates at the moment, in that it can be hard to see what their dependencies are when you’re consuming them. Using a parameter is one way to make this visible and not locked to a specific variable, but doesn’t always suit everyone’s purposes.
I’ve talked with the team and updating the error to be more meaningful is something being looked at.
As for the changes to the deployment target model, yes we understand they weren’t to everyone’s liking In case you hadn’t seen it, we did “revert” some of that, in that you can use a checkbox on the deployment steps to get them back in to the legacy mode and not use deployment targets.
.
In case you hadn’t seen it, we did “revert” some of that, in that you can use a checkbox on the deployment steps to get them back in to the legacy mode and not use deployment targets.