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

Hi Dave, Can you send a screenshot of the action to support? Want to see the value of all the fields. Suspect it's not related to variables (they get replaced long before action code runs), more to masking, or something else... Thanks

We are using Solaris 10. It is possible the delays are being caused by poor performance of the Buildmaster server which is running as a virtual machine. I have raised a helpdek issue on our side to investigate as just copying the file with winscp from Solaris to Buildmaster takes 65 seconds which is too long.

Using !.svn* still creates the .svn folder on the destination machine.

Thanks, we will wait for the updated svn extension, and use the execute command line option in the mean time.

Thanks, this issue is now fixed after updating the Jenkinds extension to the latest 3.1.2 version.

The "Execute Command Line" option correctly handles the return code from the unix command so we can use this option, thanks. It would be good if the SSH Execute options worked, however, as they give us some more flexibility. Note, the target Unix platform where the return code is not handled is Solaris 10.

As it turns out this is a problem related specifically to the SVN extension and will require us to release a new version of the extension. We will have this out within the next few days. As a workaround, you can call the Execute Command Line action directly with the appropriate SVN checkout arguments in order to get the latest code.

Just to update anyone reading this. Having spoken to support I was being a bit of an idiot. When prompted to select from SVN (Step = Select Provider/File) it wants a file, not a folder. So /Project/ will error, but if you pick a file in that folder all works.