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!
Many undocumented breaking changes in 4.7.x?
-
We've just upgraded from version 4.6.4 of Buildmaster to 4.7.3 and have encountered what appears to be numerous breaking changes that don't appear to be documented anywhere in change notes.
Issue #1:
Mercurial extension failed to load after upgrading Buildmaster. We uninstalled the extension and re-added it only to find that there was an update we had never been notified about through the extensions page. Fortunately upgrading the extension fixed this issue.Issue #2:
Source control providers now apparently have a name by each repository and the name defaults to a blank string. This would be fine except for the fact that Buildmaster requires this to match the name of the local repository clone folder for each repository. We currently have 122 repositories configured through Buildmaster and this was a nightmare to hack the Buildmaster database in order to get basic build functionality restored again.Issue #3:
Repositories have moved from an HgRepositories directory to a SrcRepos directory. After we finally resolved Issue #2 we had to manually copy all the repository clones from the original directory to the new directory to get builds working again as they weren't being cloned in a timely manner.Issue #4 (currently unresolved):
We now get a server error 500 whenever we try to clone our template application to create a new one. Looking through the event logs I can see this message:547
160Applications_CloneApplication195`The INSERT statement conflicted with the FOREIGN KEY constraint "FK__VariableDefinitions__Releases". The conflict occurred in database "BuildMaster", table "dbo.Releases".I've looked through the affected stored procedure and have hacked a couple of select statements in to try and diagnose the problem.
Here is the statement throwing the exception:--==[VariableDefinitions: Application Variables]==--
PRINT 'VariableDefinitions: Application variables...'
INSERT INTO [VariableDefinitions]
(
[Variable_Name]
,[Environment_Id]
,[Server_Id]
,[ApplicationGroup_Id]
,[Application_Id]
,[Deployable_Id]
,[Release_Number]
,[Build_Number]
,[Value_Text]
,[Execution_Id]
,[Sensitive_Indicator]
)
SELECT
[Variable_Name]
,[Environment_Id]
,[Server_Id]
,[ApplicationGroup_Id]
,@New_Application_Id
,[Deployable_Id]
,[Release_Number]
,[Build_Number]
,[Value_Text]
,[Execution_Id]
,[Sensitive_Indicator]
FROM [VariableDefinitions] VD
WHERE VD.[Application_Id] = @Application_IdThis is trying to insert Application_Id/Release_Number combinations that don't exist in the Releases table such that FK constraints are being violated. We have release 1.0.0, 1.0.1 etc for the template application, however the clone stored procedure only creates a release of 0.0.0 for the new application so this will never work.
Suggestions:
We are currently in a state where rolling back to an earlier VM snapshot and losing data is probably our only option to get application creation functionality back. The whole upgrade has been problematic and has been made worse by the fact that we had little to no warning some of these breaking changes were being introduced.Can you please put some more details into the change notes, especially highlighting breaking changes that may affect existing production systems.
Mercurial Extension Notes:
http://inedo.com/buildmaster/extension-release-notes/Mercurial#v4.5
It would be nice to know what was going on in each version rather than just the fact a new version was released.Buildmaster Extension Notes:
http://inedo.com/buildmaster/versions
Gives an overview of bug fixes but there is no blaring warning that any of the changes would be breaking.Product: BuildMaster
Version: 4.7.3 -
Sorry for all the difficulties; as you noticed, BuildMaster 4.7 introduced some changes to the Source Control providers. We do publish upgrade notes for minor versions (see KB#1103) that advise on the changes and associated risks -- but those are linked from the installer and the 4.7 overview page, not the all versions page.
The upgrade process should have taken care of the providers in the database (as you had to do in #2) -- but, it seems that, for whatever reason, it missed yours; in the future, please don't hesitate to contact us as that's happening -- we are pretty familiar with exactly what changed, and can quickly introduce a patch or fix.
For #3, that's simply an implementation detail change that would be resolved after a single source control operation and unfortunately we did not document this; we'll try to be more aware of this in the future notes.
Regarding the clone, we identified the problem, and will be fixed in v4.7.4; in the mean time, you can download a patch here:
-
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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login