Schedule Triggers haven't been replaced; we only really consider those legacy because of the way the variables are handled by them. See also: https://inedo.com/support/questions/9736

Hi Josh, Sorry, this seems to be a v6 glitch! But we're on it :) I've submitted BM-3192 and then inedo-docs/#6 to update our documentation. Your understanding of how the feature is supposed to work is correct, and your use-case is how it's supposed to be. Thanks for reporting it !

To be honest, "SCM Triggers" are in a "quasi-legacy" state, because they use the "Legacy Providers". As such, we don't list it as a feature, and we hide the button on installations without SCM Providers configured. This was done slowly over the course of two years, in various v5 versions, to gauge user reaction. So, your inquiry is good feedback. That being said, we have not yet put a lot of effort into properly redesigning this feature. The reason for this, is that the "general direction" has been moving towards post-commit hooks; i.e. triggering the build from the SCM server, once a merge request (or something?) happens. Even on dedicated CI tools, the preference is shifting towards this route. I think this is because the branching logic has been too complicated to follow (even for really advanced CI servers like Jenkins and TC). So I wonder, have you looked into post-commit hooks? Otherwise, we are definitely considering a general-purpose poll/trigger feature: basically, a poll will periodically occur, and if a condition is met, trigger some sort of event. This would be shared across multiple products, and the usecases might vary based on the product. One motivation to develop this feature is that it will allow us to really feature the "BuildMaster is from source to production" story, which is becoming more popular again. Most people didn't want that, but now the pendulum is swinging back to it, now that source code tools (like Git) are integrating (totally inadequate) build/release features. In any case, none of this is all that "immediate", but I wanted to share reasoning to you about this, and solicit your feedback. Of course, if you need to create "legacy components" we can help you do that as well. We don't plan on removing those from BUildMaster, just hiding them so no new users can access them.

It's certainly possible in BuildMaster, but it's not a common workflow anymore. We have considered extending support, but the market generally is moving towards "many single-purpose tools" than "multi-function tools". The general flow these days looks like this: Source >> CI >> Package >> Deploy In this case, ProGet is the Package repository and BuildMaster is the deploy tool. The advantage to this workflow is that, the CI tool need only "create a validated package", instead of trying to deploy. By the way, I also recommend you to look at GitLab; we switched to it after extensive evaluations of similar "simple" tools (GitHub, BitBucket), as well as the enteprrise tools (Perforce, etc).

Hi Alana, Sorry to say that the solution you propose is crap. If teamcity can monitor on wildcards, example +:refs/heads/release/* I'm sure BM can somewhat do it also. I raised a ticket for the purpose. EDO-3200. Thanks Regards

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)

There is no way to configure that in the schedule, but you can somewhat accomplish this by either: setting the filter to "newest active release" and moving the release to the top on the Release Sequence page or, if you don't mind multiple failed builds in your release, setting the filter to "all releases" and filtering at the top of the build plan, e.g. if $CompareReleaseSequence(!=, $ReleaseNumber, $DesiredReleaseNumber) { Log-Information `$ReleaseNumber is $ReleaseNumber, skipping.; fail; }

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

That behavior definitely sounds suboptimal; we will investigate a bit further!

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

So I wanted to respond on here, I wasn't quite sure what to do with the information but I wanted to proceed. What I did was the following: Forked the GitHub repository Modified the TfsBuildActionEditor to have a Checkbox for [Validate Build Status] Modified the TfsBuildAction to use this and created a ValidateBuild function If the Check is selected it sends an error and pulls the Build Errors from the Build Details and displays them. I am not sure if this is something you wished to add so I did not submit a pull request. I could do so, but this can be considered answered. The whole point being that we didn't believe that "Create TFS Build" goal was met during a build failure, and there should be a way of validating that this actually did occur. If a build controller fails then a build was not created, or was partially created, and thus the Action needed to be able to reflect that. This also helps keep the CI running smoothly since it now becomes very apparent why a build broke and does not actually break test. Hope this helps anyone else who hits that! Consider this closed.

Currently, the Git provider only monitors a specific branch + path combination in source control. You can however, set up multiple SCM-triggered builds, each pointing at the desired "release/*" branch.

You might be able to get away with this with some git trickery, i.e. you can have a script at the beginning of the deployment plan that lists the remote branches and gets the latest commit time for each one, and writes the branch name out to a file (or something like that). Then you can use the "Set Variable Value from File" action to save that value into a BuildMaster variable, and reference that in the "Get Latest" action. Hope this helps :)

This should be done on the Workflow page - you can add a Post-Deployment step "Auto-Promote Build to Next Environment" to any workflow step.

Panic over, ntlm authentication rather than basic authentication required.

This question was resolved via other means, but the solution would be to upgrade to v4.5+ of the Azure extension.

Thank you Steve. i have figured it out. it was downloading the code in different path. Thanks Again

Currently this is supported through the API, but not via the triggered builds. We will add the ability to specify a build number for URL triggered builds in the final version of 4.3 due out end of next week. You can already specify variables for URL triggered builds by including them as part of the query string, e.g. http://buildmaster-server/trigger-build?id=1000&myVar1=value1&myVar2=value2

No, the URL triggered builds are designed to be "fire and forget". However, even without a quiet period, the builds are still queued in a sense that they will not run over the top of themselves until the previous one is completed.

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.