Warn will still automatically advance. I was able to utilize the Set-ReleaseVariable as you suggested. Thanks!

Hi David, It appears that only the start of a statement block shows in the execution log.. # Visible in execution log # This is not bisible in execution log { } # Visible in execution log # This is not visible in execution log { # This is not visible in execution log } # not showing in execution log Let me know if you have any specific examples that aren't working as expected. Here is the full documentation for OtterScript comments https://inedo.com/support/documentation/executionengine/otterscript/comments-and-descriptions Thanks, Jason

Hi David, You can view the results of a monitor that triggers a plan in the Admin > Executions page, filtering by "Build Trigger". You can also add some hack debugging to the plan that logs the built-in monitor variables to a file so you can see if it's triggering. If it's still not triggering, try configuring the monitor to a public instance of something on GitHub like https://github.com/Inedo/git-test.git to see if that works since GitHub supports the SVN protocols as well. Hope this helps, -John

After looking into this issue further we have determined that sequentially ordering the parameters will resolve the issue. Thanks, Jason

FYI this has been added (in Subversion extension v1.1.0) and the available variables are documented here: https://inedo.com/support/documentation/buildmaster/builds/continuous-integration/source-control/svn#automatic-builds-continuous-integration-with-subversion

Schedule Triggers haven't been replaced; we only really consider those legacy because of the way the variables are handled by them. See also: https://inedo.com/support/questions/9736

Thanks, I've filed this as a bug here: BM-3307

That worked great. Thanks!

I've come across this too... but I'm pretty certain it's not going to possible. In the visual editor, all properties all text boxes that are blank by default (which means, not specified), and any characters in those boxes are always escaped ("" would become "\"\""). I made a variable function called $Empty that just returns "". Maybe I'll submit as a pull request to InedoCore...

It doesn't, but I think we should add it to the Release & Package Deployment .. so I added BM-3149 So, it will come in a future maintenance release, since it's additive and seems to pose minor risk.

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

Definitely; this feature is certainly slated for redesign, to bring it more in the line of a "scheduled job" concept, and unifying implementation across our products (ProGet, Otter, Hedgehog as well). This concept of "don't run this job if an execution associated with this job is currently running" is how it could be implemented/described I suppose

It's just an unfortunate mix of terminology in "promotion" vs "deployment" vs "execution". A "promotion" is simply allowing a package to be deployed to the stage and should only happen once per release. A "deployment" can happen anywhere but may be restricted by pipeline settings depending on if the package was previously promoted, and an "execution" is essentially the worker that performs the deployment (and there could be many per deployment). The fix will make it perform a deployment instead of a promotion then a deployment, so it will work as you're expecting.

Tod - thanks for the reply. We would definitely be interested in this feature in an upcoming release. Thanks.

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.

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

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

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.