We have responded to this via the ticket you submitted, can you verify that you received it? Today we switched to a new automated ticketing system and I want to verify whether you received an email update or not from the system. Here was the response: In BuildMaster v4, these are configured on the Admin > Extensions > Source Control Providers page for the specific provider in the URL of the remote repository itself, e.g. https://user:pass@example.com/remote.git

This has been added as BM-3004, and is currently scheduled for 5.6.10.

That operation looks exactly like what I am trying to achieve. What is the behavior when all of the servers in the pool have been acquired? Does current execution wait or does an error get thrown?

We anticipate the end of this week or early next!

Don't use that, use the Variables API instead.

For re-use: https://github.com/rockpooldigital/bmx-testresultssummary Cheers again, Jamie

If you call $PackageNumber with no arguments, then the curent one in context is returned. The arguments allow you to find a package number for another release in potentially another application.

Your best bet would be to simply wrap the deployment plan that gets called in a "if $RestartServer". I agree about visibility of skipping, but it's not supported at this time.

We'll add this, likely as a separate endpoint i.e. api/releases/create-from-template or something like that. It will appear as BM-2384 in the release notes (likely before it is actually documented on inedo.com).

The extension should be available now.

Well, so that's basicaly the idea of a deployable; you could have a web deployable and a database deployable. Of course, the same pipeline is used, but you use a for deployable xyz block to determine whether particular things execute. You could use this, in combination with pipeline targeting, to accomplish this. They would still follow same linear pipeline path, but some stages would only deploy one or the other. Otherwise, you can use multiple applications, and then the create- and deploy-package operations. Down the line, we will have multi-release projects that allow you to tie together multiple releases of multiple applications.

It looks like running a pipeline on a server role does not correctly set the $RoleName variable. I've filed this as BM-2381 and it is fixed for the next version of BuildMaster.

It's hard to say; 4.6 is quite old, so of course I recommend to upgrade so that it fixes any issues that might be there. But even in 4.6, the action just wrapped the commandline. So, t's about finding what and how the commandline is being used with the parameters you're specifying... You should be able to find the code on an old release here -- http://github.com/inedo/bmx-windowssdk

Thanks. That of course fixed it.

Yes, that is what I'm looking for. Sorry I didn't say it that way but I didn't think that was possible based on the docs, I thought having the sub-types like that was only in the maps. I tried that out and it works perfectly for me. Thanks!

Hi Jason, there's not currently... but I've added a request to get this in a maintence release under BM-2374 @ConfigurationFiles([AppName]) @ConfigurationFileInstances(configurationFileName, [AppName])

That is exactly what I was looking for. Thank you.

I found the issue, just didn't think about looking at the IIS settings but that clued me in. I needed to use Windows authentication via Powershell. For those that might hit this in the future this is the piece of code that did the trick: $pwd = ConvertTo-SecureString $userPwd -AsPlainText -Force $creds = New-Object System.Management.Automation.PSCredential($userName,$pwd) $Response = Invoke-WebRequest -URI $URL -Credential $creds

thanks, yes I saw that and that is what I am using. I guess the expectation I had was to see the description or synopsis in the dialog when I am adding it a plan. Once it's in the plan is useful, the way it displays now, but it's when it's being added that the person adding it needs the info. I'll just submit a feature request, it's not a major thing just be nice for people who use them later and may not know exactly what they do without opening the full script itself or reading some other doc outside BM

By default, all you need is the name. The following operations are equivalent: Deploy-Artifact my-artifact-name; # and... Deploy-Artifact my-artifact-name ( To: $WorkingDirectory, Application: $ApplicationName, Release: $ReleaseNumber, Package: $PackageNumber, Deployable: $DeployableName, DeployAsZipFile: false, TransferAll: false, DoNotClearTarget: false, Verbose: false ); This should be mentioned in the auto-generated docs but since it is not, I'll put in a note to do that :)