Passing in a username/password is controlled through the API key argument when there is no API key assigned for the feed in ProGet: http://inedo.com/support/documentation/proget/feeds/api-keys

When you share/link action groups, you may select a "Default Server" for the actions, which means you can link them across environments and still have the actions run on different servers (just select the local BuildMaster server for the actions, that will be overridden by the selected default server of the group). If you choose a separate build server for your actions instead, that will take precendence over the default server unless the build server is the same as the BuildMaster server; if that's the case you can just put those actions in a separate group. As for the database selection, we could update that action to allow selection via a variable or have a default option that chooses the DB based on the environment it's in.

Thanks Steve. That was enough for us to implement a custom action, and the action were pretty easy to implement based on the source code that you provided. Appreciate the prompt response!

Thanks for the confirmation. I just tested this technique, and it worked really well, actually. I'm going to use the following naming convention: DEV SQL Server (the actual DEV database) TEST to DEV SQL Server (the TEST database available to the DEV BuildMaster environment) PROD to DEV SQL Server (the PROD database available to the DEV BuildMaster environment) I was concerned that BuildMaster would want to re-initialize the database, but it didn't. In fact, during the next build in DEV, BuildMaster correctly backed up my PROD db and restored to DEV and then determined that my SQL Change Script had never been run (since the BuildMaster execution table is also restored). This is how I expect and want it to behave. Thanks again for the VERY FAST response! Matthew

Yes, I would like a comments field for when I deploy a config file. I already liberally use the comments field when editing. Thanks!

FYI we have released a new version of the DotNetRecipes extension, if you update that extension within BuildMaster then re-create the example app, the signing should work correctly. As for the certificate hash problem, that has been resolved in the .NET extension which is scheduled for a release later today or early tomorrow.

Fantastic! Thanks for the speedy response. Works fine now.

Thank you! I will try it now.

Thanks look forward to it

My fault, I had forgotten about the shared TMP directory and was focused on the WRK and SRC ones. It appears then that building the same app but different workflows at the same time is not currently supported, but there are workarounds. As an example, you could use a different environment (e.g. Integration2) for the patch workflow, then link/share all the action groups from Integration. If you were to then install a BuildMaster agent on the BuildMaster server (and add it via the Servers page), that agent would have its own set of temporary directories. All you'd have to do is update the "default server" setting for each action group in Integration2 to point to the agent server.

Installed 1.0.7, and no issues to report with our network share backed feed. Thx.

Ah. Currently on 2.6. Will upgrade immediately!

Thank you. The server was activated fine and is working very well. I am satisfied.

For future reference, this was happening because the application attempting to be built was including an imported deployable, and there was no active build in the referenced application. The error message will be clarified in the next version of BuildMaster (v3.2.2).

Yes, but not easily. Automatic build records (schedule, SCM-triggered, or URL-triggered) are not "soft deleted", so you must go to the audit logs and search for the "BSHDEL" event. This can be done from the UI or directly from the database with SELECT * FROM EventOccurences WHERE Event_Code='BSHDEL'

Do you know if you are running the BuildMaster web application through the integrated web server, or if it's hosted by IIS? For the integrated web server, ensure that its service runs under Administrator as well. If you're using IIS, you'll have to verify that the app pool's identity is running as the Administrator account in addition to the BuildMaster service. Right now we are in the process of writing a knowledge base article that will give step-by-step instructions with regards to connecting to GitHub since that seems to be the most common hosted solution for our Git integration.

If you're using the integrated web server, can you verify that the "BuildMaster Web Server" service is started? (Start > Run > "services.msc" to check, if it's not, just click Start). If you're using IIS to host the BuildMaster site, can you verify that the site is started and the BuildMaster app pool is running?

The Branch Action is designed for "tagging" builds (Subversion and CVS), and actually, it's been renamed in 3.2 and will only be displayed if you have one of those providers. You're definitely on the right track for labeling each build, but merging... it's not really something you can do on an automated basis because of conflicts. That said, if you do want to merge, you can simply call tf.exe merge.

All you should need to do is copy the output to wherever you want it published using the "Transfer Files" action immediately following the "Prepare ClickOnce Application".

Looks like I'll have to wait for 1.0.2. I can't seem to proxy the NuGet gallery even when I run the ProGet service as an account that has Internet access. I won't get to look at this until our Tuesday though.