There isn't, although we do have an open item -- BM-3042 -- for it.

Hello Ben, we had a missunderstanding regarding the endpoints. We didn't get that every symbol feed is available at http://proget/symbols and every nuget feed respectively at http://proget/nuget. The naming of our feeds wasn't very helpful with that... Thank you very much.

wow, thank you very much ^^

It is, albeit a bit buried in the formal specification.

You may have a proxy server that doesn't allow a connection to Inedo.com; that's where latest news is loaded from. There's not enough to help here.

Hello Jamie, There's not a way to do this through the BuildMaster interface, but if you have access to the SQL database, you can run this: SELECT P.[Plan_Name], A.[Application_Name] FROM [Plans] P LEFT JOIN [Applications] A ON P.[Application_Id] = A.[Application_Id] WHERE CONVERT(VARCHAR(MAX), P.[Plan_Bytes]) LIKE '%call MyPlanTemplateName%' There's a possibility of false positives because the SQL query doesn't actually parse the plans, but it should be able to give you a rough idea of where a template has been used.

Hello Jim, You can run the ProGet service in interactive mode to see its logs: Stop the ProGet service. In Command Prompt or PowerShell, run .\ProGet.Service.exe run from C:\Program Files\ProGet\Service (or wherever you installed ProGet if you didn't use the default location). It will run the drop path monitor every 60 seconds by default. The message for the drop path monitor starting is Executing DropPathMonitorExecuter.... You can edit Service.DropPathMonitorExecuterThrottle in /administration/advanced-settings to less than 60 seconds if waiting gets too annoying. Immediately after the drop path monitor runs, there should be a message that says Scanning for packages in f:\dsc\droppath. This will be followed by Found f:\dsc\droppath\file.ext any packages it finds. In order to be found, the package files must end in the expected extension: .tgz for npm feeds .nupkg for NuGet feeds .gem for Ruby Gems feeds .upack for Universal feeds .vsix for VSIX feeds If an error occurs while trying to add a package from the drop path, it will appear on a line shortly after the Found f:\dsc\droppath\file.ext line, starting with Error installing package:.

Assuming ProGet.Service.exe is in C:\Program Files\ProGet\Service, there should be a folder named C:\Program Files\ProGet\WebApp. Does the WebApp folder exist?

Dependency resolution is handled entirely by the NuGet client, so it's hard to say why the NuGet client is hanging like that. There have been no changes to ProGet that would yield this behavior.

Each rule separately checks that all of its conditions are met before deleting a package. If any of the rules decide to delete a package, the package is deleted.

Hello Glenn, The payload will contain: Event_Code (BLDCPP) Event_Description (Build Promotion Completed) Release_Number Build_Number PipelineStage_Name For other types of event listeners, Event_Code and Event_Description are always included and the rest of the fields are from Event Details in the event log for that event type.

Hello Glenn, The next version of the YouTrack extension will include a Find-Issues operation, so you'll be able to do: YouTrack::Find-Issues ( Credentials: MyYouTrackCredentials, Project: IT, Filter: "version: $ReleaseNumber -resolved", Output => @IssueIDs ); foreach $id in @IssueIDs { YouTrack::Add-Comment ( Credentials: MyYouTrackCredentials, IssueId: $id, Comment: Testing BuildMaster/YouTrack integration. $ApplicationName $ReleaseNumber.$PackageNumber -> $EnvironmentName ); }

Thanks Alex. Looking forward for new version.

Hi Leo, can you try this? http://44.inedo.com/otter/artifactory-1.5.0-beta1.zip Note it will need to be manually installed by just copying the otterx file to your extensions folder.

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

I like the idea, but of course there's definitely some questions and things we'd need to think about before we can spec out the feature. Just some initial thoughts... Should this really apply to all applications, seems only a few might want to share one Pipelines and deployables are not global (well, you can have a global pipeline); what to do about that? Should UI restrict from choosing? Who can edit these? Admins only? How else will they behave differently? And then of course, there's the question of how this will tie into the (unspecc'd) "Projects" concept (cross-application releases)

This error appears to be related an extension missing. I would stop/start the agent, which should cause the extension to reload

Ah, I think the confusion here is because of the different meanings of the word "set". If you don't select the deployables in the release template, it will have the default deployables available in executions. That is, if you do for deployable Foo and Foo is a deployable in the application, it will execute the code inside the block. However, you can select specific deployables for a release and the for deployable Foo block will only be run if Foo is selected.

I found the issue. User error on my part. This is a small plan that handles this and I had a Legacy plan doing something similar but not using the Promote API. The pipeline was still pointing to that old plan and I just didn't notice the calls going to Proget. Then I was working on the new plan so as far as I knew it wasn't using the filename but in the old plan it was. Changed to the correct plan and the Promotion worked fine. Sorry for wasting your time on this.