Proget: deployment usage api not failing but no usage logged

[MaxCascone]

I don't see any package deployment info when POSTing it using the package deployment api. The API doesn't return an error, in fact it logs a 200 in the local log, but it doesn't do anything, either.

I have seen this similar question but i seem to be doing all the same things, and not seeing the expected results.

I'm using the same powershell format as used in the docs.

I also tried the Jenkins httpRequest function, with the same results.
I tried with and without an API token. The token has all privileges.
I tried with JSON and forms formats.

Where else should i be looking for an error?

thanks!

# powershell
$data = @{
  FeedName='myFeed'
  Application='Jenkins'
  Description='Deployed by Jenkins'
  Target='DEV'
  PackageName='myPackage'
  GroupName='myGroup'
  Version='1.0.8-0004'
}

$headers = @{
  # 'content-type' = 'application/json'
  'content-type' = 'application/x-www-form-urlencoded'
}

# Invoke-RestMethod -Method Post -Uri 'https://proget.myCompany.com/api/package-deployment/' -Body ($data | ConvertTo-JSON) -Headers $headers

Invoke-RestMethod -Method Post -Uri 'https://proget.myCompany.com/api/package-deployment/' -Body $data -Headers $headers

// Jenkins
response = httpRequest consoleLogResponseBody: true, 
  contentType: 'APPLICATION_FORM', 
  customHeaders: [[maskValue: true, name: 'X-ApiKey', value: 'redacted-key']], 
  httpMode: 'POST', ignoreSslErrors: true, 
  requestBody: 'FeedName=myFeed&Application=Jenkins&Description=Deployed-by-Jenkins&Target=DEV&PackageName=myPackage&GroupName=myGroup&Version=4.2.1-c8adb60', 
  url: 'https://proget.myCompany.com/api/package-deployment/', 
  validResponseCodes: '', wrapAsMultipart: true            }

// result:
HttpMethod: POST
URL: https://proget.myCompany.com/api/package-deployment/
Content-Type: application/x-www-form-urlencoded; charset=ISO-8859-1
X-ApiKey: *****
Sending request to url: https://proget.myCompany.com/api/package-deployment/
Response Code: HTTP/1.1 200 OK
Response: 

Success: Status code 200 is in the accepted range: 
[Pipeline] }
[Pipeline] // script
[Pipeline] echo
Status: 200

[MaxCascone]

Update! I looked in the history tab of the package i'm testing this with, and the deploy records are there.

So how/when do they show up in the Usage tab?

Am I misunderstanding something here?

[Dan_Woolf]

Hi @mcascone,

The package deployment API will show in the History tab of the package. The Package usage block is actually part of Package Usage Scanners that are only supported on specific feed types. Which feed type are you using in this situation?

Thanks,
Dan

[MaxCascone]

@Dan_Woolf hmm, I was starting to get that impression from my testing, but the docs are a little misleading, or maybe I was just seeing what I wanted to see.

I’m using universal packages for most of our internal artifacts. Only a handful of apps are set up to be true nugets.

In my opinion, it’s a little unfortunate that the deploy statistics are kind of hidden, fairly unimpressively displayed, and not top-tier like the usage display. Is there an alternative?

[stevedennis]

Hi @mcascone ,

These are two different features...

Deployment records show which servers a package has been deployed to from that instance of ProGet, at some point in the past. They are usually added when a package is downloaded, and the GET request has a special header parameter or a user agent string.

Package usage is more complex, in that it shows which servers/hosts a package (or container) is currently installed on, regardless of whether it was deployed from ProGet or not. It requires a PackageContainerScanner component, which is intended to bridge the gap between servers and packages.

We currently have two scanners: one that interacts with Otter's API (which can return Docker, Debian, Rpm, Universal, and Chocolatey packages across your servers) and Kubernetes API (which is just Docker and Helm charts).

Hope that helps,
Steve

[MaxCascone]

Thanks @stevedennis, that's helpful, and frankly more clear than the documentation on either feature.

This might not be the right place for it, but I'd like to enter a feature request to get the Deploy History displayed similarly to the Usage History.

I would love to see a 'pretty' chart like the usage chart:, as a top-tier piece of data about a package, without having to dig into a tab to find it.

For what it's worth, since I'm using the Jenkins ProGet plugin, I don't think I have the ability to add the deployment info to a package at download time. So I'm using the Package Deployment API to send the data at deployment time.

Is there a way to add the deployment info using the ProGet download Jenkins plugin?

[stevedennis]

Glad that helped @mcascone , I'll try to update the docs when I get a chance!

In older versions, that information used to be displayed more prominently, but unfortunately relatively few users seem to utilize that data, and several have moved to Package Usage. I think someone even built Usage Scanner that queried that deployment history table but we couldn't get much info beyond that...

We don't maintain that Jenkins plugin, but it is open-source and if you're comfortable enough with Java you might be able to add the required header fields?

https://github.com/jenkinsci/inedo-proget-plugin/blob/master/src/main/java/com/inedo/proget/api/ProGetApi.java#L189

But you may find upack.exe to be better, since it can "install" packages, which then maintains a history on the server itself.

[MaxCascone]

That makes sense, i must have just read too much into the feature. It's still useful! And I include a link back to the Jenkins run that did the deploy, so it actually feels very cohesive.
Is there any way to pull that information via the api? I don't exactly know what I'd use it for, but we are also about to start pushing all of our ci/cd activity into our ELK logging stack, so we'd at least be able to make some pretty pictures out of it eventually.

[stevedennis]

It seems the package deployment endpoint is POST-only, but using the Native API you could use the Packages_GetPackageDeployments method. Down the line we can certainly consider adding GET method on the deployment api... if you can help us know what you/someone will use that info for ;)