Octopus 3.12.4 won't download many library packages

Legacy Execution
1

Even though I uploaded some packages just last night, and did a release from others 2 days ago, Octopus 3.12.4 is being a stubborn lil’ thing and telling me messages such as

{
“ErrorMessage”: “The package DataWarehouse.1-PRConfiguration-2017.9.895.1159 was not found in the index of the built-in package repository”
}

I found all the packages in the list and it was happy to deploy from some of the affected packages, so, what gives? Some packages are fine, others not so. I know my retention period is small (5 days) for non-released packages, but right now I can’t download a package I uploaded yesterday!

In addition, some files show the summary when I click on them, but will not download, others there’s no summary and also will not download.

For those without a summary, clicking on the larger “Download” button simply takes me back to the ~app#/ part of the Server URI.

The files seem to be visible in the PackageCache folder (from what I can tell).

All of these were uploaded to Octopus’s feed so I’m well puzzled as to what’s going on.

2

Hi Rachel,

Thanks for getting in touch. It sounds like there is a problem matching packages to their use in releases.

I suspect it is due to your versioning scheme and the way we compare package filenames not lining up. In the example package name you sent, the version is 1 and the patch version is PRConfiguration-2017.9.895.1159. Note that we fixes an issue like this in 3.12.3, so it might be related or a regression. Was this occurring before you upgraded?

To help me get to the bottom of this, could you please send me:

  • The listing from the internal nuget feed, marking some of those that will and won’t download
  • A screenshot of the release details page, showing the package version numbers, for a release that has missing packages
  • The task log of the last 3 days worth of Apply retention policies tasks (Task list, filter by Retention)
  • A listing of the relevant <octopushome>\Package (eg DataWarehouse) folder

Even though the package is in the PackageCache, we still look for it in the feed (Package folder) to ensure it has exactly the same hash.

If these details are private, you can mark this conversation as private on the right hand side.

Robert W

3

Just noticed something (with Monday morning eyes) - I never uploaded a package with that exact name!

For example, another troublesome package which I uploaded Friday was named PRWarehouse-1-PRConfiguration.1.1.2-Dev1180. However, if I try to download it, it looks for PRWarehouse.1-PRConfiguration-1.1.2-Dev1180,

Notice how Somehow the first dash got changed to a period (full stop)!

Here’s the output from TFS Build confirming this:

2017-04-21T23:54:29.6017764Z Publish-DlmDatabasePackage, DLM Automation 2.0.6.240, Copyright c Red Gate Software Ltd 2014-2017
2017-04-21T23:54:29.6174031Z Path: E:\TfsBuild\Agents\DW#1\_work\5\s\PRWarehouse-1-PRConfiguration.1.1.2-Dev1180.nupkg
2017-04-21T23:54:29.6174031Z 
2017-04-21T23:54:29.8830053Z InputObject: PRWarehouse-1-PRConfiguration.1.1.2-Dev1180 Database Package
2017-04-21T23:54:29.8830053Z NuGetFeedUrl: https://[RedactedURI]/nuget/packages
2017-04-21T23:54:29.8986373Z NuGetApiKey: ********
2017-04-21T23:54:29.8986373Z DlmDashboardUrl: null
2017-04-21T23:54:29.8986373Z Publishing database package to 'https://[RedactedURI]/nuget/packages
2017-04-21T23:54:30.1954924Z Published 'PRWarehouse-1-PRConfiguration.1.1.2-Dev1180 Database Package' to 'https://RedactedURI]/nuget/packages'.

I purposely don’t use a period there to avoid Octopus from thinking it’s a version number (rather a sequence number to force ordering in the package listing).

The packages that are OK are singleton packages (not set based) so have no sequence number for Octopus to fall over on.

So, question now becomes, for why did Octopus deicide to change my - to a .?

And why does this only seem to effect the package downloads? As I mentioned in my OP, deploying these works just fine.

4

Hi Rachel,

Oh, I misread and thought the deploy was now working. You are most likely running into this issue. I’ll let the team know that we’ve had another report and we should consider bumping it up the priority list.

Robert W

5

Yeah, I can see how that would be an issue! :slight_smile:

Do you know if the same happens to underscores? In other words, if I change my dashs to underscores, will that avoid this bug?

I’m not married to the dash (although obviously I’d like to get this bug fixed so I can drop old packages correctly), I just needed something that wasn’t a period is all.

6

Hi,

Using an underscore should avoid this bug. For some background, and reasons that I can’t remember, we convert the first . to a - when storing the file on disk.

Rob

7

Or the first - to a . perhaps?

I love those reasons - “Way back, eons ago, Bob came up with a brilliant idea and…well, now we can’t remember what that reason was - but it was bloody brilliant and fixed a major issue (we think)”.

I’ve subscribed the bug report on GitHub.

Thanks for the swift replies!

R

8

Hi Rachel,

Looked a bit further into it, we use - to join parts of ids together in a url, so the packageID and version got joined as such. Now we can’t tell if it was MyPackage-1 version 1.0.0 or MyPackage version 1-1.0.0 as both as valid semantic versions.

The work around is to either use a _ or make the bit after the - not just a number (eg Package-1a).

I’ve raised it with the team and it’s on the backlog, but it may be some time before we get to it.

Robert W