There is no erros in that log.

Thanks. That was the problem. After updating the Windows extension from 5.5.0 to 5.6.0 the powershell command is working again.

The problem is the CpuResetInterval parameter; it is missing the attribute to identify minutes, so it is treating it as seconds. I fixed this here, and it will be fixed in the next release of the extensionhttps://github.com/Inedo/inedox-windows/issues/10 AS a work-around, you can just specify the value in seconds (300 instead of 5). But this will become 300 minutes after you upgrade, so might be best to not set it for now.

A 401 means not authorized; so, you will want to make sure you are using proper credentials and , if you have integrated authentication configured, then it's working for the account using the NuGet push.

BuildMaster runs the PowerShell scripts in-process, so it's not possible. The method you've identified (running a separat eprocess) is the best way to accomplish it I think.

Discussion should be moved to a new post or followed here: http://inedo.com/support/questions/6554

The Release & Deployment API was added in BuildMaster v5.5 so you'd have to upgrade to use it. As for the /api/json page, it shouldn't require a key to view the methods so there's a bug there and I've added that to our internal issue tracker.

Yes. We do this ourselves when we release BuildMaster as the installer relies on the BuildMaster software itself, a few independent embedded extensions with differing release numbers, and also handles releasing a source code package to inedo.com so Enterprise users can download it. The way to do this is to create a meta-application of sorts, and then create deployment plans in that application that create packages or deploy packages for specific releases in other applications. Here are some of the operations that would be useful: http://inedo.com/support/documentation/buildmaster/reference/operations#BuildMaster

This is an internal GIt error, and can usually be resolved by just deleting the local repository (under the TMP\SrcRepos folder).

Is this for a legacy plan action or a OtterScript operation? If it's for a Legacy Plan, you can edit the Configuration Profile for the NuGet extension and specify a path to your custom NuGet.exe in there, and actions will use that instead of the default one the extension ships with -- this way you don't need to overwrite anything. If it's for an OtterScript plan, you can override the default location by creating a $NuGetExePath variable at global or server level with the value being the path to your version of nuget.exe on the server. This is the new style of configuration that replaces legacy Configuration Profiles.

All set. I was just deleting from the webtmp

This appears to be a bug - it should work exactly as you have stated. Our internal issue ID for this is BM-2281 and should be released in the next maintenance (or minor) version (whichever comes first).

The way is correct, but it appears there's a bug in the evaluation while accessing the variable; this will be fixed in [BM-2278], which brought code in from Otter that fixes this bug.

You can Log-Information to see what $WorkingDirectory is. Unless you set a value, it will be something like C:\BuildMaster\_SVCTMP\_Ennn\D0 where nnn is internal identifier of the execution. Log-Information Working-Directory is $WorkingDirectory;

Thank you. The source code makes it explicitly clear what is going on. I was assuming that the OtterScript variables were being parsed out directly from the text input rather than being passed to the PSParser before hand. This also explains my troubles with the List and Map variable types as I was attempting to utilize them inline in my PSExec steps. I would suggest mentioning this parse behavior in the PSExec documentation link text and in the "Inline Script Execution" section of link text

Yes; that behavior was added in v3 because there were a lot of execution collisions (the default working directory used the ApplicationId). This was undesired by nearly all users. The v5 engine uses ExecutionId for the default working directory,, and any collisions outside of working directories should be resolvable with a global lock.

Yes indeed, take a look at Asynchronous Blocks. Here is how you would do it in OtterScript: foreach $value in @list { with async { ... items ... } } await;

I agree whoever owns the event listener, should get the email. What I mean is the default email address doesn't seem to work. E.g., ideally, if I create a event listener, and expect that I should be the one who owns the listener, therefore gets the email, without explicitly putting in my email address to the box again. Currently, I'd have to enter my email address again to get the email, that's kind of unexpected.

There is an open issue with this, [BM-2273] that should be addressed in an upcoming release.