Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

  • 0 Votes
    4 Posts
    9 Views
    benB
    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)
  • 0 Votes
    3 Posts
    12 Views
    ?
    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.
  • 0 Votes
    4 Posts
    20 Views
    ?
    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.
  • 0 Votes
    3 Posts
    15 Views
    ?
    Thanks for the reply Tod. But I figured out the issue! We had earlier setup local repos on the BuildMaster server since the old Mercurial extension needed a local repo to be configured on the server. But the new extension for Mercurial does not have this constraint. So I just had to reconfigure the remote repos and everything is fine now.
  • 0 Votes
    4 Posts
    24 Views
    ?
    Sorry - I did mean .org in my previous response :) Still however, I am not able to reproduce this behavior that sets the Remote Repository to something other than what was typed in unless I edit an existing repository and do not save the edited values. If you could detail the exact steps you did (e.g. 1. Click Create New Provider button, 2. Input values abc and xyz, 3. click Test Connection, etc.) that would help tremendously.
  • 0 Votes
    4 Posts
    17 Views
    ?
    The remote repo is not required if the local one should be used.
  • Pull from Mercurial based on tag or branch

    Support mercurial buildmaster
    2
    0 Votes
    2 Posts
    9 Views
    ?
    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.
  • Automatic builds with Mercurial

    Support buildmaster source-control mercurial
    7
    0 Votes
    7 Posts
    11 Views
    ?
    I know this is old but it's still the first thing that comes up in Google when you search for the infinite build issue in BuildMaster. The infinite builds are because applying a label is technically a check-in in DVCSs like Mercurial and Git. So when you apply the label BuildMaster sees a new check-in and starts a new build, which applies a new label, which creates a new check-in, ... I haven't found a good workaround yet.