I think I just figured it out. We have some unit tests running which are creating the GUID based XML file in question. I still have to do some more investigation.

It was very helpful.

Thanks a lot. That worked. Your quickness is truly appreciated.

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.

I would suggest just disabling your build schedules during the outage period. Maybe at 12:45AM through 1:15AM (or whatever). This can be done through the API methods (BuildSchedules_GetSchedules and BuildSchedules_CreateOrUpdateSCMTriggered), or through a simple SQL Query (UPDATE BuildSchedules SET Active_Indicator = 'N'). We don't have a generic task scheduler built-in to BuildMaster, so you'd want to use Windows Task scheduler to run the enable/disables.

I could certainly try this if you can tell me how. Also would it be easy for me to unistall and go back to the previous functionality, if required? Please let me know what i need to do to test this.

Yes we seem to have an older version. I will update this and let you know. Thanks Chris

Do you have access to the SQL Server that BuildMaster is using? Can you send the results of the following query to support-at-inedo-dot-com: SELECT * FROM Providers Most importantly, the Provider_Configuration column.

The Database Connections module is designed to segregate connection strings in this exact manner; this way, only certain privileged users can use the database connection their privileges allow. In this case, it might make sense to build a custom Database Provider that's based off of the SQL Server one. This is pretty easy, and several users have done this. Please contact support, and we will send the source code for this.

This is not possible with that setup. If the DLLs are deployed separately at times, they should really be their own deployables (or even applications in some cases), that way you can specify them to be deployed at the release level. However, for your case, you may be able to get away with creating multiple variables (e.g. FILEMASK1, FILEMASK2, FILEMASKN, etc.) I'm not actually sure if that will work or not, and still wouldn't solve the problem if you have more than N files.

Yes we do support other regions, we will file this as a bug targeted for the next release. Thank you for the report.

I will also add that there is a feature in the pipeline named "Release Archiving", which will allow deployed releases to be archived and delete the artifacts from a release for all but deployed builds. It will also delete the execution logs and messages for non-deployed builds. This feature (at the moment) is not scheduled for any particular release, but it should be coming in one of the next few minor (3.X) releases.

At the moment, there is no way to accomplish the pull method. Our agents are extensible, but the BuildMaster service itself is not equipped to handle the incoming connections since it works backwards to the original design. We have however thought about implementing this type of agent specifically to allow for hosted instances of BuildMaster. If you are a looking to purchase the enterprise edition, there are additional support plans that we have done in the past that would expedite the delivery of features like this. If this interests you, please contact support@inedo.com.

That's great news John! (I had a 3 failed builds last night because of this issue)please let me know if you have any questions or if there is any additional information I can provide.

Yes, deleting and readding the action step fixed this bug. I should have tried that, I suppose. Thanks! Matthew

We currently have no first-class integration with HPQC but we're always looking for ways to integrate with third-party tools. We even offer extended support plans that can move the integration to the top of the list so to speak. If you'd be willing to email us at support@inedo.com with ideas on the sort of integration you're looking for, we'd be glad to take a look at that.

Okay, thanks for letting me know. I did change the name through the database, and that worked just fine. The history of the rename is not as critical to me as the deployment history, so I think we're good for now. Thanks for the reply, Matthew

The 1000 is a limit imposed by Active Directory presumably for performance reasons. Typically, you shouldn't ever need to be on the users page when using Integrated Security because once a user is assigned privileges via the "Assign Security Privileges" page, they automatically become a named user if there are licenses available when they visit the BuildMaster URL. We are planning an enhancement that will determine based on the assigned privileges whether the user should be approval-only or full, but for now it will default to full (if available) and downgrade to approval-only if no full user licenses are available. Once the user has become a named user, you can manually edit the type of user on the "License Key and Activation" page which allows you to select "[change]" to toggle the user between full or approval-only as needed.

That solved it, thanks!

Are you using the integrated web server? If so, you'll need to add the host name: http://inedo.com/support/kb/1014/changing-buildmasters-url-with-the-integrated-web-server It's also pretty easy to upgrade to IIS, if it's already installed on the box: http://inedo.com/support/kb/1013/hosting-buildmaster-through-iis-instead-of-the-integrated-web-server