Please stop brainlessly using AssemblyInformationalVersion in OctoPack

Legacy Uncategorised
1

Since the AssemblyInformationalVersion attribute can contain “any text”, it is often being used (by products such as GitVersion) to embed metadata such as commit hash that isn’t parseable as a System.Version number. If OctoPack encounters such an AssemblyInformationalVersion attribute, it dies a horrible death with the following error message:

[CreateOctoPackPackage] error OCTONUGET: '0.1.0-unstable.251+Branch.develop.Sha.b4c11b06ffd70484ee7efdf141dfb13f222bf00b' is not a valid version string.
[CreateOctoPackPackage] error OCTONUGET: Parameter name: version
[CreateOctoPackPackage] error OCT-1676060969: There was an error calling NuGet. Please see the output above for more details. Command line: 'D:\TeamCity\BuildAgent2\work\ae4444163a3860cf\packages\OctoPack.3.0.60\tools\NuGet.exe' pack "Redacted.Daemon.nuspec"  -NoPackageAnalysis -BasePath "D:\TeamCity\BuildAgent2\work\ae4444163a3860cf\src\Redacted" -OutputDirectory "D:\TeamCity\BuildAgent2\work\ae4444163a3860cf\src\Redacted\obj\octopacked" -Version 0.1.0-unstable.251+Branch.develop.Sha.b4c11b06ffd70484ee7efdf141dfb13f222bf00b
[CreateOctoPackPackage] error OCT-1676060969: System.Exception: There was an error calling NuGet. Please see the output above for more details. Command line: 'D:\TeamCity\BuildAgent2\work\ae4444163a3860cf\packages\OctoPack.3.0.60\tools\NuGet.exe' pack "D:\TeamCity\BuildAgent2\work\ae4444163a3860cf\src\Redacted\obj\octopacking\Redacted.nuspec"  -NoPackageAnalysis -BasePath "D:\TeamCity\BuildAgent2\work\ae4444163a3860cf\src\Redacted" -OutputDirectory "D:\TeamCity\BuildAgent2\work\ae4444163a3860cf\src\Redacted\obj\octopacked" -Version 0.1.0-unstable.251+Branch.develop.Sha.b4c11b06ffd70484ee7efdf141dfb13f222bf00b
   at OctoPack.Tasks.CreateOctoPackPackage.RunNuGet(String specFilePath, String octopacking, String octopacked, String projectDirectory) in y:\work\1f6ae101e1fcba62\source\OctoPack.Tasks\CreateOctoPackPackage.cs:line 588
   at OctoPack.Tasks.CreateOctoPackPackage.Execute() in y:\work\1f6ae101e1fcba62\source\OctoPack.Tasks\CreateOctoPackPackage.cs:line 194

This problem has been fixed in pull requests #69, #71 and #72, but none of them are merged or even so much as commented on by anyone related to Octopus Deploy. The oldest pull request is almost a year old now and is still causing us problems. Can you please review and merge them as soon as possible?

Thanks!

2

My company has a running enterprise license and we use Octopus Deploy for pretty much everything. I’d like to think that makes us a valued customer and that issues we encounter (and report!) get fixed.

That said: We’re still maintaining internal OctoPack forks and are not able to follow mainline simply because this issue[1] -still- persists, more than 6 months after the community provided a patch to fix it.

Let me repeat that: As an enterprise customer, we still have to maintain our own forks, to get basic things like package-versioning right.

I would appreciate it if these issues finally got resolved, or at least if we got some feedback on why our patches are not getting accepted. Clearly the Ocotpus community has a need here, and you’re not even willing to talk about it.

That’s simply not good communityship.

[1] https://github.com/OctopusDeploy/OctoPack/pull/71

3

+1.

Would love to see these PRs merged. They are over 8 months old now…

4

Jeg er på pappa-perm og vil mest sannsynligvis ikke sjekke epost før jeg er tilbake i slutten av Juli. Ta kontakt på telefon dersom det er viktig.

I’m on maternity leave and will most likely not be checking my email before I’m back at the office (end of July). If it is important: call me.

Telefon/Phone: +47 40203458

5

Hi,

Thanks for getting in touch and sorry for the long delay getting the PRs merged.

Unfortunately OctoPack tends to fall to the bottom of the priority list and doesn’t get the attention it needs from Octopus staff. I have merged PRs 69 and 71 and will review 72 as well as the other outstanding OctoPack PRs.

I will also discuss how we can manage OctoPack better so that issues are getting resolved and community contributions are given the respect that they deserve and we don’t end up in this situation again. Suggestions are welcome.

I am really sorry you’ve had to wait almost a year for these fixes, I hope we can make it up to you.

Cheers,
Shane

6

Shane,

Thanks for picking up on this so quick after it being reported here in the help forums! I do hope to see future pull requests merged faster. If you don’t have resources to do this with Octopus staff, one way of doing it would be to:

  1. Create a contribution guide with a set of rules that must be upheld for each pull request. Things like each code change having at least one test, having the test coverage above a certain %, not breaking (or rewriting) any existing tests, etc., are possible to have here.
  2. Set up continuous integration with a set of tests that ensure backwards compatibility so it’s much easier to contribute code and know it doesn’t break everything. The CI server and/or other tools can perform automatic checks for the contribution rules defined as well (such as code coverage).
  3. Appoint community managers that can do the groundwork on ensuring that all pull requests obey these rules and have them let Octopus staff know when a PR is ready for a final review and merge.

These are just ideas on the top of my head, but having a Travis and AppVeyor continuous integration pipeline would be something you should have in place anyway. It’s free and doesn’t take more than at most a few hours to set up. Just take a look at the .travis.yml and appveyor.yml in Pomona to get going and don’t hesitate to ask any questions. :slight_smile: