As currently written, I can't think of a good way to inject a connection string since that's handled at a higher level. I suppose the best way is to test against a local copy of BuildMaster with the connection string you want.

<strike>Unfortunately no. I'll add this as an item to improve for the next release though.</strike> As of BuildMaster v4.7 this is now supported using the /ServiceName argument. For the complete list of arguments, see: http://inedo.com/support/documentation/buildmaster/installation/silent-agent-installation

This is the default behavior already. Every artifact in BuildMaster is associated within a context of a build and deployable, so as long as you create the artifact in a specific build, that artifact will be used whenever that build is promoted/executed in every future environment by default. For more info, see the documentation on Builds.

Glad that works. If you only have a few instances of variables like $HOME, you can always just escape the $ - use $$HOME instead and BuildMaster will treat it like the literal $HOME and not try to replace anything.

Your projects sound like they're all part of an overall business application; i.e. to the business, and how it's consider for requirement changes and the like. In that case, the best way to handle this scenario is through deployables; that's basically what they were built for. This allows for "partial" releases (i.e. having 1, 2, or 3 components) easily, and allows for some more advanced dependencies (such as, say, you wanted to import one of those deployables to another application). However, in Jenkins, these would be represented as three (or more) different jobs. So, what I might try is to use a Build Plan (i.e. not a build importer, just a regular plan you can add actions to)... and then use three different action groups (each associated w/ a different deployable) that contains "Get Jenkins Artifact (to working directory)", "Delete Files (from working directory, with whatever masking you need), then "Create Build Artifact (from working directory)". It's a little inefficient I suppose, because of the zipping/unzipping, but hopefully that is trivial. As for the bug, actually first I heard of it --- mind submitting a ticket so we can get it fixed?

You should be able to reference your library from your custom extension. You just need to make sure that it and any other dependencies are either included in the .bmx file or are installed to the system GAC. BuildMaster doesn't use EF, so there shouldn't be any version conflicts there.

UPDATE: This is supported with the new execution engine, available in BuildMaster 4.9. As of BuildMaster 4.6, this isn't supported, but definitely something we will support in the future. I can see other cases where this would be useful as well (e.g., copying files or deploying artifacts to multiple target servers).

This sort of workflow isn't really support; the standard way to do this is to re-execute a previous release's promotion to Production, thereby setting the context for the artifact to that of the previous-deployed build.

A patch is available below; run the contained SQL scripts against the BuildMaster database in any order to resolve this. Note that this fix only applies to v4.6.3-4, and will be included in v4.6.5: http://44.inedo.com/buildmaster/CloneAppPatch-v4.6.4.zip

This isn't an answer, but more information as to why the uninstaller might be failing. When I run these manual steps, I see an exception. > C:\BuildMaster\Service\bmservice.exe UninstallWeb C:\BuildMaster\Service\bmservice.exe : Error stopping service: Service INEDOBMWEBSRV was not found on computer '.'. At line:1 char:1 + C:\BuildMaster\Service\bmservice.exe UninstallWeb + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (Error stopping ...n computer '.'.:String) [], RemoteException + FullyQualifiedErrorId : NativeCommandError Removing INEDOBMWEBSRV service... Unable to remove service: Object reference not set to an instance of an object. Service removed. I think maybe the uninstaller doesn't handle this situation and so stops in the middle?

It's not recommended to check-in the modified assemblyinfo.cs file. For a few reasons, including the one you identified: it causes issues with source control related to the build. But moreover, attributes in AssemblyInfo.cs are metadata more than code; in other platforms (like Java) these are always added as part of the build process.

As per email response: Try upgrading to 3.6.5 first, then to 4.6.4.

I'm not sure what the tool is validating exactly, but after uploading the WSDL file to https://www.wsdl-analyzer.com, it said the document was valid. I am not super familiar with Java or any Java tools, but the same problem looks like it has occurred here: http://stackoverflow.com/questions/13499860/jax-ws-error-on-wsdl-file-error-resolving-component-sschema

There is no export functionality in that version, the recommended path is to just use the installer. What do you mean when you say it’s “too risky” to upgrade? Traditionally, only a few upgrades that we’re aware of have failed when upgrading from any version, and those were mostly due to unsupported database changes made by DBAs, which we can usually help resolved based on the error messages. Have you tested an upgrade by backing up and restoring the database, then running the installer against it?

I'll have to check with the dev team, but I think that was never intended to be part of the public API, since as you discovered, it takes a little application logic to clean up the actual artifact files as well. We originally had plans to add something to the service that would occasionally scan for orphaned artifacts on disk, but those were postponed. Your workaround should be safe enough, but it's not something we can add, as we can't rely on the database being on a server that can access the artifact library, or even that it's running as a user account with sufficient privileges. At some point, we'll likely reevaluate/extend our SOAP/JSON API's and allow them to do higher-level tasks like this, but there's no immediate plans for this.

Off the top of my head, that seems like the best/easiest way. I think what we need to add is the ability to mark a manual action "incomplete" instead of forcing the user to cancel the deployment... that should make it easy then to create a Predicate that checks whether all manual actions were marked complete. I'll add these as feature requests for the time being, but am not sure when they will be shipped since your scenario should work fine for now.

While there is currently no first-class extension for it, it'd be really easy to do with a Execute Command Line action, or a reusable Powershell Script that you put in the Script Repository. It's also fairly easy to write your own extension too -- if you choose to go that route, let us know, and we'll be happy to help where we can!

FYI- 4.6.4 has been released, and this fix was included.

While the "switch to LDAP page" should not allow changing directories if it's not configured properly, most likely the BuildMaster server is unable to query ldap.

Hi Byron - We do have a number of BuildMaster users who utilize the "Attach Build Report Action" to capture the output of a Fortify Static Code Analyzer scan after running it via the command-line; it's a general-purpose Action that will basically attach the report to the build so that everyone has visibility on the scan. Others will use Coverity for static analysis in the same manner. It would be relatively easy to build a "first-class" extension for Fortify, and as an enterprise customer, we'd be happy to work closely with you develop one should you want a bit tighter integration. Cheers, Alana