Hmm, not sure, but it sounds like the problem is a corrupt install package? That's a error thrown from within MSI extraction. Maybe try downloading the file again.

We will add the descriptions at some point (we have them in BuildMaster). The HTML should probably be in a div, as it renders the value as a literal string. You can try it with something like: <div class="white-box padded-box"><h2>{Company} ProGet Repository</h2><p>Welcome to our collection of ProGet feeds.</p></div>

This sounds like it's related to package indexing. Please see this StackOverflow answer for troubleshooting steps: http://stackoverflow.com/questions/23812344/publishing-to-proget-and-i-cant-see-any-packages

There is a "purge artifacts trigger" that you can set-up that will delete artifacts from Rejected Builds, either immediately or once the release is deployed. We do have it on our roadmap to have artifact retention and clean-up policies as a more advanced feature.

NOTE : BuildMaster has Retention Policies which are strongly recommended, rather than manually purging data That being said, you can use the same strategy to delete from that table that you used for log entries: BuildMaster 4.2 and earlier: SELECT TOP 100 * FROM BuildExecution_PlanActionVariableValues --DELETE BuildExecution_PlanActionVariableValues WHERE BuildExecution_PlanAction_Id IN (SELECT BuildExecution_PlanAction_Id FROM BuildExecution_PlanActions BEPA INNER JOIN BuildExecutions BE ON BE.Execution_Id = BEPA.Execution_Id INNER JOIN Builds B ON BE.Application_Id = B.Application_Id AND BE.Release_Number = B.Release_Number AND BE.Build_Number = B.Build_Number WHERE B.BuildStatus_Name = 'Rejected') BuildMaster 4.3 through 4.9: SELECT TOP 100 * FROM BuildExecution_ActionGroupActionVariableValues --DELETE BuildExecution_ActionGroupActionVariableValues WHERE BuildExecution_ActionGroupAction_Id IN (SELECT BuildExecution_ActionGroupAction_Id FROM BuildExecution_ActionGroupActions BEAGA INNER JOIN BuildExecution_DeploymentPlans BDP ON BEAGA.BuildExecution_DeploymentPlan_Id = BDP.BuildExecution_DeploymentPlan_Id INNER JOIN BuildExecutions BE ON BE.Execution_Id = BDP.Execution_Id INNER JOIN Builds B ON BE.Application_Id = B.Application_Id AND BE.Release_Number = B.Release_Number AND BE.Build_Number = B.Build_Number WHERE B.BuildStatus_Name = 'Rejected')

Wow, what an incredibly fast response. Thanks

This sounds like it's related to package indexing. Please see this StackOverflow answer for troubleshooting steps: http://stackoverflow.com/questions/23812344/publishing-to-proget-and-i-cant-see-any-packages

To expand on this story what we are thinking about doing is creating a wide open pass through feed to Nuget that would allow users to discover new open source software to use. By forcing users through Proget we can get user info to send them reminder emails about OSS that we have not yet cleared for use in our products. Then the devs can get it cleared etc.

Are you overwriting an existing package when this happens, or are these fresh packages that are getting uploaded? Either way, if you could send that Process Monitor output to support@inedo and reference this post that would be very helpful, thank you!

We believe that it should not because it's most likely a mistake to specify a directory that doesn't exist as the working directory since presumably there could be files to work with, etc. in that directory. As you mentioned, the workaround is to create the directory before this step. I would just use mkdir in a PowerShell or Bash script.

At this point in time, it is unlikely. However, Atlassian does mention on their site that plugins could be created to integrate with third-party tools, and the JSON ProGet API could be used for this.

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.