[Maria-developers] Buildbot confused by non-monotonicity of revision numbers in the tree
Hi! Buildbot seems to have a wrong idea about the order of bazaar's revision numbers. It also shows only last five pushes, and these two issues together make it impossible to see the recent status. The problem can be observed in maria-5.1-table-elimination tree: https://internal.askmonty.org/internal/index.php/Image:Buildbot-confused-by-... it's building but won't let you see the status. I got the tree into this state as follows: 1. branch off maria-5.1 2. make a number of sequential commits, so that the number of the tip revision grows to be much greater than that of mainline tree. 3. Meanwhile, a few csets were commited into the main maria-5.1 4. Do a maria-5.1 -> maria-5.1-table-elimination merge, using the recommended procedure - make a branch of main - bzr merge --pull from maria-5.1-table-elimination to there. As a result, tip revision in maria-5.1-table-elimination becomes a number which is less than it used to be (all csets made in #2 are collapsed into one Merge cset), and buildbot is confused - it assumes that the revision numbers are monotonically increasing, and that assumption puts my latest revision between some dated revisions. Besides the ordering problem, there might be an identity problem. At the moment the tree has a tip revision number #2723. The problem is that there already was a moment in the past when the tree was in a different state and had a tip revision number 2723. Does this mean that the new test results will overwrite the old ones? BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog
Sergey Petrunya <psergey@askmonty.org> writes:
Buildbot seems to have a wrong idea about the order of bazaar's revision numbers. It also shows only last five pushes, and these two issues together make it impossible to see the recent status.
The problem can be observed in maria-5.1-table-elimination tree: https://internal.askmonty.org/internal/index.php/Image:Buildbot-confused-by-...
it's building but won't let you see the status.
I got the tree into this state as follows: 1. branch off maria-5.1 2. make a number of sequential commits, so that the number of the tip revision grows to be much greater than that of mainline tree. 3. Meanwhile, a few csets were commited into the main maria-5.1 4. Do a maria-5.1 -> maria-5.1-table-elimination merge, using the recommended procedure - make a branch of main - bzr merge --pull from maria-5.1-table-elimination to there.
As a result, tip revision in maria-5.1-table-elimination becomes a number which is less than it used to be (all csets made in #2 are collapsed into one Merge cset), and buildbot is confused - it assumes that the revision numbers are monotonically increasing, and that assumption puts my latest revision between some dated revisions.
Besides the ordering problem, there might be an identity problem. At the moment the tree has a tip revision number #2723. The problem is that there already was a moment in the past when the tree was in a different state and had a tip revision number 2723. Does this mean that the new test results will overwrite the old ones?
I think internally Buildbot uses its own "build numbers" that are always increasing to record results. So old results should never be overwritten. However, all of the bazaar stuff in Buildbot seems to be based on revision numbers. Launchpad also does not seem to provide anything but revision numbers. So there will be confusion in reports based on revisions when the tree is modified. Bryan's and my idea is to eventually replace most/all of the built-in Buildbot web pages with some PHP pages that pull the data out of a database. This will be a much more flexible solution, and hopefully we will be able to resolve most of these kinds of issues. Meanwhile, if there is something that critically needs fixing, let me know and I will take a look. In the main lp:maria tree, we have set append_revision_only=True, so in this tree revision numbers can never mutate, and at least there the problem should be less. Also, I think I will write a feature request for Launchpad to include the revision ids in the email notifications, so at least the information can be made available to the PHP pages. - Kristian.
Kristian Nielsen <knielsen@knielsen-hq.org> writes:
Also, I think I will write a feature request for Launchpad to include the revision ids in the email notifications, so at least the information can be made available to the PHP pages.
https://bugs.launchpad.net/launchpad-code/+bug/419057 - Kristian.
Kristian Nielsen <knielsen@knielsen-hq.org> writes:
Kristian Nielsen <knielsen@knielsen-hq.org> writes:
Also, I think I will write a feature request for Launchpad to include the revision ids in the email notifications, so at least the information can be made available to the PHP pages.
Unfortunately, this is the comment I got on the bug: From: Aaron Bentley <aaron@canonical.com> "One of the design goals of bzr is that revision-ids should not appear in the UI. If you are really concerned, you can set the append_revisions_only flag in the relevant branches." :-(. - Kristian.
participants (2)
-
Kristian Nielsen
-
Sergey Petrunya