In v5.4, we will have a "Custom Setter" for template variables which would allow for this scenario. Our primary use case is to allow for a searchable list of packages from ProGet, or builds from teamCity/Jenkins/etc to be populated.

Yes, it's posible, and that's a common workflow; there are operations to do all of these things. I would try to follow the [BuildMaster tutorials])(/support/tutorials), some of them have some workflow similar to what you're doing. The other things (like SEnd Email, Execute SQL Scripts) are just differnet types of operations you can run during a plan.

If the JIRA release operation should happen anywhere other than when the release is deployed in BuildMaster (i.e. using the event listener), you'll have to add a custom action or use PowerShell, etc. Alternatively you could fork https://github.com/Inedo/bmx-jira and add it that way, here is the tutorial for that: http://inedo.com/support/tutorials/cloning-and-patching-an-inedo-extension

Thanks, I'll add this as a feature request; there should be a link on the "perform manual action page" that links to the execution, but you can see all current executions on the home page dashboard.

Great! Thanks for the quick turnaround.

The page was changed in v4.8.2 to only show the first 30 releases for perf reasons, so if you have more active releases than that, the list would be truncated to the first 30 ordered by when they were created. We're open to making this behavior configurable instead of a strict limit of 30.

That should be OK - just note that this will update all workflows in the system to have this behavior.

FYI- 4.6.4 has been released, and this fix was included.

Executed with output of: (1 row(s) affected) (1 row(s) affected) Will let you know if I see any more problems like this, Thanks for the incredibly fast turn around time!

Unfortunately that is a limitation of the v3.X line of BuildMaster - releases were ordered and meant to be built on top of each other, e.g. once version 5 goes out, it is meant to encompass everything up through v5. If you were to upgrade to the 4.X line (make sure to read all the upgrade notes first), then you can actually re-order releases as necessary, and allow other advanced workflow options.

Just to follow up, got some help from the inedo folks and we discovered that the server hosting the sql server database had its system clock slightly off which was causing the delay till the start of execution.

It sounds like this is a bit of a hack; when an application component is deployed to a production environment, it's status should be represented as "Deployed". You can purge releases if needed using the Releases_PurgeReleaseData API/Sproc method.

This sound like it's just a tough process to model. No matter what you do, you can't have it both ways such that you could deploy to either a subset of DevX servers to an arbitrary subset of QAX servers. The options you'll have to decide on are either: use different workflows and different environments to separate Dev1 from Dev2, which will force releases to use a specific set of servers after a build is created for it use abstract environments (Dev, QA) with server variables that resolve to different server groups (e.g. DevSet1, DevSet2, or whatever), and select the result either at release, build, or promotion time so it provides historical context with the release/build In BuildMaster, the idea of an Environment (i.e. a different stage of testing) is meant to be abstracted from a Server (i.e. a physical/virtual machine), so whatever follows most closely to this paradigm would be the way to go.

I went to the Releases table and fixed it by hand, and the sequence is correct now. Thanks.

Once created, a Build Release may not be deleted from the UI; this is an important part of the auditing/workflow pieces. There are three options: Clone application - http://inedo.com/support/tutorials/cloning-an-application-with-the-sql-api - this is least risk, but will not copy histories Undocumented Releases_PurgeRelease method; this is generally used for accidently created releases, and will cascade to all builds/promotions/executions/database changes/etc Delete from database tables directly more risky The first is preferred.

Thanks for the update; we do plan on supporting this soon once a particular feature ("Release Archiving") is introduced. In the mean time, we can at least change some of the procs/funcs/etc that are crashing. If you can send us a backup of your database (support at inedo dot com), we could use that as a starting point and get a patch to you very soon. If you need to scrub sensitive data, this will do it: DELETE BuildExecution_PlanActionLogEntries UPDATE Providers SET Provider_Configuration = NULL UPDATE PlanActions SET Action_Configuration = NULL But it will also ruin your database, so obviously only do that on the database you'd send us :-)