There isn't, although we do have an open item -- BM-3042 -- for it.

Hello Jamie, There's not a way to do this through the BuildMaster interface, but if you have access to the SQL database, you can run this: SELECT P.[Plan_Name], A.[Application_Name] FROM [Plans] P LEFT JOIN [Applications] A ON P.[Application_Id] = A.[Application_Id] WHERE CONVERT(VARCHAR(MAX), P.[Plan_Bytes]) LIKE '%call MyPlanTemplateName%' There's a possibility of false positives because the SQL query doesn't actually parse the plans, but it should be able to give you a rough idea of where a template has been used.

Hello Glenn, The payload will contain: Event_Code (BLDCPP) Event_Description (Build Promotion Completed) Release_Number Build_Number PipelineStage_Name For other types of event listeners, Event_Code and Event_Description are always included and the rest of the fields are from Event Details in the event log for that event type.

Hello Glenn, The next version of the YouTrack extension will include a Find-Issues operation, so you'll be able to do: YouTrack::Find-Issues ( Credentials: MyYouTrackCredentials, Project: IT, Filter: "version: $ReleaseNumber -resolved", Output => @IssueIDs ); foreach $id in @IssueIDs { YouTrack::Add-Comment ( Credentials: MyYouTrackCredentials, IssueId: $id, Comment: Testing BuildMaster/YouTrack integration. $ApplicationName $ReleaseNumber.$PackageNumber -> $EnvironmentName ); }

Ah, I think the confusion here is because of the different meanings of the word "set". If you don't select the deployables in the release template, it will have the default deployables available in executions. That is, if you do for deployable Foo and Foo is a deployable in the application, it will execute the code inside the block. However, you can select specific deployables for a release and the for deployable Foo block will only be run if Foo is selected.

This error appears to be related an extension missing. I would stop/start the agent, which should cause the extension to reload

I like the idea, but of course there's definitely some questions and things we'd need to think about before we can spec out the feature. Just some initial thoughts... Should this really apply to all applications, seems only a few might want to share one Pipelines and deployables are not global (well, you can have a global pipeline); what to do about that? Should UI restrict from choosing? Who can edit these? Admins only? How else will they behave differently? And then of course, there's the question of how this will tie into the (unspecc'd) "Projects" concept (cross-application releases)

I certainly see the issue. Where this starts to get tricky from a UX perspective is that some folks have long stage, server, and plan names. So, we need a way to better represent this data in a compact view.

Thanks for response. I created a new API Key. My environment IDs are as follows: Development = 1, Testing = 2, Production = 3, Build = 5 If I run the API call you provided above for Build environment, doesn't it mean I will need to resequence the rest of the environments too?

When a Windows Service doesn't start, the reason will be logged in the Windows Event Log. Usually, it's related to an inability to connect to the database. Note that, you can also run the BUildMaster Service interactively to diagnose as well.

This error means that the user running the installer doesn't have access to the database in the connection string in the config file on disk. You'll need dbo access to the database in order to perform the upgrade.

I found the issue. User error on my part. This is a small plan that handles this and I had a Legacy plan doing something similar but not using the Promote API. The pipeline was still pointing to that old plan and I just didn't notice the calls going to Proget. Then I was working on the new plan so as far as I knew it wasn't using the filename but in the old plan it was. Changed to the correct plan and the Promotion worked fine. Sorry for wasting your time on this.

As of v5.6, the "SQL Change Scripts" feature is designed with these principles in mind: Database Changes Done Right. Run once and only once Impossible to be “un-run In order to accomplish this, a metadata table is created in the database (__BuildMasterDbSchemaChanges2) to track which change scripts have already been run. Before running a script, this table is queried. Regarding "resetting" the idea that a script is run, the best bet is to delete and re-add it from BuildMaster. You can also restore that particular database.

The Operation does nto currently support this; ApplyLabelOperation.cs is the source code, so perhaps it wouldn't be too hard to customize?

OK ; in this case, can you provide a simple reproduction case that we can try? Like, a new application that reproduces this? And please send this as a ticket -- Q&A are generally the lowest priority when it comes to support, so we want to handle it through better channels :) The $ApplicatinName and $ReleaseNumber are standard test cases for us, so they do work in our config file replacement tests (which, are quite complex due to so many legacy cosniderations...)

There doesn't appear to be; but we have a new issue (BM-3034) for this. If it's easy to do, we'll get it in ASAP!

Your template can look like this: template MakePair<$First, $Second, out @Pair> { set @Pair = @($First, $Second); } And the plan that uses the template can look like this: set @Fruits = @(); call MakePair { First: Apple, Second: Orange, Pair => @Fruits }

Thanks, I believe this was caused by the anti-virus program. Once I excluded the folder from the scan, the problem went away.

The legacy source provider is available in the same Mercurial extension. As long as the provider has Log command line arguments disabled, the Admin_ConfigureBuildMaster permission is required to see the URL with the password in it. If the username or password has special characters that don't work in URLs, they can be encoded. Common characters that cannot be used in the username/password section of a URL without encoding include: \ (use %5C) / (use %2F) @ (use %40) : (use %3A, but don't encode the colon between the username and the password) % (use %25, but only if the percent sign is part of the username/password and not one of the above replacements)

For most use cases, deployables are mostly a "vestigial" feature; they were very important in v4 and earlier , in that they permitted partial deployments and cross-application orchestration (dependencies, artifacts, etc). Moreover, as organizations are moving towards a "microservice" architecture, the concept of a large application with many depoyables is becoming rarer. In an v5/OtterScript plan, you can do this: for deployable web-application { ... operations ... } In this case, the "current deployable in context" will be web-application, and if that deployable is not included in the release, then the block is skipped. You can also add variable key/value pairs to a deployable. When a deployable is context (as the case above), that variable will be evaluated. With "cross-application deployables", you can have one application reference a release of another application. When doing this, it's changing the release number in context. So, for example, if web-application was imported from another application, then $ReleaseNumber would resolve to that application's number. All that said... all of these things are more intuitively accomplished through variables, and for most users that's just fine. In a new application you create will not have any deployables.