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

This was definitely fixed in a newer version of BuildMaster, though I'm not sure which one specifically.

This was a regression in 5.5.2, but will be fixed in 5.5.3 (shipping later today) As a work-around, you can use text-mode to invoke PSCall

That behavior definitely sounds suboptimal; we will investigate a bit further!

So being new to BuildMaster I was just restarting the windows service rather than using the site to stop the service. Admin > Manage Service :> Stop then Start fixed it.

Hi David, this is on our roadmap-- calendar views for things like this.

Hi Mike, For GitHub, that source control path doesn't look right. It shouldn't have the ".git" in it. Are you using the [...] selector? That should provide for a proper source control path.

You can use the Execute-LegacyAction Operation to do this; it inputs the XML-based configuration of the action. The easiest way to get this XML is to create a legacy plan with the desired action, then convert to OtterScript.

This is working as designed*, as a user can still approve the package even if there was a failed target. We have been thinking of ways to improve this (events / notifications in general, across the products), and will likely add something a lot better on the roadmap. [*] which is not to say the design needs work :)

We plan to add a variable function (such as @GetLogs) that will return error logs from the current scope, so you could then do whatever with them (email, post to Slack, etc). Regarding "how do I stop the next action from being executed", this is the behavior of the execution engine. See Action Statement in the formal specification: "8. If an exception occurred within one of the above methods or a log message was written with an error level, then the execution state will change to Failing and an error will be Raised"

Well i finally was able to publish to our Powershell feed. I updated the PackageManagement and PowerShellGet modules to version 1.1.0.0. which were released a few days ago... 12 Oct 2016 I hope this helps .

That doesn't sound right for a default obviously; I've opened [BM-2256] to investigate further. It's possible it happened during an upgrade of some sorts. In the mean time, you can safely exclude that.

Oh ok, I thought it was done by you. I'll pester him about that then. Sorry about that. Thanks, Jon

I suspect the two messages are unrelated... but unfortunately it's really hard to know what would cause the first problem. 99% of the time, especially over long-running things like this, it's a result of problematic network connections. The new Inedo Agents (available in v5) are a bit more resilient to this.

Finally got it working, turns out a single quote at the start and end of TextData is enough for the configs to be fully included without error, while still accepting BuildMaster parameters, Here's the code in case there is a desire to implement Job creation in the Jenkins extension, (anonymized a little): Post-Http http://Jenkins:8080/job/TestNewAPIJob/config.xml ( ContentType: application/xml, TextData: '<?xml version="1.0" encoding="UTF-8"?><project> </project>', LogRequestData: true, LogResponseBody: true, RequestHeaders: %(Authorization: Basic xyz123) ); Thanks for the help getting this going, this was my first time using 5.3 from 4.7, little learning curve with the new Plan editor that is really cool! -Dan

If the files contained in a zip being transferred as a whole, shouldn't they be appearing almost all at once? It's like downloading a file from your browser... the files are sent are written to disk as they are being streamed. Unfortunately, sometimes the .exe files is relatively large that their size increases gradually, therefore probably locked by the anti-virus tools while the deployment is still going. That could happen; it's possible the AV tool is acquiring a lock between chunks. In this case, your best bet would be to disable the AV tool or, if not possible, then use the zip method you described.

This is handled by Release Package Variables within a Release Templates. They work basically the same, except now you can create multiple sets of required variables, depending on the template chosen at release time.

The issue turned out to be a problem with uploading the package to ProGet. ProGet was reporting the package was available in our feed and we were able to download the package through the website however the package was not available through the nuget feed. Deleted and re-uploaded the package a couple times and it finally took. Issue resolved thanks to help from Inedo's great support team! Thanks!

I would suggest to use the "Run MSBuild Script" Action instead. Then you can specify any of the properties.

We had considered this as an option when designing templates, but decided against it because of the additional complexity required. The main challenge being, a user with Releases_Manage can already change the pipeline (or any other attribute) on an existing release. Making a "restrictive" template be a securable feature would require new permission attributes (and thus be more confusing/frustrating to use), and making it a convenience feature would give it the appearance of security (which is also bad).