I think one approach you could take would be to utilize the Native API which, using your example, could be found at https://example.com/reference/api. You could call the Pipelines_GetPipelines endpoint, filter by "Active_Indicator" == true, then parse the "Pipeline_Configuration" xml for each pipeline looking for the "PlanName" attribute of the "Properties" element under the "Inedo.BuildMaster.Pipelines.PipelineStageTarget" elements. Here's a snippet of the "Pipeline_Configuration" I get back when I run this, to get a better idea. <Inedo.BuildMaster.Pipelines.Pipeline Assembly="BuildMaster"> <Properties Name="All" Color="#499e8d" Description="The pipeline that deploys to all environments on all stacks. " EnforceStageSequence="False"> <Stages> <Inedo.BuildMaster.Pipelines.PipelineStage Assembly="BuildMaster"> <Properties Name="Build" TargetExecutionMode="Parallel" AutoPromote="False"> <Targets> <Inedo.BuildMaster.Pipelines.PipelineStageTarget Assembly="BuildMaster"> <Properties PlanName="Main-Build" EnvironmentName="BuildFarm" DefaultServerContext="None"> <ServerNames /> <ServerRoleNames /> </Properties> </Inedo.BuildMaster.Pipelines.PipelineStageTarget> </Targets> From this you can see I have a Pipeline named "All" that has a stage named "Build" that calls the plan "Main-Build".

Found the follow-up issue as a user error. After upgrading to 6.0.x the feature worked as expected.

Blindly ignoring certificate validation in an orchestration tool such as BuildMaster is not recommended; basically it allows you to transfer secrets and other sensitive information to a machine that isn't what you think it is. as such, we don't have it as a checkbox or option. Instead, your better off resolving the certificate validation errors. Typically, you just need to make sure you have a self-signed certificate installed on the BuildMaster machine. If you can share more details about the configuration, we might be able to provide some more guidance on configuring certificates --- but I'm not sure how things are configured now, so it's hard to be more specific! Hope this at least helps a litte..

Hi Josh, Sorry, this seems to be a v6 glitch! But we're on it :) I've submitted BM-3192 and then inedo-docs/#6 to update our documentation. Your understanding of how the feature is supposed to work is correct, and your use-case is how it's supposed to be. Thanks for reporting it !

In this case, it seems like your machine has no internet access, and can't request a key from my.inedo.com; you can do it manually from that website.

Are you sure you're using the right server context when calling the BuildMaster Powershell Asset? If you print out the server name in your asset using $env:computername do you get back the expected server? If I create a simple plan ##AH:UseTextMode for server $MyServer { PSCall GLOBAL::Test_Powershell_Asset; } Where my powershell asset is defined as this one-liner Invoke-Expression C:\Path\To\PowerShell\script.ps1 Then I am able to run this script, no problem.

Hi Paul, Your best bet would probably be to use Role Dependencies - the parent role would ensure that the module is installed: # Parent Role PSEnsure ( Key: InstallDSC, Value: 0, Collect: "if(Get-Module -Name cNtfsAccessControl -List -ErrorAction SilentlyContinue) { exit 0 } else { exit -1 }", Configure: install-module -Name cNtfsAccessControl -Force, UseExitCode: true ); Then, in the dependent role, you can safely use the module: # Dependent Role PSDsc cNtfsAccessControl::cNtfsPermissionsInheritance ( Otter_ConfigurationKey: ApplyPermissions_Key, Path: c:\temp, PreserveInherited: true, Enabled: true ); Note that this usage of Role Dependencies will require Otter 2.0.8 or later. In any case, if you don't want to or can't use Role Dependencies, you can simply put the PSEnsure operation inside an alwaysExecute block. Does this help?

Hello; I've added a feature request for this. There is no ability to do a "mass edit" like this I'm afraid.

