$OctopusParameters is a NULL array

Octopus Server
, ,
1

I have a project with several Bash script steps and a very large number of variables.
Some of these variables are sensitive and all of them have multiple scopes.
I cloned this project to a new project that needed the same variables but will target Windows tentacles with a different process.
So I’m replacing the BASH script steps with PowerShell script steps.

The BASH script steps resolved variables using the #{varname} syntax.

In the new project, I am trying to use the $OctopusParameters[‘varname’] syntax for resolving variables.
When I run the new project, the first script step fails with the following output (sensitive info redacted) …

Cannot index into a null array.
At E:\Octopus\Work\20220324125607-332588-366\Bootstrap.ps1:20 char:1

  • $tempVar = $OctopusParameters[’********’]
  •   + CategoryInfo          : InvalidOperation: (:) [], ParentContainsErrorRecordException 
  + FullyQualifiedErrorId : NullArray

The remote script failed with exit code 1
The action ******** on ******** failed

Through some experimentation, I confirmed that $OctopusParameters is, in fact, NULL
When adding this line …
Write-Host “Octopus Parameters array is null: $($OctopusParameters -eq $Null)”
to the script, it outputs:
Octopus Parameters array is null: True

I have also confirmed this happens whether I run the script on a tentacle or on the Octopus Server.
Plus, I have also confirmed that the #{varname} syntax still resolves the variables properly.

I can use the #{varname} syntax, but for some of my scripts the $OctopusParameters[‘varname’] syntax would be more convenient.

