The variable-creation UI allows users to create variables that include invalid characters (aka anything else other than A-Za-z0-9:_). Being allowed to create variables such ‘Foo.bar.something’ (for the sake of “namespacing” vars) results in cryptic errors upon actual deployment in the sense that the #{Foo.bar.something} bit doesn’t get replaced.
Just our 2c.
Hi @Dominick_Sidiropoulos, thanks for reaching out.
Variables like Foo.bar are supported, so if you are seeing errors then that is possibly a bug. What version of Octopus are you using?
Also can you supply the logs that show the errors that you are referring to after enabling variable debugging?
Varibale debugging is documented at https://octopus.com/docs/support/debug-problems-with-octopus-variables#DebugproblemswithOctopusvariables-Writethevariablestothedeploymentlog, and by setting OctopusPrintVariables and OctopusPrintEvaluatedVariables to True we can see what values Octopus has assigned to the variables in the project.
https://octopus.com/docs/support/get-the-raw-output-from-a-task documents how to get the raw logs for a task.
Regards
Matt C
Thank you for the prompt response.
We are using 2019.1.6 locally installed in one of our in-house machines (Windows 10 fully updated). As you can see below we use ‘#{vNext.Backend.PackageID}’ to define the package we want. We have made sure to also set ‘OctopusPrintVariables=true’ and ‘OctopusPrintEvaluatedVariables=true’ for the QA environment. The package cannot be found when we use the dot ‘.’ notation for variables:
Task ID: ServerTasks-240
Task status: Failed
Task queued: Παρασκευή, 22 Φεβρουαρίου 2019 12:15:25 μμ
Task started: Παρασκευή, 22 Φεβρουαρίου 2019 12:15:26 μμ
Task completed: Παρασκευή, 22 Φεβρουαρίου 2019 12:15:26 μμ
Task duration: less than a second
Server version: 2019.1.6+Branch.tags-2019.1.6.Sha.1e1809ae886e8a9649933e85f78daf3c09eebdab
Server node: GRDO211NSG2
| == Failed: Deploy vNext.Backend release 1.0.0 to QA for vNext.Backend.Monolithic.Internal.QA.Oracle ==
12:15:26 Verbose | Guided failure is not enabled for this task
12:15:26 Fatal | The deployment failed because one or more steps failed. Please see the deployment log for details.
|
| == Failed: Acquire packages ==
12:15:26 Info | Acquiring packages
12:15:26 Info | Making a list of packages to acquire
12:15:26 Verbose | An operation in "Acquire Packages" failed
| The package '#{vNext.Backend.PackageID}' is required by 'vNext.Backend', but no version has been specified.
| Octopus.Shared.ControlledFailureException: The package '#{vNext.Backend.PackageID}' is required by 'vNext.Backend', but no version has been specified.
| at Octopus.Server.Orchestration.ServerTasks.Deploy.Steps.Acquire.RequiredPackageListBuilder.GetVersion(PackageReference packageReference, IImmutableVariableDictionary actionVariables, IFeed feed, String actionName)
| at Octopus.Server.Orchestration.ServerTasks.Deploy.Steps.Acquire.RequiredPackageListBuilder.<GetRequiredPackages>d__6.MoveNext()
| at System.Linq.Enumerable.<SelectManyIterator>d__23`3.MoveNext()
| at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
| at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
| at Octopus.Server.Orchestration.ServerTasks.Deploy.Steps.Acquire.AcquisitionTaskPlanner.<PlanTasks>d__11.MoveNext()
| at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
| at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
| at Octopus.Server.Orchestration.ServerTasks.Deploy.DeploymentTaskController.AcquirePackages(PlannedStep step)
| at Octopus.Server.Orchestration.ServerTasks.Deploy.DeploymentTaskController.DispatchStep(PlannedStep step)
| Octopus.Server version 2019.1.6 (2019.1.6+Branch.tags-2019.1.6.Sha.1e1809ae886e8a9649933e85f78daf3c09eebdab)
12:15:26 Fatal | The step failed: The package '#{vNext.Backend.PackageID}' is required by 'vNext.Backend', but no version has been specified.
12:15:26 Verbose | Acquire Packages completed
|
| == Skipped: Step 1: vNext.Backend ==
12:15:26 Info | Step "vNext.Backend" runs only when all previous steps succeeded; skipping
|
The snapshot of the variables for the release in question are shown here:
This problem went away the moment we switched from using ‘.’ to using ‘::’ everywhere. Hope these pieces of information help.
Hi @Dominick_Sidiropoulos, thanks for that info. We’ll look to create a test case to reproduce the issue. But it sounds like you have a suitable workaround in the meantime.
Regards
Matt C
Mr Casperson,
Thank you for the prompt response for taking the time to look into it. If you can’t reproduce this issue easily, I’m always at your disposal to help you track this issue down as soon as possible.
Thank you and be safe.
Yours Sincerely,
Dominick Sidiropoulos
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
