@mness_8576 thanks! We definitely welcome feedback on the UI/UX - this is a new feature, so there's a lot of room to improve :)

Hello Dan, Exactly what I needed. Thank you for the prompt reply! Mikhail R.

The fix will be part of that (it was actually a regression in the Pipeline picker control which is on both of those pages).

Hello Rob, I've released version 1.0.1 of the TeamCity extension, which should fix this (or at least give a more sensible error message). It should be available in /administration/extensions.

We use to have a script that auto-unlisted everything. After we switched to the paid version, we found that just using retention rules to clean up pre-release packages after a few days that haven't been downloaded worked a lot better.

It does purge the packages and logs, but the artifact files themselves are only purged by a Purge Artifacts policy. This behavior is a little confusing I think - we may change it for v6 (by adding an option). For now you can work around it by adding a purge artifacts policy too, and either creating it before the other policies (they are run in the order they are first created), or checking the option to "purge orphaned artifacts," since an artifact file would become orphaned if its associated release package has been purged from the database.

I believe there was a fix for this (issue: BM-2392 - FIX: Variable bulk edit for releases and release packages checks for Admin_ConfigureBuildMaster task instead of Releases_Manage) in v5.6.9

Thanks Jon! This is not an uncommon pattern, it's something I call the "quasi-custom software" problem. I.e. you have a "small" number of customers (dozens not thousands), and each customer gets (1) small customizations to a common platform, and/or (2) customer-driven testing and rollout scheduling. In BuildMaster, I have seem both patterns; the "customer per app" seems to work the best when you need individual workflows and customizations, and then you can just deploy artifacts from the "core" app. Having seen this problem for many years, I have yet to see any tool that will "properly" model the situation; Octopus does have an interesting "multi-tenant" feature, but it's not so well suited for individual maintenance workflows. In my mind, this is a key benefit to the "quasi-custom software" model that companies like yours provide. That said, I think we will have definitely have better handling for this in our next generation of tooling (i.e. Hedgehog). Projects will lend better to sharing than applications, and one of our usecase for nested projects will be grouping customers in this manner Universal/romp packages will be able to be bundled, allowing for an easy conceptualization of the "quasi-custom" code as well It's not a huge departure from BuildMaster now, but it will just be much easier to handle I think!

That's great news. Thanks!

Ben, That works. Thank you! TLDR; don't use "MultipartFormDataContent" when making this request.

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.

I like the idea, but of course there's definitely some questions and things we'd need to think about before we can spec out the feature. Just some initial thoughts... Should this really apply to all applications, seems only a few might want to share one Pipelines and deployables are not global (well, you can have a global pipeline); what to do about that? Should UI restrict from choosing? Who can edit these? Admins only? How else will they behave differently? And then of course, there's the question of how this will tie into the (unspecc'd) "Projects" concept (cross-application releases)

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

Don't use that, use the Variables API instead.

Your best bet would be to simply wrap the deployment plan that gets called in a "if $RestartServer". I agree about visibility of skipping, but it's not supported at this time.

There is no way to configure that in the schedule, but you can somewhat accomplish this by either: setting the filter to "newest active release" and moving the release to the top on the Release Sequence page or, if you don't mind multiple failed builds in your release, setting the filter to "all releases" and filtering at the top of the build plan, e.g. if $CompareReleaseSequence(!=, $ReleaseNumber, $DesiredReleaseNumber) { Log-Information `$ReleaseNumber is $ReleaseNumber, skipping.; fail; }

You could just bypass it on the promote page, by selecting "Do Not Execute" and then override the promotion status to Successful. That might be sufficient? Otherwise, we don't have a good way to evaluate whether or not a pipeline stage should advance. Perhaps one idea would to use a variable for targeting? or maybe a (JSON-only) option that says "skipStep" or something that you could have a $Variable as. Just ideas, not sure if they're feasible!

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

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.