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

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

I was finally able to reproduce this - I had been using v5.5.0 of the Windows extension which does not exhibit this behavior. We will have a fix for either the Windows extension, BuildMaster or both shortly.

https://github.com/PowerShell/PowerShellGet/issues/76

Hello, I was not able to reproduce this. Here is what I did. Create a new PowerShell Asset... Name: Test Script Parameters: none One ambient variable: MyEnvVar ==> $EnvVar Contents : Write-Host My var is $MyEnvVar; Create a variable on MYSERVER: $EnvVar = my server var Create a new application with a deployment plan that has a single action (targeting MYSERVER) that calls Test Script Output is My var is my server var, as expected I also deleted $EnvVar from the server, and then created it on an environment the server is associated with, and it works as expected. When I deleted $EnvVar from the environments, it produced the literal output (My var is $MyEnvVar) upon running. So, my guess is there's a typo somewhere... best, Alana

Just letting you know that we have added a feature to BuildMaster 4.8 that we're calling Ambient Script Variables that should solve this problem. Basically, it allows you do define script variables that BuildMaster will evaluate and assign before running a script. So, in your case you'd just add one called ReleaseNumber that contains the value $ReleaseNumber (the value can evaluate to anything though, and use any variables/functions that are in scope when the script runs). 4.8.0 should be released tomorrow.