The "default" folder (usually the SRC subfolder) is unique to applications and deployables, and is housed under the <bmas-tmp>\A<appid>\S<depid> folders. It is cleared during the "preparing agents" step at the start of every action, unless it's a re-execution of a failed deployment. Only one execution within an application is permitted at the same time, so the second one created will be queued until the first completes.

We have upgraded to Buildmaster 4.0.9 (B31) and the "Execution Status" == succeeded work better but still not correctly. The predicate test is on the Action Group which contains 2 separate actions. The first action fails (and shows as failed in the log) then the next action succeeds and this marks the Execution Status as succeeded again to the remaining predicate tests pass. It would seem that the Execution Status should not be set the succeeded after it has been set to Failed.

You can try this method with the BuildMaster service (INEDOBMSVC) or agent (INEDOBMAGT) if it's running on a remote server: http://www.codeproject.com/Articles/4891/Interact-With-Desktop-when-Installing-Windows-Serv

The editors/extensions are sealed, so unfortunately the only pattern available at this time is the "Inherits by Clipboard" pattern. In this case it shouldn't be so bad, since it's a couple-line action+editor.

Every .NET project that consumes NuGet packages has a packages.config file, and that should be in source control. Unless I'm missing something, the deployment plan actions should be as simple as "Getting Latest" from TFS, then an "Install NuGet Packages" action followed by "Create NuGet Package".

Yes it would, but the editor UI may attempt to validate the credential. The way to get around this would be to edit the Action XML directly and replace the principal name with %VARNAME%. We'll add a fix in a future version of BuildMaster (likely 4.x) to bypass this validation if %[A-Z]% or something is matched.

You should be able to use a variable server by editing the action's config xml, and replacing it with %VARNAME%; however, this is not supported in the editor, and will break once upgraded to 4.0. But, it will work. The Variable Server in XFer Files will be available in 4.0.

This is how the "default directory" is implemented (see http://inedo.com/support/documentation/buildmaster/deployment-automation/deployment-plans/actions). It allows for the same directory to be used as input/output. At the start of the action, the "WRK" directory is moved to "SRC" and a new "WRK" directory is created. If there are no files in "WRK" at the end of the action, "WRK" is deleted and "SRC" is renamed to "WRK". Otherwise, SRC is deleted.

Sorry about that - there was a bug with that action in BuildMaster versions pre-v3.6.5 (specifically BM-1137). If you upgrade to the newest version of BuildMaster the "Set File Attributes" action with your masks will function as intended.

What error message are you seeing?

Short of using the API, I can't think of a way to have the deployables be automatically removed based on variables. You could try a trigger, but that might not hit in time since those are on a few-second delay. The custom predicate sounds like it would work well.

Maybe... but there's no plans right now for it in 3.x. We plan on having support for that in 4.0

Unlike most BuildMaster custom editors, the VariableSetters do not have a Context object; we'll consider adding this in future SDK versions. In the meantime, you'll have to "hack" it by looking at the HttpContext.Current.Request.Querystring for the release number, or perhaps locating the Release Number control on the page.

Thanks for the report, I've reproduced the behavior and logged it to be fixed in the next maintenance release.

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())

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.

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