We don't have export capability for those other items just yet. Does purging the logs as per http://inedo.com/support/questions/1826 not help clean out 90%+ of the space? The log table is the one that typically fills the BuildMaster database. There are some other tables that could also contain a lot of data depending on usage, those being: BuildOutputs (if you generate and store reports with every build) BuildTestResults (if you run unit tests during builds) EventOccurenceDetails & EventOccurences (if many users are constantly using the software) The first 2 can be purged for rejected builds, and the event occurences can be purged entirely if that data is meaningless.

Tod, I justed tested it and it works perfectly. You can see this API being used in Fiddler when you use the "Show all versions" link for a package in NPE. Previously doing that didn't work against a ProGet feed. Thank you for the fast turn-around! That was impressive... Riko

Apologies for the delay, but as of v3.0.3, you can configure your feed so that the PDBs are not stripped out.

For completeness, v3.0.3 was just published which adds an index to Publish_Date and the dashboard query now returns virtually instantly tested against 100,000+ packages in the database.

Thanks Philipp, we've identified some additional performance issues as well and will plan to release a maintence ProGet release to fix this .. ideally today.

You can't run BuildMaster on MySQL, but it is relatively easy to move it to a different SQL Server -- see Backing-up and Restoring BuildMaster

Thanks Tod, I have run your query and it deleted most of the rows out of the log table. However, Buildmaster is still timing out due to slow database performance. Are there any other tables we can reduce in size. Also we are looking to upgrade to SQL Server as soon as possible.

Just name your database connections something like: "SQL-Integration", "SQL-Testing" (using the environment names). Then in your "Execute Database Change Script" (or whichever database action you're using), enter the name of the database connection as SQL-${EnvironmentName}

Thanks for the additional information. I've logged this as an item in TFS (https://github.com/Inedo/bmx-tfs2012/issues/16), and we'll fix it ASAP. In the mean time, it might be easy to work-around with doing a clone/patch: http://inedo.com/support/tutorials/cloning-and-patching-an-inedo-extension.

Thanks for the bug report, Dave. This has been identified as a regression in 4.2, and will be fixed as BM-1474 in 4.2.6. You can manually visit the page by using the execution ID as a workaround. http://servername:80/executions/view-log?executionId=XXXX

Unfortunately, the "Download Dependencies" feature can act a little funny because the way NuGet does dependencies is a little funny. It's on our list to improve this functionality.

Yes, just edit the connection string in both the web and services directory.

Hi Dan, It sounds like this new issue is related to your new domain account not being able to connect to your svn server through a proxy server. One thing you can try... log on to the BuildMaster server using this new account, and try to run that same SVN command. It might pop-up an authentication dialog, or something... in which case, you can get better insight into the exact specific problem.

I see; in this case, your old extension is still being loaded. Maybe the service/webapp wasn't restarted, etc? Easy thing to test, add a new LogDebug(...) before that SPROC call.

Thank you for the bug report. We have reproduced this and it will be fixed in 4.2.4, which is scheduled for release today. The bug is: BM-1464: NullReferenceException when creating or editing an action where there is a server that the current user does not have access to

Interesting, it looks like the unzip program is returning a non-zero exit code, which causes the SSH agent to interpret the command as an error. You might be able to get around this by editing that specific Deploy Artifact action to treat errors as warnings. Also as a workaround, you could deploy the artifact to the "CurrentDirectory" on the BuildMaster server, then use the Transfer/Synchronize Files action from the CurrentDirectory on the BuildMaster server to the Solaris server.

Are you using the integrated web server, or hosting via IIS? Regardless, if you don't want to just delete the ProGet database and start from scratch, you can run the following command from PowerShell or a CMD window to reset the authentication mechanism: sqlcmd -E -S localhost -d ProGet -Q "UPDATE Configuration SET Value_Text = 'false' WHERE Key_Name = 'LDAPEnabled'" You can additionally reset the Admin user by running the ProGet.Service.exe executable and selecting Action 7 "ResetAdminPassword".

This is a known issue with .NET-based services on low-spec servers running Windows Server 2003. Basically, the CLR cannot load in time, triggering an error. In newer server operating systems, you can specify Delay Start, which solves the problem, but it's not possible on 2003. There is a workaround available from Microsoft, KB#193888.

To back-up ProGet, you just need to Back-up the Database and the Packages directory (the path is listed on each feed, and is in the All Settings under Admin).

The patch corrected the issue. Thank you.