I've got it working now, but only with the port. I'd rather not have to do that, but it will work for now. I'd really like to know why I can't use a reverse proxy in front of ProGet to avoid needing to specify port numbers.

There are some disk usage reports on the Manage Feed Page, but they do not break it down overtime and by month. We simply do not store disk usage statistics -- only the current space utilization. There are likely some third-party utilities that will tell you disk usage peaks, usage over time, etc; you can point those to the disk path that ProGet uses for internal storage.

The issue is that before nuget publishes a package, it goes to the feed source without authentication with GET. This fails with 401 and nuget starts asking credentials. In general, this means that we must have a view feed assigned to anonymous user, which is rather unfortunate but this is the issue with nuget.exe

The service must be able to restart itself and overwrite its own files.

Hmm, they are not different. Privileges are checked in the same manner regardless of the action that's being edited. If you're running into an error, it may not be related to privileges; perhaps send in some screenshots / more details to support at inedo dot com? If the plan is a global plan, note you need the [Plans_ManageGlobalPlans] task instead of the [Plans_ManagePlans] task.

If you want multiple builds of the same application going at the same time, then you won't be able to use the default, $CurrentDirectory. I would instead use a directory like, $ApplicationDirectory$ReleaseNumber$BuildNumber. However, once you deploy a release, you may want to clear $ApplicationDirectory$ReleaseNumber, otherwise you will end up with a lot of disc space used.

Oh, it works now. Thanks a lot, Alana!

This requires the [Events_ManageOwnNotifiers] task.

After updating to ProGet 3.8.1 the query http://192.168.216.1:25602/nuget/Packages()/$count?$filter=substringof('TESTTAG',Tags) now works as expected. Fixed by • PG-441 - FIX: substringof OData function arguments should be swapped Thanks.

SFTP essentially works over SSH; BuildMaster's SSH-based agents utilize SSH and SFTP to run scripts, actions, and transfer files; so, you can just set-up an SSH agent, and then transfer files as needed. FTPS, on the other hand, is completely different; it's basically FTP over SSL, so you can just use the FTP extension for that.

The reason you have to Get Latest is because otherwise if you built straight from the BuildMaster-managed "ScrRepo" directory, there would be artifacts from the SCM tool also included (for git, .git files), and other times added files from the BuildMaster build steps that you wouldn't want stored with the repo. Once you "Get Latest" somewhere, you can operate on a fresh set of files to perform whatever build tasks are necessary for deployment. Note the "Get Latest" action will essentially perform a clone or pull from BitBucket, then copy the files to the source directory of the action.

You don't have to install Visual Studio 2015 on the buidlserver. Install MS Build Tools 2015 will do it. https://www.microsoft.com/en-us/download/details.aspx?id=48159

That sounds great! I'll mail you some testcases for reproducing the issues we ran into shortly.

not currently, but it's definitely on our roadmap to do a caching in a similar manner

Tod, I have resolved my problem. Where I select "server" on new git repo setup, I shouldn't have chosen the target server, but the server, where buildmaster (and git) is running. This confused me. Thanks for attention, Milan

Hi, Same question here: http://inedo.com/support/questions/3738. The git repo itself is worth caching for enterprise needs. Actually our developers checkin in the bower_components directory into their git repos, because of the "fear" that the public git repo is getting unavailable. As I can see, https://www.npmjs.com/package/private-bower has this feature. Regards Marco

Thanks for the feedback. The HttpModule was not the cause. I just had to configure the NuGet.config credentials correctly in %ProgramData%\NuGet\Config\NuGet.Config, which is machine wide rather than user specific. I will distribute this configuration to all developer machines using an Active Directory Group Policy.

So I wanted to respond on here, I wasn't quite sure what to do with the information but I wanted to proceed. What I did was the following: Forked the GitHub repository Modified the TfsBuildActionEditor to have a Checkbox for [Validate Build Status] Modified the TfsBuildAction to use this and created a ValidateBuild function If the Check is selected it sends an error and pulls the Build Errors from the Build Details and displays them. I am not sure if this is something you wished to add so I did not submit a pull request. I could do so, but this can be considered answered. The whole point being that we didn't believe that "Create TFS Build" goal was met during a build failure, and there should be a way of validating that this actually did occur. If a build controller fails then a build was not created, or was partially created, and thus the Action needed to be able to reflect that. This also helps keep the CI running smoothly since it now becomes very apparent why a build broke and does not actually break test. Hope this helps anyone else who hits that! Consider this closed.

Thanks Philipp i will findout the script to delete the files.

I have found the solution ... Set the Property "UseIntegratedWebServer" to False in the Advanced Config when use IIS. The solves the problem