The self-hosted agent uses a proprietary binary protocol over TCP that is optimized for performance. IIS agents do indeed use SOAP over HTTP (or HTTPS). Both agent types can be secured using SSL encryption and client IP restriction. For an overview of how the agents differ, you might want to check out this article: http://inedo.com/support/kb/1039/comparison-of-buildmaster-agents

Thanks, it works fine now :)

Hi, Thanks. I removed the extension and added it again. This time, it's version 4.8.1. :-)

In theory, you shouldn't need to add a name unless there are multiple repositories for a single provider - if that's not working as you would expect then that is a bug. All of our test repos for multi-repo providers have a name, but it still seems to work without one. If it's easy enough to add a name as a workaround, that's the best bet, and we can update the provider again in the meantime as to not require it as before.

Can you try pointing the extension at the 32-bit MSBuild (or 64-bit if you are already using the 32-bit version)? Beyond that, have you seen: http://blog.nikosbaxevanis.com/2013/10/04/how-to-configure-msbuild-to-locate-the-fsharp-build-targets/

There is no "first-class" support for this framework, but anything that can be built/run with a command line can build/deploy applications that use it.

Hmm, we'll have to look into that... Just use Applications_PurgeApplicationData with this method: http://inedo.com/support/tutorials/cloning-an-application-with-the-sql-api

Turns out it does work, there was another issue preventing it from running. What's got me confused though is that the script is being run from the SRC directory (that's what the unix pwd command implies) when it was copied to the WRK folder as you can see from the log. Downloading http://192.168.59.103:8081/artifactory/libs-release-local/myapp/0.1/33/trial.sh artifact to C:\BuildMaster\_SVCTMP\trial.sh Transfer C:\BuildMaster\_SVCTMP\trial.sh to /tmp/buildmaster/_A5/_S5/WRK/trial.sh over SSH Execution complete. Finalizing... Target directory used. Abandoning source. Finalization complete. Source and target directory are the same; splitting... AgentBasedAction initialization complete: Temp Directory: /tmp/buildmaster/_A5/_S5/TMP Source Directory: /tmp/buildmaster/_A5/_S5/SRC Target Directory: /tmp/buildmaster/_A5/_S5/WRK Server: DockerVM (Id: 2) Initializing action... Initialization complete. Executing... trial.sh /tmp/buildmaster/_A5/_S5/SRC Script returned: 0 Script completed. Execution complete. Finalizing... Target directory unused; joining with source. Finalization complete. Source and target directory are the same; splitting... AgentBasedAction initialization complete: Temp Directory: /tmp/buildmaster/_A5/_S5/TMP Source Directory: /tmp/buildmaster/_A5/_S5/SRC Target Directory: /tmp/buildmaster/_A5/_S5/WRK Server: DockerVM (Id: 2) Initializing action... Initialization complete. Executing... echo result: Hello World, we've made it! ls result: trial.sh pwd result: /tmp/buildmaster/_A5/_S5/SRC

Anything with the suffix _Configuration can be deserialized, so for your example all you need is: return (ArtifactoryVersionVariable)Util.Persistence .DeserializeFromPersistedObjectXml(settings);

Also for convenience, as of .NET 4.0 there is a CopyTo() method on Stream that will do the buffering for you, so you can just call: srcStream.CopyTo(destStream);

Predicates are not directly tied to applications anymore as of v4.3 because of global plans. However, if the plan is in a single application, you can use: int id = int.Parse(HttpContext.Current.Request.QueryString["planActionGroupId"]); int applicationId = StoredProcs.Plans_GetPlanActionGroup(id) .Execute() .ApplicationDeploymentPlans .First() .Application_Id; to get it.

You can use: var configurer = Util.ExtensionConfigurers.GetExtensionConfigurer(this); from within the variable itself, or pass in an instance of the variable instead of this from the variable setter.

That should be OK - just note that this will update all workflows in the system to have this behavior.

The BuildMaster (primary) server currently only runs on Windows, but it can connect with MacOs servers via SSH. It's a web application, so of course you can access it on a Mac no problem.

Embarrassing, a Spanish colleague had been on the server and changed all the setting!

There shouldn't be anything else that needs to be passed in, are "hello" and "cause" the only 2 variables? It's possible there could be an issue with default variable values.

If "Multiple Active Builds" is enabled for the application, the builds will queue (i.e. the latest ones will stay "Pending" until the prior ones finish sequentially). Without that setting, newer builds will reject older builds for the same release. Beyond that, your workaround for the non-mulitple-active builds setting will work fine.

Restarting the service sorted it thanks.

Interestingly enough, disabling connection pooling for Buildmaster seems to have solved our issues. It's been five days and there hasn't been a single error in the event logs or Buildmaster itself. In app_appSettings.config we now have our connection string setting looking like this: <add key="Core.DbConnectionString" value="Data Source=localhost; Initial Catalog=BuildMaster; Integrated Security=SSPI;Pooling=no" /> Could this possibly be caused by a connection in Buildmaster not being disposed properly such that when it is pulled back out of the pool, it's in a broken state?

Apparently only the PowerShell scripts support variables in parameters and in scripts at this time, so we will have to add this feature for shell scripts as well. Ideally it will be included with the initial 4.7 release, but may be a maintenance release behind that. For now, if you use the Execute Shell Script action and enter the script as text or a file, it should work as you expect.