This has also been reported in our Jenkins extensions issues section, can you take a moment to respond to the questions I posed here? https://github.com/Inedo/inedox-jenkins/issues/26#issuecomment-454188149

Here is a working PowerShell example (v6.1+): Invoke-RestMethod -Method POST -Uri "http://{bmserver:port}/api/releases/builds/deploy?applicationName=ApiTest&releaseNumber=1.2.3&buildNumber=1&key=<api-key>" For pre-v6.1 versions, the equivalent is: Invoke-RestMethod -Method POST -Uri "http://{bmserver:port}/api/releases/packages/deploy?applicationName=ApiTest&releaseNumber=1.2.3&packageNumber=1&key=<api-key>" I have also put in a doc change request to clarify the endpoint names. Additional note: -UseDefaultCredentials would be required if Integrated Authentication were enabled.

That worked great. Thanks!

If it still doesn't work after you've granted anonymous to the feed, then one possibility is that you have WebDAV (caused from a Windows Update?), or a proxy server blocking the PUT request. I've seen that quite a bit..

You can either use the Release Name for this, or you can use a combination of Build and Release number to create a four part version number ($ReleaseNumber.$BuildNumber)

Aha, it will also be included in BuildMaster... not sure why I got stuck on Otter. I guess it was on my mind because we just had a maintenance release today :) This feature is also scheduled for BuildMaster v6.1.10 on July 19

Thank you for the report; this will be resolved by the following issue: BM-3364

Great idea :) See BM-3278

Yes! You can use either NuGet or Universal Packages to store your C++ code and packages, and those host those in ProGet.

Just to clarify, you can create releases on the "Releases" tab, just "Create New Release". You can have multiple simultaneous releases per application going on, which is ideal for a scenario you describe

InedoCore 1.0.10 was accidently released; it was a pre-production version and should not have been shipped. It's since been removed. However, you identified the correct remediation steps: manually restore the old version of the extension. Sorry for the inconvenience.

I ended up using powershell to add variables to a properties file of env.properties. Then used the "inject environment variables" post build step to add the file with those variables to by environment. #Powershell "APP_VERSION=$appVersion RELEASE_NUMBER_VAR=$releaseNumber IIS_APP_ROOT_NAME=$iisAppRootName APP_EMAIL=$appEmail" | Out-File env.properties -Encoding ASCII Then then used the Get-Release API to check and see if my selected release was a valid release. If not I created it with the Create-Release API. Then used the Inedo_BuildMaster Plugin for jenkins. Create BuildMaster Package - Post Build Step Variables: appEmail = ${APP_EMAIL} appVersion = ${APP_VERSION} buildNumber = ${BUILD_NUMBER} buildType = ${BuildTypeParam} iisAppRootName = ${IIS_APP_ROOT_NAME} iisHostNamePrefix = ${BuildTypeParam} After I figured out myself how to inject the Variables and use them properly this rout was much better because it let me know when the package was done deploying, if it failed, showed me the deployment log on failure and failed my Jenkins Job on Failure. Thank you for your answer though Josh!

I'm sorry but I'm not understanding what you mean by "queues" or "hangfire"...

Glad to see it's working; but just as an FYI, the installer does not have any code that can delete the database. That's only in the uninstaller program, and that needs to be manually run with double-confirmation (in the UI).

ProGet is primarily developed in .NET (C#) and SQL Server. The front end, of course, uses JavaScript (TypeScript). Our other products use the same technologies

This is also fixed (BM-3271) starting in v6.1.0

I've deleted FTP extension and restarted both BM services. After restart it works properly. Thank you.

Thanks, it is working now.

Are you pushing the same version number? If so, this is (unfortunately) a by-design feature of NuGet. The solution is to use pre-release versioning, or instruct the NuGet task of the build server to always request with the -NoCache flag.