For most use cases, deployables are mostly a "vestigial" feature; they were very important in v4 and earlier , in that they permitted partial deployments and cross-application orchestration (dependencies, artifacts, etc). Moreover, as organizations are moving towards a "microservice" architecture, the concept of a large application with many depoyables is becoming rarer. In an v5/OtterScript plan, you can do this: for deployable web-application { ... operations ... } In this case, the "current deployable in context" will be web-application, and if that deployable is not included in the release, then the block is skipped. You can also add variable key/value pairs to a deployable. When a deployable is context (as the case above), that variable will be evaluated. With "cross-application deployables", you can have one application reference a release of another application. When doing this, it's changing the release number in context. So, for example, if web-application was imported from another application, then $ReleaseNumber would resolve to that application's number. All that said... all of these things are more intuitively accomplished through variables, and for most users that's just fine. In a new application you create will not have any deployables.

Release are used to move packages through a specific pipeline, so you can't really have one with out another unless we realllly change our model. Of course in some scenarios, like the one you described, it feels like an unecessary step. We've considered making a simplified "create release/package", where you can do both in one step... but it's deceptively complex to do that on a single page... and have it behave in the same manner. There are permissions to consider, release templates, legacy variables, etc... >.<

For this, you'll want to use 5.6.0 of the extension; it would appear, it may not have shown up in the Den, so I just enabled it now in case it didn't...

Hi Ben-- This is a fantastic solution, and suits the situation perfectly. Thank you!

Hello Shane, You can add this as a script from Admin → Manage Scripts: param($projectDir, $buildType) powershell -file $projectDir/Resources/tools/PreBuild.ps1 -projectDir $projectDir -buildType $buildType Then, from the deployment plan, adding "Execute PowerShell Script" with that script will give you fields for the two parameters.

In case anybody wants to know, this is what worked for me: SubjectName = the CN (CommonName attribute of the subject in the certificate) Description = the Description in the certificate

Just discovered Kevin's answer here which should work: http://inedo.com/support/questions/4058#inline-post-5062

Turns out that not all of the packages were being included in source control. Once I added in the missing package folders to source control I was able to move forward.

Hello Aris, If you click on the release number (the leftmost column) the user that created the release is displayed in the Details section.

This must be it, redownload solved it. I downloaded 5.6.11 sometime on Apr 4.

Hello Michael, NPM feeds don't currently support an API key, but you can share a single ProGet user between all of the users who need to upload to the feed to simulate the same thing. The Publish Packages task group on the NPM feed is all you need to upload a package. If you want to replace an already-uploaded package, you need the Overwrite Package task, which is available on the Administer and Manage Feed task groups by default, but you can create a new task group with just Overwrite Package on the Customize Tasks page (/administration/security/customize-tasks).

Configuration file versions and database change scripts must be tied to a specific release number, so we create 0.0.0 to associate those. It might be best just to purge that release if you don't really use it.

That fixed it, argh! Been messing with this for hours! Thanks!

Perfect. Now it works as expected :-)

It's cool, I switched to global template to be called. It works fine. Thanks!

Definitely! We're really not thrilled on how the current legacy Actions work (they were built by a third party, and also during a time that Azure underwent so many changes), so we'd like to update them to make more sense and be more useful... We'd love to understand your usecases, and how we can make the BuildMaster/Otter Azure integrations great. It'd be quite a bit easier to do this outside of Q&A though, so let's get in touch via email!

Well, the only code path that will yield that error is if System.IO reports that the file requested is not on disk. The most likely cause of that is that the file is not actually there at the time (obviously), but that might be because anti-virus quartanteed it, a file server didn't replicate it, or something? So, I would try to find what might be causing that file not to be there. The only way that BuildMaster will delete a file (but not the record) is a retention policy.

Correct. Output variables don't need to be specially declared. However, the next version of the Windows plugin for BuildMaster and Otter will add support for [ref] parameters as output variables in the editor.

MaxResponseLength was missing a ScriptAlias. It'll be fixed in the next release.

This has been on the list for a little while, but I finally made a github issue for it. We'll get it soon! https://github.com/Inedo/inedox-inedocore/issues/22