[3] – yes; I'm currently doing the following: Create an application package (by using the standard "Package" target in my "Build .NET MSBuild Project" action) Create a BuildMaster build artifact (i.e. create an archive file containing the application package and ancillary files) Deploy the build artifact to a folder on the build server. Run Web Deploy (msdeploy.exe) via a "Execute Command Line" action to deploy the application package (in the folder to which the artifact was deployed in [3]) to the relevant server(s) for the environment.

Check out the "Get Labeled" action under the "Source Control" group of actions. I'm using Git and that's how I pull the code associated with a tag. I'm pretty sure "Get Latest" does pull down the whole repo. In general, when automating application builds, you want the process to be as repeatable as possible, and relying on a repo to be maintained on the build server between builds introduces unnecessary complications.

Wow! Talk about agile, thank you for the quick turn around.

Hi Bryant, This is not supported as of yet, though we do hope to address it in BuildMaster 4.1. It is possible to write your own custom actions... and now that BuildMaster is on .NET 4.0 it wouldn't be so difficult to... query the database for the members of a server group do a Parallel.ForEach on the results, and perform the file transfer in that manner

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.

You could use the ExtensionConfiguration_GetConfiguration method, e.g.: EXEC [dbo].[ExtensionConfiguration_GetConfiguration] 'Inedo.BuildMasterExtensions.Artifactory.ArtifactoryConfigurer,Artifactory', NULL, 'N' and get the Extension_Configuration column, which contains the XML serialized properties of what you need - some simple XPath should be able to retrieve them.

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.

This is likely a subversion/workstation configuration problem. Sometimes two versions of Svn.exe -- the one you installed (like tortoise svn) and the one built-in to the extension -- cause conflicting configuration. Try to change the provider configuration (Admin > Source Control) to point to your own svn.exe instead of the built-in client. Also, try to change the option to use SVN UPDATE instead of EXPORT for this provider.

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

Can you try to use the "Build .NET Project" without checking "this is a web application"? Then, capture the artifact from _PublishedWebsites\project.name instead? This is how we solve this problem when we build proget (see http://inedo.com/specifics/proget), and we'll soon be adding another option for this action.

Hey Tod, Sorry about the confusion, the error was indeed different. I think we got a bit cross eyed while trying to figure all this out. The setup that we had to use in the end was rather awkward. Buildmaster seems to add quotations around the arguments section. We had the following setup: Command: delete http://<path_to_repo> Argument: -m "ReExecution by Buildmaster" When looking at the logs, it was converting that to: delete http://<path_to_repo> " -m "ReExecution by Buildmaster"" --non-inteactive etc... Notice the double quotations. So we ended up having to jimmy it a bit and it is now working with: Command: delete http://<path_to_repo> -m Argument: ReExecution by Buildmaster So I guess we can scratch this one of the list. Hopefully can present to the boss soon and get some budget for this.

There's no specific error message, aside from the SQL error that's being thrown. Since you have both on the same server, perhaps it'd be best to have a single SQL Server instance (SQL Express), and have the BuildMaster and ProGet databases hosted in that server.

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.

You are correct - I had a typo in the working directory !. This question can be closed.

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

Thanks for your reply, advice and for pointing us in the right direction. I think we need to rethink our web.config procedures.

At the moment, build and promotion-level variables cannot be modified by an action during an execution. This is mainly because of the way default values are cascaded and inherited. We've talked about adding another variable scope (execution) that then is created and persisted only at execution time, which would then allow for this - but at the moment build/promotion variables are immutable once the build is created. You should still however be able to add variables during execution time - they just won't appear in the build summary. In a quick test I ran setting a variable that wasn't specified as a build variable worked later on in the execution with the code you have written, so I couldn't repro part 2. Make sure both the BuildMaster service and web app are restarted whenever the extension changes, otherwise changes might not actually be loaded by the extension loader.