Topics created by jstarbird_7831

I see what happened, I looked under Servers where I would have thought that info would be but instead it's under General in the docs.

The fix for this is included in the latest release of BuildMaster (v5.8.1).

I should clarify my last post, it does a Return Select 0 only when it is successful.

Thanks for the reply. I didn't really think it was BuildMaster itself since I can deploy other smaller apps to the same server, same main web site, without issue. This particular app has a lot of files so I was somewhat suspicious of BuildMaster, memory, Windows or combination thereof having some issue with that large number. I am continuing to debug it and we have been looking at couple of possible issues. One thing that did come is a possible incorrectly registered DLL. Our IS dept had been registering it under the apps folder rather than the Windows/system32 folder but it's not certain that the one is this particular folder was the one registered. Unfortunately this is a live server so I have to use caution as to what I do on it.

Ignore. Someone had modified a property value incorrectly when combining two variables which was causing the Virtual Path to be invalid.

Try: set $regExists = $PSEval("Test-Path $regPath");

That type of difference is understood. Someone here asked me about it so I just wanted to clarify what should be expected as it was not clearly defined in the documentation as to what differences it would be reporting. Thanks.

Another option to consider is just defaulting to the BuildMaster Server time zone. At least for us that is the same as the Jenkins system. So use that as a Default but allow a setting in the Artifact Deployer if someone needs to be different.

Pipeline variables are considered Configuration Variables, not Runtime Variables. When you use the Set Variable Value statement, you are creating a runtime variable in the current scope, or updating a runtime variable in the current or parent scope. If you want your scenario to work, you would need to do this... #create a runtime variable from $pipelinevar1, which will resolve to configuration variable set $pipelinevar1 = $pipelinevar1; # update runtime variable created in above scope { set $pipelinevar1 = somevalue; Log-Information value is as set here: $pipelinevar1; } #general { Log-Information value is as set in pipeline here: $pipelinevar1; }

Unfortunately it's a bug in IIS/COM API Library. There is no resolution, it "just happens" sometimes. On some servers, especially older ones, it seems to happen more frequently. Rebooting tends to fix more persistent ones. if it's an issue, then just put in a retry loop with a timeout.

Follow up question, would the file that is in the artifact already have had the key pairs replaced when the artifact was made? And do I need to deploy the config file first and then make the artifact or will it just automatically be part of it? What I'm needing to accomplish is deploy it using the same way if possible without having to replicate storage of the config in different apps. So replacing the key pairs under the new app if possible. I know it would make more sense to make it part of the original apps but I cannot here because this is strictly on-demand deployments and we want to keep the restrictions on the pipelines requiring deployment to stages in order for the real apps.

lol, boy I really need to quit doing 5 things at once. Thanks for the answer Ben. Thought you were answering another one I posted that I had meant to close. Going to drink my coffee now and hopefully wake up!

You can ignore this post. I can get my info from the API.

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.

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.

We anticipate the end of this week or early next!

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.

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!