Hi Dave, There is new release of the Linux extension (v3.12) that will resolve this issue. Best, -Steve

Hi Andrew, We don't do anything special, just standard Process.Start stuff. I believe Processes inherit environments from the parent process, so perhaps you need to stop/start the service, so it can capture new machine variables? FYI - we do have an option (AddBuildMasterVariablesAsEnvironmentVariables) on CommandLineActionBase, but this is not exposed as a checkbox in the Command Line Action. We will likely add that as a checkbox in the future. Alex

Issue tracking would require a custom extension. It's a pretty simple web api, and if you'd be interested at taking a crack at it, we could help you build the extension (and support it going forward).

That half worked, the environment variable has been set (I can log on to the server and echo the value) but if I try to use the environment variable from a script called by buildmaster then the no value is returned. Why can't I use this value from a script called by buildmaster?

Thanks! I changed the account build master was running under, and it now works.

Thank you Alex, as you suggested, the issue has been solved increasing the maximum allowed content length in IIS.

Thanks for the prompt answer :)

Thank you, it did solve the problem.

Pulling in a variable value from an external source would require a custom action using the BuildMaster SDK. These are relatively easy to write, but we can of course help with that through professional services (http://inedo.com/company/professional-services). In the action's overridden Execute() method, all you'd need to do is: this.Context.Variables["VERSION_NUMBER"] = GetVariableValue(); where GetVariableValue() is a method you create to pull the value from whatever source you want (could be from Artifactory, or something like File.ReadAllText())

Variables have been expanded quite a bit in BuildMaster 3.6... so this might be accomplished through a Promotion, Environment,etc. variable

The logging isn't disabled; build execution log entries with a debug level are simply not displayed to users who don't have that privilege. By default the "View Only" role does not include the ability to view execution log entries. We have a few tutorials for making a custom action here: http://inedo.com/support/tutorials Alternatively you could store the password on the machine as an environment variable, and have the shell script retrieve it that way.

Thanks for the info. In regard to switching the exe.. should I be able to save the change from using the built in exe to a standard one without hitting the "Test Connection" button? When I try switching to an external git.exe and click the "Save" button, I can open the provider properties back up and the "Use Standard Git Client" option is unchecked again. Any other changes I make seem to save, just not changes to that option. The same thing happens when I create a totally new provider / source as well. I set it up to "Use Standard Git Client" and hit save then open the new connection up and it shows as unselected.

You can use your account credentials for testing purposes; but for long term-usage, an systems administrator should set up a service account for BuildMaster and its agents to use. To change service credentials, go to "View Local Services" and then edit the BuildMaster Service. You can just set it to your account. If using IIS, go to App Pools, BuildMaster App Pool, Advanced settings, and change Application Pool Identity to your account.

Thanks for the work around. Saved us much headache!

Hi Tim, You may want to create a role with the task, Builds_PromoteBuild, and then only deny that role to Production. Alex

Nevermind, the Build was already rejected.

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.

BuildMaster 3.6 (currently in beta, download here -- http://inedo.com/buildmaster/download/versions#3.6.0 ) allows servers to be specified as variables.

All of these seem valid approaches... #1 obviously has the most flexibility in getting any artifact version. We will soon be releasing an Artifactory Extension that will make Artifactory interactions a little easier.

Hi Phil, This has to do with the Action Group that creates the Artifact. It's probably associated with (all deployables), which means it will be in the \0 folder. So, simply change the action group that creates or deployes the artifact to use the same deployable... either (all deployables) or DeployableX. Hope that helps... Steve