Hello Paul Here is the powershell script we are using. It is running from the server as a part of our init server script. We deploy the Otter/BuildMaster Agent and we run the script . Hope this help Regards Philippe Param( [Parameter(Mandatory=$false)] [string]$API = "https://#OTTERHOST#/api", [Parameter(Mandatory=$false)] [string]$SERVEUR = $env:computerName ) #end param # Extract AESKey [xml]$XmlDocument = Get-Content -Path "C:\Program Files\InedoAgent\InedoAgentService.exe.config" $AESKey=($XmlDocument.configuration.appsettings.add | where-object {$_.key -eq "EncryptionKey"}).value # # Grab list of registered server # $URI=$API+"/infrastructure/servers/list" $aListServer=Invoke-RestMethod -Method Post -Uri $URI -Headers @{'X-ApiKey' = '********************'} if ($aListServer.Name -contains $SERVEUR){ # # Mise à jour # $URI=$API+"/infrastructure/servers/update/"+$SERVEUR $body = @{ name="$SERVEUR"; hostname="$SERVEUR"; active=$true; serverType="windows"; port="46336"; encryptionType="AES"; encryptionKey=$AESKey } }else{ # # Creation # $URI=$API+"/infrastructure/servers/create/"+$SERVEUR $body = @{ name="$SERVEUR"; hostname="$SERVEUR"; serverType="windows"; active=$true; drift="automaticallyRemediate"; port="46336"; roles=@("Baseline"); environments=@("Integration"); encryptionType="AES"; encryptionKey=$AESKey } } # # Appel de l'API # Invoke-RestMethod -Method Post -ContentType 'application/json;' -Uri $URI -Body (ConvertTo-Json $body) -Headers @{'X-ApiKey' = '********************'} #

I found a solution. I had to change the pipeline to not restrict the order of the stages.

I believe the issue is related to the "Execution in Progress Page", which is the "live view" page of the execution, and shows logs like a big textbox. The slowness seems to be more related to client interaction, at least in our exploration. So we have decided to limit this view to previous ~500 entries in v6; you will notice a big improvement for such large log, and can see full details in the details page.

Thank you so much for your answer and the confirmation for a futur support of Black Duck. I will contact you once we are ready to work with you (ProGet solution is in planification and installation phasis here). Thanks.

As of V6, we no longer bundle SQL Server. The links should be updated, but they are all the same. There is just one installer now. SQL is now downloaded during install.

Hello Rob, I've released version 1.0.1 of the TeamCity extension, which should fix this (or at least give a more sensible error message). It should be available in /administration/extensions.

Not really I'm afraid... "Pulling with dependencies" would require implementing every dependency resolution algorithm of every version of every client, including the non-deterministic dependency resolution used by the npm client, and then somehow letting you select the algorithm version and the additional contet required by the algorithm (such as .net framework target versinon).

I discovered one more error detail. BuildMaster logged an error that it couldn't use the folder (for the "get latest" copy on the build server) because it belonged to a workspace for a different account. I believe this is because I changed from using a domain account to a local account on the TFS server machine for the TFS connection from the BuildMaster machine. I deleted the workspace for the previous account. I edited the TFS connection in BuildMaster, entered the account information for the local account that I am now using, and saved it without doing a "Test Connection". Now, everything seems to be working okay. This installation of BuildMaster has been through many upgrades. Maybe someday I will do a full uninstall and a clean install of the latest version, and build new applications in that version, etc. If anyone needs to know, I found (and then deleted as needed) the TFS workspaces as follows (this is using TFS 2017 and Visual Studio 2017). On my workstation with Visual Studio 2017 installed, I ran the "Visual Studio 2017"-"Developer Command Prompt". This opens a command prompt window with all the appropriate environment variables set to allow the "TF" command to be used. Then, run: tf vc workspaces /owner:* /computer:* /collection:"http://URL-for-TFS-collection/" to show all the existing workspaces (this shows username and workstation as well). To delete an existing workspace, use a command like this (note that this uses the singular form "workspace" where the previous command uses the plural "workspaces"): tf vc workspace /delete /collection:"http://URL-for-TFS-collection/" WORKSPACE-NAME;USERNAME-for-the-workspace This will let you know if there are any pending changes in the workspace, and ask if you are sure you want to delete the workspace.

The latest version was incorrect in the Den -- the latest cross-product TeamCity extension should be v1.0.0, and its legacy counterpart extension (i.e. TeamCityLegacy) should be v6.0.0. If it doesn't appear on the extensions page in BuildMaster, you can download and install it manually from here: https://inedo.com/den/inedox/teamcity If you go the manual route, note in the manual installation instructions it says the file extension is ".inedox", while in this case it is actually ".upack". Make sure there is no TeamCity.bmx or TeamCity.inedox in the extension path (TeamCityLegacy.bmx is OK if not a fresh installation of BuildMaster).

There are three things that will cause this: Service not running Service doesn't have full control over drop path packages in drop path are invalid You can check the message center and see if errors are occurring.

Yes, here is the tracking issue: BM-3165