Hi Matt, If it's not too much trouble, what time did the executions start in the stage that unexpectedly succeeded? It should say in the Deployments section of the package page. (I'm mainly wondering if they started on the same second or on different seconds.)

Thanks Ben! it works now

There are some bugs using map variables within OtterScript in v5.5.3; these have since been resolved.

Thank you for the report - this issue (BM-2370) was fixed in a later version.

Currently variables are not evaluated in pipelines. I'm not exactly sure on the pipelines/application setup you have, but you might be able to get away with using the Variable Value Promotion Requirement which forbids deployment past a certain stage if a Package Variable named IsReleased is not true. Combined with the Set-ReleaseVariable operation in the plan assigned to the release stage, you should be able achieve what you want, e.g.: Set-ReleaseVariable( Variable: IsReleased, Value: true, Release: $ReleaseNumber, Package: $PackageNumber );

We don't support doing this sort of tweaking on the ProGet database; it might work, but we don't test it so I can't say.

The release/deploy API is secured by API keys, not by username/password. When you configure an API key, you can determine which access that API key has. Treat those API keys like passwords, and share them only with people you trust.

That is the requirement; the installer requires SQL_Latin1_General_CP1_CI_AS collation in the database, so if it's not that (and the installer can't change it), you won't be able to install ProGet.

The FTP extension can help with this

If you want to extend the life of that directory so you can view it in process explorer you can do something like this in the deployment plan: with async { Git-GetSource( # ... ); } with async { Sleep 1000; } await; That will keep the directory around for long enough to examine the file locks, and the deployment can be cancelled when finished.

The NuGetExePath variable is used by the NuGet operations (like Install-Package). So you would need to use that ahead of MsBuild, and then not do the NUGet restore in your msbuild. Your MsBuild script most likely hard-codes a path to NuGet.

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

Hello Megha, In PowerShell, to create a JSON object key with a dollar sign in it, you need to use this syntax: "`$KeyName" So your object would look like this: $CreatePackageParam= @{releaseNumber=$ReleaseNumber; applicationName=$ApplicationName; "`$SiteName"=$SiteName; } Otherwise, PowerShell replaces both instances of $SiteName with the value in that variable.

You are using it correctly; there is a bug in that particular endpoint that ignores the variables for non-legacy plans, see: Issue BM-3077

See: https://stackoverflow.com/questions/45063717

Hi Megha, Per the Release & Package Deployment API, you must POST or PUT to this url. On the Invoke-RestMethod CmdLet, you specify this using the -Method argument. $response = Invoke-RestMethod 'http://<<BuildMasterServer>>/api/releases/packages/create?releaseNumber=1.0.2&applicationName=DeployWWMapping&key=5WRTeJcctiY32u2bEqTb4Q==' -Method Post

I was trying the Otter instructions link provided by you. When we execute step 4 and try to execute command: “InedoAgentService.exe install” We get the error message saying that InedoAgentSVC already exists.. attempting to uninstall it. Which means it first removed the already existing and running InedoAgentSVC and then created the same again. But it could not install it since I checked in services.msc and there was no such service(i.e, the already existing service was gone). I tried to do it as below as well: Since the InedoAgentSVC(Inedo agent service) had already uninstalled, I tried to install it again but this time with different port(used 8080 instead of 46336) so that we can use port 46336 for second agent installation as per otter instructions. I changed the port for Inedo agent and the service was installed successfully but its name was still InedoAgentSVC, so I tried to change name of service to InedoAgentSVCMain in app_appsettings.config and installed the Inedo agent again. It did not get installed and threw error. The point that comes out is that both Otter and Inedo Agent generate same service with name InedoAgentSVC. If we install either of these and then try to install the other one, the first one gets uninstalled. So as a conclusion, we can have only one of these agents in a machine. Please let me know if I am missing something or some step as I am still not able to use multiple agents on same service box.

In Properties, @(type: txt, sha1: <sha1 value>, md5: <md5 value>, name: Artifact7.txt) should be @(%(type: txt, sha1: <sha1 value>, md5: <md5 value>, name: Artifact7.txt)). If you're more used to JSON, those are equivalent to ["type: txt","sha1: <sha1 value>","md5: <md5 value>","name: Artifact7.txt"] and [{"type":"txt","sha1":"<sha1 value>","md5":"<md5 value>","name":"Artifact7.txt"}], respectively.

Hello Megha, That URL looks correct. Are you doing a POST or PUT request, or a GET request? If you're visiting the page in your browser, that's a GET request and it won't work. Either POST or PUT will work, though. You can use a web hook to automate this through TFS.