This is currently on our roadmap

The legacy source provider is available in the same Mercurial extension. As long as the provider has Log command line arguments disabled, the Admin_ConfigureBuildMaster permission is required to see the URL with the password in it. If the username or password has special characters that don't work in URLs, they can be encoded. Common characters that cannot be used in the username/password section of a URL without encoding include: \ (use %5C) / (use %2F) @ (use %40) : (use %3A, but don't encode the colon between the username and the password) % (use %25, but only if the percent sign is part of the username/password and not one of the above replacements)

hi Mark, great question. My team pointed me to your question; I actually talk on this topic quite a bit. DevOps is really just a buzzword, and everyone (including Inedo) is jumping on it to describe what we do. But ultimately, DevOps is a process improvement designed to improve release velocity (e.g. going agile) through two means: Automate everything you can Increase collaboration between teams Ultimately it's about improving a process of software release. There's a ton of noise about "best practices" out there, and everyone has opinions. But I think the best way to understand these opinions are to get a feel for the underlying process. Two suggestions for that. Release Management Done Right describes why you should be following a pipeline strategy. Source Control Done Right goes over how source control should/shouldn't be used, and is still quite relevant today (it was written before "DevOps" was buzzy). Now, based on your specific situation, my advice is to start simple. Just change-up your TFS version strategy a little bit -- don't build in each environment, but create a build artifact at the start. You can do this all in BuildMaster. The other tools are nice, but may not be necessary until you run into the problem of trying to have a single tool do it all.

This is an internal GIt error, and can usually be resolved by just deleting the local repository (under the TMP\SrcRepos folder).

Hi Mike, For GitHub, that source control path doesn't look right. It shouldn't have the ".git" in it. Are you using the [...] selector? That should provide for a proper source control path.

Well be releasing BuildMaster 5.1 in just a bit (later today), which will have these operations.

That's great news ! Thank you for following up :)

Please see the TFS extension for information on how to do this.

Thanks for your prompt reply. The patch script you linked certainly fixed Issue#4 for us. I think we should be fine to push forward with 4.7.3 as it looks like all the issues have now been resolved. Thanks for linking through that knowledge base article. I'll be sure to have a look through the knowledge base articles before any future upgrades.

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.

Sorry, this question somehow got marked as resolved, but it doesn't look like you ever got a response. If you'd like, you can email us at support at inedo.com with details about what you are trying to do, and we can try to give you some more specific help/ideas.

When you say "BuildMaster is not able to see it", are you saying you aren't able to get the latest files in that branch, or that when you browse the branches in the file/folder picker that they aren't visible? I just did a quick test with a Git repository on BitBucket and the moment I added a remote branch, it became visible in the file/folder picker.

Which aspect of insecurity are you referring to? Those credentials (as long as they are sent over SSL) are encrypted before they are transmitted. If you mean storing them in the BuildMaster database, of course that does leave them available to anyone who has access to them, but you can configure permissions to hide debug logs and access to the configuration for that provider. Anyway, you should configure your git client to use key-based authentication if the username/password combo can't be done.

In .net, it's usually best to split out your web.config files into multiple files using the configSource option. So, <appSettings configSource="web_appSEttings.config" /> This way, you only need to edit web_appSettings.config when a key changes.

Hi Max, That sounds like a great idea. Unfortunately, there is no SC Provider that is associated with a particular build; that is, there'd be no way (aside from looking at logs) to know which ProviderIds were used in deployment plans executed over a build's lifecycle. You could capture this as a variable, however. If you haven't already, make sure to see how the SourceControlProviderActionBase actions work; you can find their code thru a decompiler (BuildMasterExtensions assembly), or just ask for it and we'll email you. Hope that helps, Alex

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?

Nevermind. I see the answer here ( http://inedo.com/support/questions/820 ). I swear it wasn't there on Friday.

Just to update anyone reading this. Having spoken to support I was being a bit of an idiot. When prompted to select from SVN (Step = Select Provider/File) it wants a file, not a folder. So /Project/ will error, but if you pick a file in that folder all works.

Code sent! hope this helps. A general rule of thumb... An action that inherits from ProviderBasedAction<T> is designed to run an operation on a single provider (Issue, Source Control, Database, etc). The provider and action plumbing take care of the agent and cross-platform things. If the provider doesn't already do what you want it to, then it's almost always easier to just run a command-line action (CommandLineActionBase), as that takes care of all the process logging and other things.