A build is a separate object in Artifactory. You can create one with the Upload-Build operation. Artifactory::Upload-Build ( Credentials: ArtifactoryCredentialsName, Name: builds.json, Version: 1.2.4, Number: 1, Modules: @(%(id: some-module-name, artifacts: @(%ArtifactDefinition)) ); You can get %ArtifactDefinition from Get-Artifact-Metadata or Upload-Artifact.

There is a setting on your pipeline; if you edit the pipeline settings, you'll be able to uncheck that option. Note that, we'll be handling this in a different manner in a future version (post-deployment OtterScript plans) with the Create Release operation; but of course, you could do this today at the end of your production plan, or as a new target/stage in your pipeline.

We'll be handling this in a different manner in a future version (post-deployment OtterScript plans) with the Create Release operation; but of course, you could do this today at the end of your production plan, or as a new target/stage in your pipeline.

Hi Megha, Ensure application dont have selection of appPool right now, may be you can try create a powershell like below might solve your problem for time being. param( [parameter(mandatory=$true)] $iisAppPoolName, [parameter(mandatory=$true)] $iisAppName ) Import-Module WebAdministration #gets the iis application name $iisApp = get-item 'IIS:\Sites\Default Web Site' if((Test-Path ("IIS:\AppPools" + $iisAppPoolName)) -and (Test-Path ("IIS:\Sites\Default Web Site" + $iisAppName))) { #set the app pool to the application #Set-ItemProperty IIS:\Sites'Default Web Site'$iisAppName -Name applicationpool -Value $iisAppPoolName Set-ItemProperty -path IIS:\Sites'Default Web Site'$iisAppName -name applicationPool -value $iisAppPoolName -Force Write-Host $iisAppPoolName“ configured to web site: “$iisAppName } else { Write-Host "The App Pool/site does not exists" -ForegroundColor Yellow Write-Error "Failed to add application to the app pool" exit } Thanks, Srinivas

Thanks Alana, [EDO-2856] has been raised. Thanks, Clint

Because this error is coming from MSBuild (a third-party tool not written/supported by Inedo), your best bet will be to search for that error code, and follow those instructions. Google Search: MSB3884

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; }

Sounds like the service is crashing because of connectivity problems with SQL Server; this is expected behavior, as the service cannot operate without a database and will crash if it can't be reestablished after a few tries. This is why it's not logged in BuildMaster's error logs (as those are stored in the database). You could see it in the Windows Event Log however. Short of fixing connectivity problems, you can just set service to auto-recover.

Just pushed another version; let me know if that one has any other issues.

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.

Thanks all, it seems the problem with the extension. One thing I've observed is the extension is not working for 5.6.5. As we end up in upgrading the buildmaster to 5.6.11 then it started working.

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.

It's certainly possible in BuildMaster, but it's not a common workflow anymore. We have considered extending support, but the market generally is moving towards "many single-purpose tools" than "multi-function tools". The general flow these days looks like this: Source >> CI >> Package >> Deploy In this case, ProGet is the Package repository and BuildMaster is the deploy tool. The advantage to this workflow is that, the CI tool need only "create a validated package", instead of trying to deploy. By the way, I also recommend you to look at GitLab; we switched to it after extensive evaluations of similar "simple" tools (GitHub, BitBucket), as well as the enteprrise tools (Perforce, etc).

This is currently on our roadmap

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.