Note: My organization is running Octopus v2020.3.2
I see no reference to a bug fix for this between that version and the latest version (https://octopus.com/downloads/compare?from=2020.3.2&to=2022.1.2121)

Can anyone tell me why $OctopusParameters would be a null array?
Is this an intentional “feature” and if so, why?
Thank you.

3

Hi @blusen-ip,

Thanks for reaching out and welcome to our community forums!

I’m currently in the process of reproducing what you’ve reported and I will let you know as soon as I have an update for you.

In the meantime, feel free to reach out with any questions or concerns and I’ll do my best to get back to you.

Kind Regards,
Adam

4

Hi @blusen-ip,

Thanks for being patient while I looked into this, I have a quick question if that’s alright?
What variable type (string, sensitive, account, output) was the variable in question when you received the null array error upon applying it to a PowerShell variable?

For regular project variables, you can reference the variable as a regular PowerShell variable using the name, for instance, if I have a variable with name “myVar” and value “myVal”, the following commands will work within Octopus:

> $reassignedVar = $myVar
> write-host $reassignedVar
myVal

For Output variables you can reference them using $OctopusParameters[Octopus.Action[STEP NAME].Output.VARNAME], with the step name being the step where the Output variable was created.

I wasn’t able to get $OctopusParameters to evaluate as null in the most recent version of Octopus but I’m happy to spin up a version of Octopus that’s the same as yours and try it.

Out of curiosity, can you please run the following inside a project to see what the results are:

$OctopusParameters -eq $null

foreach($item in $OctopusParameters){
    write-host $item
    }

write-host $OctopusParameters

$OctopusParameters.GetType();

My results looked like the following, even with no variables on the project:

False 
System.Collections.Generic.Dictionary`2[System.String,System.String] 
System.Collections.Generic.Dictionary`2[System.String,System.String] 
IsPublic IsSerial Name                                     BaseType                                                     
-------- -------- ----                                     --------                                                     
True     True     Dictionary`2                             System.Object

Let me know what you think of the above, please, and if you’re able to get any further. In the meantime I’ll work on spinning up an older instance of Octopus to test this on.

Kind Regards,
Adam

5

Hi @adam.hollow,
Thank you for working on this.

The variable for which I got the original error was a simple string type.
However the variable is irrelevant as the array itself was $Null.

I understand I can access single variables in various ways, but I would like to iterate over $OctopusParameters.Keys and since ($OctopusParameters -eq $Null) is True the Keys property is not valid.

Another point of note … I have been unable to reproduce this issue in other projects that I have created from scratch. This issue only seems to arise when the project I am working on was cloned from another.

I will execute your script, but as I mentioned in my initial post I already did the ($OctopusParameters -eq $Null) test and it was True

Script line: Write-Host “Octopus Parameters array is null: $($OctopusParameters -eq $Null)”
outputs: Octopus Parameters array is null: True

I will reply again with the output of your script from my cloned project.

6

Hi @adam.hollow,
Thanks again for looking at this.
I implemented your script as it’s own step and executed only that step.
Here is the output (with sensitive information redacted):

                |   == Failed: Step 2: Test Script ==

13:22:59 Fatal | The step failed: Activity Test Script on the Octopus Server failed with error ‘The remote script failed with exit code 1’.
13:22:59 Verbose | Test Script completed
|
| == Failed: Octopus Server ==
13:22:59 Verbose | Octopus Server version: 2020.3.2+Branch.tags-2020.3.2.Sha.0d64b33d41be33a511fe1fab38f207d2348460d4
13:22:59 Verbose | Environment Information:
| IsRunningInContainer: False
| OperatingSystem: Microsoft Windows 6.3.9600
| OsBitVersion: x64
| Is64BitProcess: True
| CurrentUser: *
| MachineName: ********
| ProcessorCount: 8
| CurrentDirectory: C:\Windows\system32
| TempDirectory: C:\Users*\AppData\Local\Temp
| HostProcessName: Octopus.Server
| PID: 15976
13:22:59 Verbose | Executing Test Script (type Run a Script) on Octopus Server
13:22:59 Verbose | Running this script in the Octopus Server security context (*)
13:22:59 Verbose | Starting C:\Windows\system32\WindowsPowershell\v1.0\PowerShell.exe in working directory ‘E:\Octopus\Work\20220324172259-332666-34466’ using ‘OEM United States’ encoding running as '***’ with the same environment variables as the launching process
13:22:59 Info | True
13:22:59 Error | You cannot call a method on a null-valued expression.
13:22:59 Error | At E:\Octopus\Work\20220324172259-332666-34466\Bootstrap.ps1:9 char:1
13:22:59 Error | + $OctopusParameters.GetType();
13:22:59 Error | + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
13:22:59 Error | + CategoryInfo : InvalidOperation: (:slight_smile: [], ParentContainsErrorRecordException
13:22:59 Error | + FullyQualifiedErrorId : InvokeMethodOnNull
13:22:59 Verbose | Process C:\Windows\system32\WindowsPowershell\v1.0\PowerShell.exe in E:\Octopus\Work\20220324172259-332666-34466 exited with code 1
13:22:59 Verbose | Updating manifest with output variables
13:22:59 Verbose | Updating manifest with action evaluated variables
13:22:59 Fatal | The remote script failed with exit code 1
13:22:59 Fatal | The action Test Script on the Octopus Server failed

7

Hi Bill,

Thank you for following up with that additional information. I’ll jump in here quickly as Adam is now offline as part of our UK-based team. :slight_smile:

I attempted to reproduce this myself, though it is possible I over-simplified it a bit in my attempt. I created a sensitive variable, tested a deployment of it, Octopus Parameters array was not null, cloned the project and attempted the same with the exact same result. My guess is it is tied to the fact that the project was cloned as you’ve noticed, whereas others were not.

Is it possible that the cloned project was created using a different lifecycle, causing the scoping in your variables to break? Perhaps it’s deploying to a new environment in which you didn’t originally scope a variable to in the source project?

If the scoping still lines up in the cloned project, I’m then curious if re-creating any of these variables show up? E.g. is it only old variables created in the source project, or is this same issue happening on new variables created in the clone?

From here, it might be worth enabling debugging variables in your project, deploying again and sending the resulting task log for us to have a deeper look into.

I look forward to getting to the bottom of this one!

Best regards,

Kenny

8

@Kenneth_Bates
Thank you Kenny for digging further.

Yes, the original project’s lifecycle was different than the new project’s lifecycle.
The original project’s lifecycle targeted environments using LINUX boxes.
The new project’s lifecycle targets environments using Windows machines and the environments are named differently.

The variable scopes, therefore, were significantly different, including some channel scopes.
The first thing I did after cloning the new project was to
1. Remove all custom channels and only keep a single Default channel (lifecycle inherited from parent)
2. Review the entire list of variables and change their scopes to match the new lifecycle.
- I removed ALL channel scoping
- I only scoped variables to environments that are valid for the new lifecycle
Note: neither the original project nor the cloned one uses any Variable Sets - these are all project variables
It wasn’t until after all variable scopes were fixed that I created the first PowerShell script step.

I think it’s important to re-iterate this point: using the #{varName} syntax works successfully for the new PowerShell scripts.
The variables named within this syntax resolve correctly to the expected values.
It is only the $OctopusParameters array that is not working.

I will attempt to get some time today to turn on variable debugging and get a new task log for you.
Thanks again.

1 Like
9

@Kenneth_Bates, @adam.hollow
Kenny & Adam,
Thank you again for looking into this.
I set both project variables (OctopusPrintVariables, OctopusPrintEvaluatedVariables) to True and re-executed the test script step that Adam gave me.
The results were the same as before. I have attached the exported log (with sensitive credentials redacted).
Thanks.
ServerTasks-333074.log (3.4 KB)

10

Hi @blusen-ip,

Thanks for the new task log. It doesn’t look like the variable evaluation shed very much light on this behavior.

I am wondering if it would be possible to get a copy of this project via Migrator before and after cloning?

A few notes if you feel comfortable doing this:

  • The export will include sensitive variables
  • Every Partial-export run will overwrite the previous, so you will have to either specify separate directories or save and move the folder each time.
  • You can use all of the --ignore flags e.g. --ignore-history as we should not need any of that information for repro.

The reason we’re asking for the export in this manner is to get a proper reproduction done so that we can pass this off to the developers. Ideally, we’d be able to get this figured out ourselves, but unfortunately in this case everything we’ve tried has not allowed us to duplicate the behavior you’re seeing.

I’ve created a secure upload link for you here to use for uploading so you don’t have to post your Project export in the public help channel. This link will be only usable by your email and this comes directly to Octopus: Support - Octopus Deploy

If you don’t want to do the project export, please let us know. But right now, unfortunately, the only solution we can think of is to rebuild the project from scratch.

Regards,
Garrett

11

Hi @garrett.dass

Unfortunately, I do not have access to our Octopus server. Plus, the policy of my organization won’t let me export the IP of our sensitive variables.

I am attempting to scrub another cloned version of the project that still reproduces the issue. If I am successful, I will be able to request of my IT Ops staff to export the scrubbed project. I will reply again once I have more information.

Thank you.

12

Hi @garrett.dass, @Kenneth_Bates, @adam.hollow,

I have reproduced the issue with a very simply newly-created project.

STEPS TO REPRODUCE:

  1. Create a new project (e.g. named “Test OctopusParameters”)
    • default all other fields including Lifecycle (any lifecycle will do)
  2. In the project, create a single STRING variable. For example:
    • Name: MyVariable
    • Value: Any Value
  3. Add the following second string variable:
    • Name: OctopusUseNakedScript
    • Value: True
  4. Edit the Process and create a single SCRIPT step
    • Choose POWERSHELL
    • enter the script provided by Adam earlier in this conversation
  5. Create a release and execute to any environment

This will show that $OctopusParameters is a NULL array when OctopusUseNakedScript=True

I cannot find any documentation for this option other than here: Support a step to access deployment packages without unpacking them · Issue #2770 · OctopusDeploy/Issues · GitHub

Thank you for looking into this.

13

Hey Bill,

Thanks for getting back to us with those detailed steps to reproduce the issue! I’ve tested this on my end and can confirm the behavior is the same.

After some discussion with my colleagues, it turns out OctopusUseNakedScript is a legacy system variable that has been replaced by OctopusUseRawScript. You might already know, but this variable is used to deploy to SSH targets where Mono (and therefore Calamari) is not installed, and you can find more information on these types of deployments here: Raw scripting - Octopus Deploy.

I know you mentioned variable scoping earlier, so I was wondering if you perhaps have past SSH targets in an environment this variable was scoped to? If so and you’ve changed to deploying to an environment without SSH targets, that might explain the behavior here.

Let me know what you think, or if you have further questions.

Best,
Patrick

14

@patrick.smergut
Yes, the original project (from which this new project was cloned) was targeting LINUX machines that were not using Mono. I have removed the OctopusUseNakedScript variable and am now good to go.

Academically, I am surprised that this variable, that targets SSH, isn’t ignored by PowerShell script running on the Octopus server. I can imagine if I added a step to the original project that ran PowerShell on the Octopus Server that I would expect it should still support the documented PowerShell constructs.

In practicality, I am now unblocked and can resume authoring my new script steps in the cloned project.

Thank you all for your help.

1 Like
16

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.