Thanks Alex. Looking forward for new version.

Oh, that's certainly a mistake -- actually it came when the feature was released. But I've updated the index page, so it'll be updated at some point when site gets updated. The security API are also unspecc'd. That's something we plan to bring to all products, and will probably be much easier to spec out

Sorry for the confusion... I think those should be listed as "internal only" methods, and not on the API page. Anyway, the Native API can only be used for metadata. So you won't be able to use it in this manner.

UPDATE: this has been updated in PG-1632 __ Hello Jonas, Deleting images isn't in the native API because the stored procedures only delete metadata, but if your CI server has access to the database ProGet is using, you can run the stored procedure to delete the metadata for the image and ProGet will automatically delete the files whenever the FeedCleanup scheduled task next runs. Assuming your docker image is named proget:443/foo/bar/baz, the foo feed has ID 42, and the digest for the version of the image you want to delete is f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7, this SQL statement will work: EXEC [DockerImages_DeleteImage] /* Feed_Id */ 42, /* Repository_Name*/ 'bar/baz', /* Image_Digest */ 'f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7' GO If you don't know the digest, https://proget/api/json/DockerImages_GetImages?API_Key=[your API key from /administration/api-keys]&Feed_Id=42&Repository_Name=bar/baz returns metadata including Image_Digest and Published_Date, and https://proget/api/json/DockerImages_GetTags?API_Key=[your API key from /administration/api-keys]&Feed_Id=42&Repository_Name=bar/baz returns metadata including Image_Digest and Tag_Name.

Glad you were able to get a little further... I've added this to the our public issue tracker as PG-1026. It's currently classified as unscheduled, but I imagine it will make it into the next release.

I agree that it is a poor solution, but we do not have very many good solutions for this. Docker itself does not support prefixing private repositories; everything is assumed to be hosted in the same manner as the public registry (ie, absolute URL path from the server root), and assuming all /v2/ requests are Docker without some other declaration of intent in the request didn't seem good either. That said, if there's no collisions with anything else using that URL, we can change the default behavior.

Apparently I was an idiot and couldn't do basic auth correctly, because once I did that correctly it worked fine without anonymous access involved. I am using Java 8, and the Authenticator class to set the authentication on my URL globally. Hope this helps the next person coming along.

The native API is a database wrapper, and thus would only be able to return local/cached packages. You should consider using the NuGet API instead.

We'll add this, likely as a separate endpoint i.e. api/releases/create-from-template or something like that. It will appear as BM-2384 in the release notes (likely before it is actually documented on inedo.com).

I tried to use the docker API, however I'm having problems accessing it For example, according to the API documentation: GET /v2/<name>/manifests/<reference> Should get the signature, however using this call: curl -H "Accept: application/vnd.docker.distribution.manifest.v2+json" -X GET -vvv -k https://<host>/<repository>/v2/<image>/manifests/latest Returns not found. What is the correct way to call v2 API from a proget docker repository ? I couldn't find any documentation about it. Thanks Francisco

The "Pull from Another Repository" actually requires the Feeds_PullPackage privilege; so make sure to grant anonymous that as well. Then it should work as expected!

There might not be a single API call for this, but there is the Variables Management API (were you can get the variables data), or you could use the Native API to list the deployables.

We'll add that as a proposed feature. I think the only issue aside from a small query/performance issue in implementation is that dependencies can change for different versions, so we'd really just be showing the latest version's dependencies there. Still, we are already doing that with certain fields like description, so that's not too bad...

The Release & Deployment API was added in BuildMaster v5.5 so you'd have to upgrade to use it. As for the /api/json page, it shouldn't require a key to view the methods so there's a bug there and I've added that to our internal issue tracker.

Thanks a lot. It works ;)

This isn't currently supported, but we can add an endpoint for that. Sounds like it would fit in the Package Deployment API (see roadmap). Of course, we can always ship these in earlier maintence releases, they just won't be documented and may change before final releases.

Whoops, seems like we forgot to update the operations documentation on the site after 1.3. The function is renamed to $GetCredentialProperty (though the old alias should still work) and you can access it like: <code>set $password = $GetCredentialProperty(MyCredential,Password);</code> Note you can see the generated documentation: http://<otter-host-name>/reference/functions

Thanks for the pointer. I noticed if I edit the Job Template it doesn't seem to have the right plan 'selected' in the Plan Name dropdown (it defaults to the first in the list every time). I think I saved it without noticing and it ended up attached to the wrong one. Maybe review the edit code that generates this page: https://url/job-templates/edit?jobTemplateId=x

This is definitely something we intend to address as part of our v5 roadmap; there just hasn't been a huge customer demand for automating BuildMaster using the sort of "temporary API access key" approach that has grown popular in the more consumer-facing things like Twitter, GitHub, etc. We may add this if there' demand and similar adoption in other tools in the space, but in our experience, it's generally more complicated for administers to manage and set-up. So they just set up one "access key" and give it to everyone. It's particular challenging for us to solve in the same manner because of the way BuildMaster scopes privileges (by application and environment), and because the Native API can work cross-application/environment. So, if it's a requirement to give limited access to Developers, the current best approach is to wrap the native api with a permissions wrapper, and then check if that user is authorized based on the AD group they're in, etc., based on the action they want to perform.

Thanks, Tod, but I want to keep all the actions on the client side. I found that I can just do a GET and a PUT, and once I constructed the multi-part form data correctly and added a boundary to the content, it worked.