Off the top of my head, that seems like the best/easiest way. I think what we need to add is the ability to mark a manual action "incomplete" instead of forcing the user to cancel the deployment... that should make it easy then to create a Predicate that checks whether all manual actions were marked complete. I'll add these as feature requests for the time being, but am not sure when they will be shipped since your scenario should work fine for now.

This should be fixed in v4.5.7 (select NuGet or Chocolatey feed as the first option, and you can change the dropdown afterward). Note, we are considering deprecating the Deploy functionality in the next major version, so if you're looking to get started with deployment you should use BuildMaster instead.

There is no export functionality in that version, the recommended path is to just use the installer. What do you mean when you say it’s “too risky” to upgrade? Traditionally, only a few upgrades that we’re aware of have failed when upgrading from any version, and those were mostly due to unsupported database changes made by DBAs, which we can usually help resolved based on the error messages. Have you tested an upgrade by backing up and restoring the database, then running the installer against it?

Hi Dean, I ruled out the proxy since I know I'm getting to the server; I can see it in my IIS logs. What I did notice, is that when I tried to load the package from FeedB into FeedA again, the user the ProGet web app was using to authenticate was DOMAIN\MACHINENAME$ (e.g., NETWORK SERVICE). This account didn't have any rights to access ProGet, so the attempt was failing. My ProGet instance is hosted in IIS and the app pool was running using the application pool ID, so I first tried allowing DOMAIN\MACHINENAME$ access to the feed, but ProGet ignored that principal (I'm guessing you don't allow computer accounts to be added from AD). Next, since I have multiple service accounts lying around, I made the following configuration changes: Granted access to the service account to view FeedB in ProGet's Privileges & Roles Granted the service account access to the ProGet database, and put the user in the ProGetUser_Role role Changed the app pool of the site that the ProGet web app runs under to use the service account credentials Added my service account to the IIS_IUSRS group When I tried loading the package again, it worked correctly. So, the root cause here was that when ProGet is hosted in IIS using a built-in account that translates to DOMAIN\MACHINENAME$, you have to do some additional configuration to grant ProGet access to itself. Although this solved the problem, it would be handy to allow the specification of built-in accounts like BUILTIN\NETWORK SERVICE, or use the computer principal from AD such as DOMAIN\MACHINENAME$ when assigning privileges. Thanks!

FYI- 4.6.4 has been released, and this fix was included.

This action has been updated in 4.6.4, which is now available. We've added a more friendly editor for form data and some better documentation in the action. The UI will probably still be refined in a future release, but it should be more intuitive now.

I'll have to check with the dev team, but I think that was never intended to be part of the public API, since as you discovered, it takes a little application logic to clean up the actual artifact files as well. We originally had plans to add something to the service that would occasionally scan for orphaned artifacts on disk, but those were postponed. Your workaround should be safe enough, but it's not something we can add, as we can't rely on the database being on a server that can access the artifact library, or even that it's running as a user account with sufficient privileges. At some point, we'll likely reevaluate/extend our SOAP/JSON API's and allow them to do higher-level tasks like this, but there's no immediate plans for this.

Unfortunately not, but this would be a great place to post it if you are able to get it working! :) But before you do that, check under Advanced Settings to see if modifying the Base Odata URL field will solve the problem you're looking for.

I don't think you're doing anything wrong, but based on this, and your previous error... it sounds like you've got some server/network oddities. That could be any one of a THOUSAND things, but it's definitely not ProGet nor the NuGet clients. So, I'd suggest to put some wireshark or fiddler monitoring in between to see exactly what's happening, where they are coming from, and what the actual responses are.

Thanks Alana. I upgraded to Proget v3.5.6 and updated the timeout period for the nuget feed source to 30s. Now I am no longer getting that issue but I am getting a different one. I logged it as a separate question: http://inedo.com/support/questions/2969

Ah, I see; please note that we do not support v1 feeds (they were already obsolete when we build ProGet in 2012) and we have no intention to. Suggest you push packages from TeamCity to ProGet instead.

So upon doing a fiddler trace and seeing nothing coming through when I used nuget.exe against our internal repo, I tried it against nuget.org and lo and behold that failed too. It turns out for prior things I had HTTP_PROXY and HTTPS_PROXY environment variables set and nuget.exe didn't like it. This carried over to Visual Studio as well. After removing those variables everything started working again. So, sorry this wasn't ProGet at all (thankfully).

While the "switch to LDAP page" should not allow changing directories if it's not configured properly, most likely the BuildMaster server is unable to query ldap.

While there is currently no first-class extension for it, it'd be really easy to do with a Execute Command Line action, or a reusable Powershell Script that you put in the Script Repository. It's also fairly easy to write your own extension too -- if you choose to go that route, let us know, and we'll be happy to help where we can!

Thanks for letting us know. At some point, we switched to doing connector searches in parallel, so the ordering was no longer consistent for identical packages. It seems to be an easy fix though, so it should be working again in 3.5.6, due out this week.

It looks like the timeout box is not being rendered for some reason. We'll be releasing an update this week for ProGet which will include a fix for that. For now, it is possible to set the timeout either directly in the database or using the API. If you have access to the SQL instance, probably the easiest thing to do is change the Timeout_Period value for the connector (it's in seconds). You can get the connector ID by looking at the URL for an edit connector link. After setting it, you'll probably need to restart the web site by going to the All Settings page and just clicking Save. Sorry about this- we haven't needed to change the timeout period for a while. As far as the poor performance goes, I imagine nuget.org simply is not optimizing anymore for the types of queries that our connector filters are using. If there's nothing simple they can do on their end, we'll figure something out, but hopefully it's just a temporary issue with them.

This is related to the timeout question, so I've posted the answer there -- http://inedo.com/support/questions/2915#inline-post-2936

You can disable the View privileges from Anonymous user, otherwise you'll have to upgrade to the Enterprise edition (a free trial is available) for more specific, feed-level privileges,

Thanks for the investigation- we'll see if we can get this configurable in the next release, and possibly look into seeing if we can avoid clobbering web.config on upgrades.

Hi Byron - We do have a number of BuildMaster users who utilize the "Attach Build Report Action" to capture the output of a Fortify Static Code Analyzer scan after running it via the command-line; it's a general-purpose Action that will basically attach the report to the build so that everyone has visibility on the scan. Others will use Coverity for static analysis in the same manner. It would be relatively easy to build a "first-class" extension for Fortify, and as an enterprise customer, we'd be happy to work closely with you develop one should you want a bit tighter integration. Cheers, Alana