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.

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

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.

This original post is really old and refers to an old version of BUildMaster (v4); I'm not sure what version you're using, etc. Can you submit this as a new question so we can more easily try to address / reproduce / investigate it?

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.

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

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.

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.

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.

Hi Tod, We upgraded from an older version, 3.6 to 4.3.8. The feature "Update Checklist" is a nice one and at the moment "all green". Execpt for one issue, the "Test your deployment plans". On our server we are running TFS 2010, version 10.0.30319.317. In Buildmaster we added the TFS2012 extension. Regarding your last remark "connections to TFS are now made by the BuildMaster service instead of the web application", do you mean by this that the "service-user"should have acces now to TFS ? Kind regards Martin

The patch corrected the issue. Thank you.

Downloaded and installed Oracle Extenstion 4.1.1 without any errors. Sincere thanks! I will begin to setup an Oracle db deploy and test the results. Thanks again, Dan.

Thank you for posting the action log. When extracting the zip file, the deploy artifact action attempts to run the unzip program, is that program available on the server? Based on the log above, the exact command is: unzip -o "/home/dmccaffr/_A3/_S4/TMP/[artifactName].zip" -d "/home/dmccaffr" An IOException is thrown if the exit status returned is not equal to 0. Can you verify that running that command on the server above actually unzips the artifact, and that its exit code is 0?

Hello, that cryptic message means that the RENAME FILES action does not yet work with the SSH-based agent. Your best bet is to write a simple shell script that can do the same.

Decided to go with the embedded version, install worked fine, I'll revisit this once I move out of testing mode and perhaps we can figure out what the issue is. Thanks! D

Yes, it's from the Dummy extension. When I click the "Add Server" button on the Servers page, it lets me choose an agent type -- self-hosted, IIS-hosted, SSH-based, or Dummy Agent. I was hoping to use dummy servers as stand-ins for real servers that don't (yet) exist so I could create my deployment plan before the servers exist. Then, once they exist, I would just point the deployment steps to the real servers.

No, the URL triggered builds are designed to be "fire and forget". However, even without a quiet period, the builds are still queued in a sense that they will not run over the top of themselves until the previous one is completed.

This sound like it's just a tough process to model. No matter what you do, you can't have it both ways such that you could deploy to either a subset of DevX servers to an arbitrary subset of QAX servers. The options you'll have to decide on are either: use different workflows and different environments to separate Dev1 from Dev2, which will force releases to use a specific set of servers after a build is created for it use abstract environments (Dev, QA) with server variables that resolve to different server groups (e.g. DevSet1, DevSet2, or whatever), and select the result either at release, build, or promotion time so it provides historical context with the release/build In BuildMaster, the idea of an Environment (i.e. a different stage of testing) is meant to be abstracted from a Server (i.e. a physical/virtual machine), so whatever follows most closely to this paradigm would be the way to go.

Thanks for the report - this should be fixed on the server end now, and you should be able to see the release notes on your end.