Octopus CLI error when creating release - Value cannot be null. (Parameter 'source')

dgard1981 · 10 January 2023 15:44

Hi all,

I’m trying to create a release using the Octopus CLI version 9.1.7 (the current latest), but I’m hitting an error when using the following command.

dotnet-octo create-release --space Spaces-182 --project Projects-3884 --version 1.0.8-INF-2382.6-b1e2 --defaultPackageVersion 1.0.8-INF-2382.6-b1e2 --gitRef INF-2382 --ignoreExisting

To confirm…

The server URL and API key are provided via environment variables OCTOPUS_CLI_SERVER and OCTOPUS_CLI_API_KEY.
The GitHub branch INF-2382 exists.
The package at version 1.0.8-INF-2382.6-b1e2 required by the process exists and can be found when testing in Octopus.
The space Spaces-182 exists.
The project Projects-3884 exists.

When creating a release in the UI using the same GitHub branch and package version, everything works as expected.

Are you able to shed any light on the source of my issue?

The error

System.ArgumentNullException: Value cannot be null. (Parameter 'source')
   at System.Linq.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument)
   at System.Linq.Enumerable.Select[TSource,TResult](IEnumerable`1 source, Func`2 selector)
   at Octopus.Client.Exceptions.OctopusValidationException..ctor(Int32 httpStatusCode, String message, ICollection`1 errors)
   at CallSite.Target(Closure , CallSite , Type , Int32 , String , String[] , Object )
   at System.Dynamic.UpdateDelegates.UpdateAndExecute5[T0,T1,T2,T3,T4,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
   at Octopus.Client.Exceptions.OctopusExceptionFactory.CreateException(Int32 statusCode, String body)
   at Octopus.Client.Exceptions.OctopusExceptionFactory.CreateException(HttpResponseMessage response)
   at Octopus.Client.OctopusAsyncClient.DispatchRequest[TResponseResource](OctopusRequest request, Boolean readResponse, CancellationToken cancellationToken)
   at Octopus.Client.OctopusAsyncClient.Get[TResource](String path, Object pathParameters)
   at Octopus.Client.Repositories.Async.BasicRepository`1.Get(String idOrHref)
   at Octopus.Cli.Util.RepositoryExtensions.FindByNameOrIdOrFail[T,TResource](T repository, Func`2 findByNameFunc, String resourceTypeIdPrefix, String resourceTypeDisplayName, String nameOrId, String enclosingContextDescription, Boolean skipLog) in D:\a\OctopusCLI\OctopusCLI\source\Octopus.Cli\Util\RepositoryExtensions.cs:line 36
   at Octopus.Cli.Commands.ApiCommand.Execute(String[] commandLineArguments) in D:\a\OctopusCLI\OctopusCLI\source\Octopus.Cli\Commands\ApiCommand.cs:line 156
   at Octopus.Cli.CliProgram.Run(String[] args) in D:\a\OctopusCLI\OctopusCLI\source\Octopus.Cli\CliProgram.cs:line 47

Installation

This is how I installed the tool.

foo@bar:~$ dotnet tool search Octopus.DotNet.Cli
Package ID              Latest Version      Authors             Downloads      Verified
---------------------------------------------------------------------------------------
octopus.dotnet.cli      9.1.7               Octopus Deploy      2123756        x

foo@bar:~$ dotnet tool update --global Octopus.DotNet.Cli --version 9.1.7
Tool 'octopus.dotnet.cli' was reinstalled with the latest stable version (version '9.1.7').

Thanks,
David

sean.stanway · 10 January 2023 16:05

Hi @dgard1981

We’ve found in the past that sometimes the “‘source’ parameter is null” is a red herring, and instead, there is another issue at the heart of this.

I don’t see anything that jumps out at the moment in your actual CLI parameters. It all seems alright from what you’ve provided.

To test, would you mind directly passing in the URL and API key into your CLI call to see if there is any issue with the environment variables being read?

Kind Regards
Sean

dgard1981 · 10 January 2023 16:10

Hi Sean,

Thanks for your reply.

Even when unseting the environment variables for the server URL and API key, and instead passing them through the CLI, I’m seeing the same error.

Thanks
David

sean.stanway · 10 January 2023 16:38

Hi David,

Thanks for confirming that for me.

I see that you are a cloud customer, so I looked into our logging and found that there are quite a few errors being reported regarding Projects-3884 and Spaces-182. The main exception looks to be throwing Octopus.Core.Git.Schema.Exceptions.GitSchemaException: Branch has not been initialized.

I’ve noticed that this certain exception only gets thrown when we look for the schema_version.ocl is more than 0 to check if the branch has been successfully initialised, toggling a boolean we check to true. If this particular boolean isn’t true, then when we try migrating that branch onto our current schema, it will throw the above exception.

Would you be able to upload your OCL files for this particular project to this link I’ve generated here? It would be worth us looking through and seeing if there is anything out of the ordinary there.

Kind Regards
Sean

dgard1981 · 10 January 2023 16:52

Hi Sean,

I’ve uploaded all files as requested. Currently the schema version is at 5.

The branch 100% exists, though it wasn’t created by Octopus. When configuring the version control I selected main as the default branch, but because that is protected I instead committed to INF-2382. The UI is picking up the files just fine from that branch, but the files are NOT in the main branch yet.

Thanks,
David

sean.stanway · 10 January 2023 17:02

Hi David,

So you can see the files in the main branch, and since it’s protected, you push to the INF-2382 branch?

Am I also right in thinking that the main branch is still set up as the default branch for your version control settings? It might be worth changing this to the branch that contains the OCL files. I suspect this may be the issue. It could be that the CLI is trying to write to the default protected branch instead of going through to the INF- branch.

Would you mind giving that a try and seeing if this changes the outcome of your CLI command?

Kind Regards
Sean

dgard1981 · 10 January 2023 17:06

Hi Sean,

The files DO NOT exist in main.

Octopus offered me the choice of setting a default branch, which I set to main, but because it’s protected Octopus allowed me to initialise the project using another branch, so I chose INF-2382. That branch is the only one that has any files on it, and I’m not referencing main anywhere. It will be quite sometime until we are in a position to merge the feature branch into main.

Are you suggesting that as it’s the default branch, main also has to have these files? If that’s the case, how is it I am able to create a new release in the UI?

I have to go home now but I will re-read your reply tomorrow and do any testing that you have suggested.

Thanks,
David

sean.stanway · 10 January 2023 17:14

Hi David,

Sorry, I should have clarified. I meant that you could generally see files in main, but since it’s protected, all your files and OCL is set up for your INF-2382 branch.

In the UI, I assume that you have the correct branch selected, the INF-2382 branch, which is why you can create releases there. In the version control settings on the project, if the default branch is set to main, I gather this is where the problem with your CLI is coming in. We might be reading the default branch for initialising (which might be the main in this case), so it’s not initialising properly in the code and failing when trying to access the other branch you specified.

If this is the case, this might be a bug on our side with the CLI, where we are not initialising using the specified branch and instead using the project’s default. The test to change the default branch to the one containing the actual files will prove whether this might be the case.

I look forward to hearing back from you regarding this!
Kind Regards
Sean

dgard1981 · 11 January 2023 09:22

Hi Sean,

So you are correct that I am using INF-2382 in the UI, and that is working as expected.

However, even after changing the default branch to INF-2382 and removing any references to protected branches, the CLI create-release is still failing.

I assume the log where you found Octopus.Core.Git.Schema.Exceptions.GitSchemaException: Branch has not been initialized being thrown is consolidated Octopus logging, and not something we can view through our own Cloud instance?

Thanks,
David

dgard1981 · 11 January 2023 10:33

Hello again,

As this is a fairly simple project, I recreated it without CaC to allow me to crack on with my work, while still keeping the original project for us to investigate.

However, I’m now unable to create a release using the CLI in the new project. It’s failing with the exact same error.

I can’t see anything in the audit logs to indicate the issue, and as you say, the Value cannot be null. (Parameter 'source') error is a red-herring do to with a bug in the CLI’s exception handling.

I’m stumped as the CLI has been working without issue before yesterday.

Thanks,
David

sean.stanway · 11 January 2023 11:08

Hi David,.

Hmm. That is odd. I think I’ll need to loop in our CaC engineers and see if they can find what might be the issue here.

Do you mind if we log into your cloud instance to have a look this particular issue? We have access to the logs, but our engineers might want to have a look at the project itself.

Our engineers are based in Australia, so I might not be able to get an answer until tomorrow at the latest, just so you know.

Kind Regards
Sean

sean.stanway · 11 January 2023 11:16

Hi again David,

I was just thinking about what you mentioned regarding the CLI release working up until yesterday.

I checked and you haven’t had an update since December, so are you aware of any other changes either to your Git setup in Octopus or the repo itself?

Kind Regards
Sean

dgard1981 · 11 January 2023 11:37

Hi Sean,

Thankfully, problem solved!!

The issue was that someone in the team recently created a new Team for the Service Account that handles deployments to consolidate deployment/release permissions, but they didn’t include permissions for this space.

A fail on our part for not communicating that internally, but it would have been significantly easier to debug the issue if the exception handling on the CLI didn’t fail and obscure the underlying error. Hopefully that’ll be fixed in the next release.

Thanks for your help throughout,
David

sean.stanway · 11 January 2023 12:07

Hi David,

Glad to hear the you got to the bottom of it!

On cloud instances these errors get logged to our internal logging, but you can check the most recent errors in Configuration > Diagnostics.

I’ll mention the CLI obscuring the underlying error to our engineers who manage it and see if something can be done.

Have a good day!
Kind Regards

dgard1981 · 11 January 2023 12:10

Thanks Sean,

Unfortunately I don’t have the option for Configuration > Diagnostics (nor does anyone in the team). Not sure if it’s permissions related, but I am an admin so I would have thought I had all permissions.

Thanks,
David

sean.stanway · 11 January 2023 12:21

Hi David,

Apologies, I forgot this was restricted to Octopus staff only for cloud instances. The diagnostics page is available for on-premise, but that’s due to those instances storing their own files locally.

I’d recommend contacting us directly if an exception comes up in the future, either here or via support@octopus.com.

I’ve reached out to the team that manages the CLI to get an answer on the exception pass back in the meantime.

Kind Regards

dgard1981 · 11 January 2023 12:43

OK, understood. Thanks for your help.

system · 11 February 2023 12:43

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