OK they are now triggering. Thanks. Please can you advise on how to manage the release numbers For the regression test I entered a release number one higher than the current release on the standard. In reality my regression release will never go into production. The regression Test workflow is set to a loose Automatic Release Close-Out and disabled Release Cancellation. But the standard workflow is set to strict on all these. When the standard workflow is released into production, will it cancel my regression release. Should I set the regression release to a much high number or will this screw up the standard release numbering?

Your best bet would be to do a "Delete Files (*) From ~/Src" Action.

Additionally, if you have publish profiles saved in your solution, you can add the following additional argument that will exhibit the same behavior as AutoParameterizationWebConfigConnectionStrings=false for the chosen ProfileName: /p:PublishProfile=ProfileName

Yes; if there is no deployable, then "0" is used as part of the path (e.g. <tmp>\A12\S0\WRK\my-path)

The "default" folder (usually the SRC subfolder) is unique to applications and deployables, and is housed under the <bmas-tmp>\A<appid>\S<depid> folders. It is cleared during the "preparing agents" step at the start of every action, unless it's a re-execution of a failed deployment. Only one execution within an application is permitted at the same time, so the second one created will be queued until the first completes.

We have upgraded to Buildmaster 4.0.9 (B31) and the "Execution Status" == succeeded work better but still not correctly. The predicate test is on the Action Group which contains 2 separate actions. The first action fails (and shows as failed in the log) then the next action succeeds and this marks the Execution Status as succeeded again to the remaining predicate tests pass. It would seem that the Execution Status should not be set the succeeded after it has been set to Failed.

It's not available now, but we are strongly considering targeting that (and some related features) in v4.2, which should ship in March.

It appears the user that is running the web application does not have the needed permissions to restart the BuildMaster service. If you either 1) change the user account to one that has permissions to do so, or 2) manually restart the BuildMaster service, you should see the extensions.

This is caused when BuildMaster cannot determine the CPU ID or MAC address of the server it is installed on. Here is a detailed description: http://inedo.com/support/kb/1005/this-machine-cannot-be-uniquely-identified Typically, restarting the server fixes this problem. If that still doesn't work, you can also try the following steps to resolve: Stop the Windows Management Instrumentation service. Go to the %SystemRoot%\System32\Wbem\Repository folder. Delete all of the files that are in the %SystemRoot%\System32\Wbem\Repository folder. Restart the computer. The files that were deleted are recreated when the computer restarts. The Windows Management Instrumentation service will start automatically when you restart the computer. (These steps were taken from: http://minasi.com/forum/topic.asp?TOPIC_ID=5772)

There is no officially supported desktop client; however, one of our VIPs at Leaping Gorilla built a custom one. The repository is at: https://leapinggorilla.kilnhg.com/Code/Open-Source/Group/Buildmaster-Tray

I can't think of any tangible benefits to doing so, and can't think of any real drawbacks either. The only possible issue I could think of would be cookie related -- e.g. if you have the same hostname for both products differing only by port, there could possibly be conflicts with the cookie names. Using different hostnames would solve that, however.

@J.D. - can you post this a new question? It may only be tangentially related to the original post in this thread.

Are you using the embedded/built-in SVN client, or are you pointing at your own svn.exe, and if so, what version is it? That behavior seems odd since BuildMaster explicitly instructs the command line client to ignore these types of errors: https://github.com/Inedo/bmx-subversion/blob/master/Subversion15Provider.cs#L318 As a workaround, I suppose you could run the command line under the same account that BuildMaster runs as and accept the certificate manually as you have likely done with your own account. If you need to accept the certificate as LOCAL SYSTEM, you can follow the steps here under Using LOCALSYSTEM Windows Service to accept it as LOCAL SYSTEM. It's also worth noting that for the non-interactive/trust-server-cert flags to be acknowledged, the hostname of the SSL certificate installed on the server must be the same as the one in the repo URL. Is it possible that your SVN server cert is assigned to an IP address instead of the hostname, or vice-versa perhaps?

Hey Tod, Its when we execute the workflow, it hungs after the execution is started. the very first step after it starts, still I kept the work flow going on.. and it took 208mins to execute all the steps which generally shall take not more than 2mins... A simple app pool recycle on the target system takes more than 30mins. I verified the communication with the target system and the agent .. they are working fine... the ports and communication between both the servers is good did the telnet and its responding... I can transfer the data between both the servers using normal copy within seconds... so no network issues. I can see the agents as ready for the target system.

BuildMaster Enterprise is licensing on annual or perpetual/lifetime basis. If you purchase an annual license, then you'll receive a key that will active the software for a year, and we will provide maintenance/support during that period. To continue after the first year, you'd have to purchase another license. If you purchase a perpetual license, then you'll receive a non-expiring key and a year of maintenance/support. You can renew support/maintenance after that, but the software will work regardless. Hope that helps.

The SOAP-based agent is the IIS-hosted agent, so IIS would need to be enabled. The installer for that agent will automatically set up IIS for you.

Submitting here is just fine - the newest 4.0 Beta will do this now, thanks.

That is great.I look forward to the new version. My intial impressions are very good - even though I haven't been able to set up a project.

Hello David! You can add multiple repositories like that in the "Repositories" section when editing the source control provider. When you're editing the provider, enter: http://myserver/svn/ as the Subversion URL, and the repos would be: Relative Repository Path: Repo1 Repository Name: Repo1 If you're having trouble with that, you could always just add multiple source control providers each with their Repository URLs pointing at their own repos.

The simplest way is: http://inedo.com/support/kb/1001/backing-up-and-restoring-buildmaster It's worth mentioning in the v4.0.1-beta that there is an import/export option for deployment plans (not application configuration yet).