Thank you. The server was activated fine and is working very well. I am satisfied.

For future reference, this was happening because the application attempting to be built was including an imported deployable, and there was no active build in the referenced application. The error message will be clarified in the next version of BuildMaster (v3.2.2).

Yes, but not easily. Automatic build records (schedule, SCM-triggered, or URL-triggered) are not "soft deleted", so you must go to the audit logs and search for the "BSHDEL" event. This can be done from the UI or directly from the database with SELECT * FROM EventOccurences WHERE Event_Code='BSHDEL'

Do you know if you are running the BuildMaster web application through the integrated web server, or if it's hosted by IIS? For the integrated web server, ensure that its service runs under Administrator as well. If you're using IIS, you'll have to verify that the app pool's identity is running as the Administrator account in addition to the BuildMaster service. Right now we are in the process of writing a knowledge base article that will give step-by-step instructions with regards to connecting to GitHub since that seems to be the most common hosted solution for our Git integration.

If you're using the integrated web server, can you verify that the "BuildMaster Web Server" service is started? (Start > Run > "services.msc" to check, if it's not, just click Start). If you're using IIS to host the BuildMaster site, can you verify that the site is started and the BuildMaster app pool is running?

The Branch Action is designed for "tagging" builds (Subversion and CVS), and actually, it's been renamed in 3.2 and will only be displayed if you have one of those providers. You're definitely on the right track for labeling each build, but merging... it's not really something you can do on an automated basis because of conflicts. That said, if you do want to merge, you can simply call tf.exe merge.

All you should need to do is copy the output to wherever you want it published using the "Transfer Files" action immediately following the "Prepare ClickOnce Application".

Looks like I'll have to wait for 1.0.2. I can't seem to proxy the NuGet gallery even when I run the ProGet service as an account that has Internet access. I won't get to look at this until our Tuesday though.

It does indeed go against the business logic of change control history... and as such we don't have a feature or API call that can "unperform" a change control (or, technically, delete the change control performance record). If you are so inclined, you can delete the relavent row from the ChangeControlPerformances database table in the BuildMaster database... but as with any direct database changes, tread lightly :-)

Check out the BuildMaster API references: http://«host:port»/api/json http://«host:port»/api/soap If you're coding in C#, the SOAP API is probably easier, since it can generate types for you. You'd probably want to call Releases_GetReleases to get a status of all the releases and builds of an application.

We found that the Change Control feature was somehow disabled when we upgraded the version. Not sure how this happened, but when we set the Change Control setting to (not set) as it was previously, everything was back to normal. Thanks, Matthew

There is no known issue with the layout in Chrome for that version. Chrome likes to cache aggressively (sometimes ignoring the no-cache headers) and will keep things cached even if you hard refresh (w/ CTRL+F5). Try clearing the cache through the menu (CTRL+SHIFT+DEL) and that will probably resolve your issue.

Hi Alex, After reading your (Alex') reply I concluded that given the fact that I'm using a WinXP machine as a build server, using IIS is no option for me. I had already tried the instructions you gave me. I tried them again an to no avail. I did noticed that although I did provide a valid username and password the service was still being registered under the local service user. That was odd. I guessed the settings for the webserver would be stored in the database (as I couldn't find them in the config file). I added the IntegratedWebServer_Prefixes (which I remembered from the settings screen) and added a binding. -> Works like a charm. However, I still wondered why registering the service as described in the knowledgebase article didn't work. So I took a peek inside bmservice.exe. I found the answer in the construcor of the Arguments class. The knowledgebase article is wrong! The command to execute isn't "bmservice /iws /user=[SERVICE_USER] /password=[SERVICE_USER_PASSWORD] /prefixes=[HOST_NAMES]", it's bmservice /iws /user [SERVICE_USER] /password [SERVICE_USER_PASSWORD] /prefixes [HOST_NAMES]". Also, the hostnames aren't sparated by semicolons, but by regular colons. Maybe you could fix this in the knowledgebase? Thanks, // Vincent.

Hi Oleg, The problem is that the database stores some of this information as VARCHAR instead of NVARCHAR. SQL Server converts cyrillic (and other non-Latin) characters to ???. Unfortunately, there is no quick fix; the appropriate columns (and stored procs, etc) must be changed to NVARCHAR. But we do have this planned for 3.2, which isn't too far away. Best, Steve

It appears you've discovered a bug in our variables engine that will be fixed in the next maintenance version v3.1.5 (scheduled on or before 5/25/12). Thanks for the report.

We have a known issue where if you have two test actions with the same group name in the same deployment plan, you will get this error. The workaround is to use a different group name for each test action in the same plan.

Yes; just set up an Source Control Triggered Automatic Build ( http://inedo.com/support/documentation/buildmaster/core-concepts/builds/source-control-triggered-builds ) that watches the desired path(s), and a build will be kicked off when that changes.

Yes. This is what “imported deployables” are used for; on the deployables screen, just add an imported deployable, and then you will be able to create an action group that can deploy that artifact. The “framework recipe” demonstrates this usage somewhat.

This is typically a sign that the account used to install BuildMaster does not have the necessary privileges to create a Windows service.

"Agents" and "Servers" are generally synonymous, but there is a subtle difference. Servers represent actual (physical or virtual) servers that BuildMaster can orchestrate. Actions can operate against Servers, files can be transferred from one Server to another, etc. A "Server Group" is a set of servers that can be treated as a single server. Agents are the mechanism that BuildMaster uses to communicate with servers, and are tied to a specific protocol (SOAP/Binary/SSH) and/or operating system (Windows, Linux, etc). Environments are on a "higher level" than Servers and Server Groups; they describe a stage of testing that your application is currently in, e.g. "Integration", "QA Testing", or "Production". Server groups are a way to simplify deployment to clusters, if necessary. Environments can consist of any number of servers and server groups. To make matters more confusing... you can still work with other servers without an agent, but you're limited to whatever you can do in a normal Windows environment. For example, you can transfer files over UNC paths so long as permissions are set-up, etc. installing an agent and hooking it up to BuildMaster (via External Servers) allows a higher degree of control.