Using octo.exe “5.2.6” and running the following command:
octo create-release --space="..." --project="...." --deployto="..." --version="...." --packageVersion="..." --server="...." --apiKey="..." --tenanttag="QA"
As you can see the tenant-tag is erroneous (it should have been --tenanttag=“Stage/QA” ). Instead of the exe-tool complaining right off the bat it instead creates the release only to complain afterwards ala:
Octopus Deploy Command Line Tool, version 5.2.6
Detected automation environment: "NoneOrUnknown"
Finding space:
[...]
Creating release...
Release 0001.00.00.00084-beta20190308160930 created successfully!
Octopus Server returned an error: Canonical Tag Name expected in the format of `TagSetName/TagName` <--------
Server exception:
Canonical Tag Name expected in the format of `TagSetName/TagName`
System.FormatException
at Octopus.Core.Model.TagSets.CanonicalTagName.<>c__DisplayClass12_0.<FromFormattedName>b__0(String name)
at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
at Octopus.Core.Features.Tags.CanonicalTagNameMapper.GetTagIdFromCanonicalTagName(String canonicalTagName)
at System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext()
at System.String.Join(String separator, IEnumerable`1 values)
at Octopus.Server.Web.Api.Rules.FilterTenantsByTagsRule.Customize[TModel](IQueryBuilder`1 query, ISpecialRuleContext context)
at Octopus.Server.Web.Infrastructure.Api.ListAllResponseDescriptor`2.Responder.<>c__DisplayClass4_0.<Execute>b__0(ISpecialRuleContext c, IQueryRule r)
at Octopus.Server.Web.Infrastructure.Api.Responder`1.ExecuteRules[TRule](Action`2 ruleCallback)
at Octopus.Server.Web.Infrastructure.Api.ListAllResponseDescriptor`2.Responder.Execute()
at Octopus.Server.Web.Infrastructure.Api.Responder`1.ExecuteRegistered()
at Octopus.Server.Web.Infrastructure.Api.Responder`1.Respond(TDescriptor options, NancyContext context)
at System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2)
at Octopus.Server.Web.Infrastructure.OctopusNancyModule.<>c__DisplayClass14_0.<get_Routes>b__1(Object x)
at Nancy.Routing.Route.<>c__DisplayClass4.<Wrap>b__3(Object parameters, CancellationToken context)
-----------------------
Error from Octopus Server (HTTP 500 InternalServerError)
Exit code: -7
Thanks for getting in touch. Sorry about any frustration this has caused you octo.exe is simple tool, it doesn’t validate any arguments. Part of the reason is a release is a separate concern, and a deployment must have an existing release in order to be created.
There’s currently no plans to extend the capabilities of octo.exe to report that it was called with the incorrect/invalid data in the arguments. It would be quite involved to make it bullet proof, example you could supply a valid tenant tag, but it may not match any tenants linked to that environment. The API of Octopus in general lets you supply data and reports on failure.
What possibly makes this feel more like a bug is that octo.exe is doing 2 distinct and isolated API calls for you, the nature of it the first is very likely to succeed but the latter has a lot of moving parts for success.
If you use the client APIs to first query valid data from Octopus server you can write code that uses only those values to ensure they are in the expected format as part of your call to octo.exe
If you use the client APIs to first query valid data from Octopus server you can write code that uses only those values to ensure they are in the expected format as part of your call to octo.exe
If end-users can write such custom logic then it would make sense to have such logic embedded in the program itself. Aka make 1 + 2 API calls where the first one is simply to healthcheck all parameters involved in the 2 subsequent calls. Just mentioning this to help you guys save face.
The bug in question is giving off the wrong image about how good octopus-deploy actually is. As devs we want the best tools for the job and such trivialities can landmine our efforts to promote your sales in our companies. Help us help you put some extra money in your pockets and some more faithful clients in your client-base. Just my 2c.
Thanks for the input and being a loyal customer. You do make a very good point Octopus is about high quality and best of class tools. So we can do better with some of these edge cases on octo.exe.
That’s also a very good point that if the logic to validate is straight forward we should just do it. I was thinking it may have some backwards compatibility issues, but customers in your position would more likely want the command to succeed completely than partially.
I’ve raised these details for an issue in our backlog, we can hopefully get something in place sometime soon.
Our customer’s 2 cents are always valued, keep them coming
Thank you for the prompt response. Looking forward to getting our hands on a version of the tools which has this issue resolved.
Keep up the good work.
Yours Sincerely,
Dominick Sidiropoulos
P.S.: For those coming across this thread, as an intermediate stop-gap solution (until this issue is fixed for good) you may employ the following technique in your build scripts: Issue your octo.exe command with the ‘–whatif’ flag first and only if that succeeds then proceed to issuing the same octo.exe command without the ‘–whatif’ flag this time
