Octopus Client Create Release NetStandard


(Chris Blyth) #1

When i use the Octopus Client to create a release using a .netcore application (therefore the netstandard version) i always get an error.

When using the netframework version, this works perfectly fine.

a small repo console app is:
using Octopus.Client;
using Octopus.Client.Model;
using System;

namespace OctopusRelease
{
    internal class Program
    {
        private static OctopusRepository client;
        private static readonly string OctopusUrl = "";
        private static readonly string OctopusKey = "API-";
        private static readonly string OctopusProject = "Chris Test";
        private static readonly string OctopusVersion = $"0.0.0.0-{Guid.NewGuid()}";
        private static readonly string OctopusChannel = "Default";
        private static void Main(string[] args)
        {
            client = new OctopusRepository(new OctopusServerEndpoint(OctopusUrl, OctopusKey));

            try
            {
                var octopusProject = client.Projects.FindOne(x => x.Name.Equals(OctopusProject));
                var channelId = client.Channels.FindByName(octopusProject, OctopusChannel).Id;
                client.Releases.Create(new ReleaseResource(OctopusVersion, octopusProject.Id, channelId));
            }
            catch (Exception e)
            {
                Console.WriteLine(e);
            }

            Console.ReadLine();
        }
    }
}

The error is get is “The resource ‘Releases-23542{’ was not found.” - different release number each time obviously.

I’ve done a bit of digging and can see that the client pulls the “location” header, which is always “/api/releases/Releases-23547{?ignoreChannelRules}” (again different release number each time)
It would appear that when using framework, the value in curly braces is removed, but when using the netstandard variation, the opening brace is still included.

I have created a PR on GitHub (https://github.com/OctopusDeploy/OctopusClients/pull/384) which is a workaround for this issue, but it’s in no way elegant :slight_smile:

Currently, this is preventing my application from working as i expect, and i’m having to catch the exception and assume that everything was ok…


(John Simons) #3

Hi Chris,

I am sorry that you are running into this issue, btw nice diagnoses of the issue, thank you, it did save me quite a bit of time.
So I have raised an issue that you can track in https://github.com/OctopusDeploy/Issues/issues/5282
I am taking a different approach to fix this, the real bug is that we should not be sending those invalid characters in the location header.
I am currently putting together a PR to fix this issue.

Once again thank you and thank you for submitting a PR too :slight_smile:

Regards
John


(John Simons) #4

Hi Chris,

Me again, just to let you know that a fix for this issue has just been released in v2019.1.6.

Cheers
John


(Chris Blyth) #5

Great, looks like i really need to get my backside in to gear and do the upgrade…we are currently on 2018.7.1 :frowning:


(system) closed #6

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