There's supposed to be a button next to that text box that allows you to browse to the path in source control, but there was a small bug that prevented its display. We have just released a new version of the Windows SDK extension; if you update that within BuildMaster, then that [...] button will return and you will be able to select the path.

This was fixed in one of the versions we released this year, if you upgrade to the newest version it should work correctly. Make sure to read the Upgrade Notes for each minor version since 2.2 (i.e. 3.0 thru 3.3), and back up your ProGet database before upgrading (the installer should offer this option) as there have been significant changes to feed storage and indexing. You'll also want to read the KB article about Migrating Legacy Feeds.

The -source argument doesn't look right. Since the command is running remotely, it shouldn't be accessing localhost, but instead it should be using the ProGet server's URL. To override that URL, make sure to set the ODataBaseUrl in Advanced Configuration to something like: http://proget-server:1000/nuget/

I assume the internet is not accessible from the server that ProGet is installed on? Either way, try setting the UpdateCheck_Next setting on the Advanced Settings page to an empty value.

Reworking that page was already on our list of things to do for the next version, so this won't be an issue after that :) Thanks for your help!

I've just determined that the age is processed, but apparently we are not treating it as a hex number. We'll get this fixed in 3.3.6. Thanks a lot for the detailed analysis!

Thank you for investigating the issue. I will assume that the observed behavior is due to a problem with the dependency graph specific to the Ninject nuget package.

It looks like that was a holdover from when it was copied from the BuildMaster licensing page :/.... It should say: If you would prefer additional terms or an otherwise customized license agreement, we are amicable to negotiation for sales of 5 or more server licenses. From: http://inedo.com/proget/license-agreement

What it sounds like you're talking about is a "Build Importer"? We have one built for TFS - https://github.com/Inedo/bmx-tfs/tree/master/BuildImporter - and the basic idea is that you import your build's artifacts using that. As for chaging the status on VSOnline, that hopefully is just an HTTP Post, or it may require a custom action.

I hadn't thought of using BuildMaster like that. What I have implemented and seems to work well is a groovy script that make use of the BuildMaster and Artifactory json api's: Get List of all envrionment for this Application using GetEnvironments api For each environment get a list of the last 'X' builds and add to a list of of versions to keep using GetExecutions. As a build may get reapplied to the same envrionment several times to repair a failed deployment I get more than I need and only keep the to X unqiue versions for that environment. Get a list of folders from Artifactory for our application (each build is stored in seperate folder) using FolderInfo api For each folder returned, check its in our keep list, if not delete it using DeleteItem api

In 3.3.4 no; it is set to 1 minute and cannot be changed. We of course could make this configurable if 1 minute isn't quick enough.

This is a known issue having to do with the application & application group filtering of event listeners and was resolved in v4.5.4 (under issue # BM-1675), which was released yesterday - an upgrade will resolve it.

Reboot fixed the issues. Thanks for your reply.

Looks like there was an additional issue being caused by the feed metadata being slightly off. We've published another fix (v3.3.4).

Thank you, REPLACE works as intended.

This should be done on the Workflow page - you can add a Post-Deployment step "Auto-Promote Build to Next Environment" to any workflow step.

This appears to be the same bug as reported in this question. We'll have the fix available today. Thanks for the bug report!

We've reproduced this and implemented a fix- we'll have v3.3.3 available today to resolve this issue. Thanks for the bug report!

There are 3 possible statuses: the build status, the promotion status, and the execution status. I assume you want to get the build's execution status? If so, Builds_GetExecutions will do that (the only param you might not know to that is Execution_Count, which is just the number of executions to return, which you'd only want 1 since it orders by latest DESC).

Make sure the ExecutionStart_Date is passed in as UTC.