DBT should correctly handle builds with numbers around 4.0-722

[ajburley]

Build 4.0-722 is a bit strange.

Build numbers situation

Build 4.0-722 was originally generated as a result of a commit with parent 4.0-720, with two file changes. Subsequently, build 4.0-732 was generated as a result of a commit with parent 4.0-722, with ten file changes.

However, some time later (between builds 4.0-746 and 4.0-748), a commit was made with parent 4.0-720 with one file change. This build was therefore numbered 4.0-721, even though it came after 4.0-746. After that, another commit with one file change was made with parent 4.0-720. This build was also numbered 4.0-721 and the original 4.0-721 plus its commit ceased to exist outside of Dolphin's own database.

Now, another commit was made with a parent of (the new) 4.0-721. So this build was numbered 4.0-722 by the build tool. This overwrote the original 4.0-722, so that build is no longer available on the build server. However, the 4.0-722 commit was simply a revert of the parent 4.0-721 commit, so that this new 4.0-722 build is identical to 4.0-720. Furthermore, the two commits leading to the new 4.0-721 and the new 4.0-722 were subsequently nuked from the repository, even though they are still accessible on GitHub's database.

Since there are two builds called 4.0-721 and 4.0-722 on Dolphin's database, the Dolphin website (accessed by DBT via "dolp.in") cannot handle the situation and displays an "Internal Server Error" when trying to load the detail pages for these builds.

Build numbers summary

Numbering the first and second versions of 4.0-721/722 with "a" and "b" suffixes for clarity, the parent structure looks like this:

4.0-720 -> 4.0-722a -> 4.0-732 -> ... -> 4.0-746 -> 4.0-748 -> ... -> 5.0-xxx
        \
         \-> 4.0-721a
          \
           \-> 4.0-721b -> 4.0-722b

(NB: 4.0-721a, 4.0-721b and 4.0-722b are not ancestors of the current Dolphin versions.)

Whereas the chronological series looks like this:

4.0-720 -> 4.0-722a -> 4.0-732 -> ... -> 4.0-746 -> 4.0-721a -> 4.0-721b -> 4.0-722b -> 4.0-748 -> ... -> 5.0-xxx

The details of the builds' availability;

4.0-720, 4.0-732, 4.0-746, 4.0-748 (normal builds):

• Build IS available on the build server
• Build details CAN be viewed through "dolp.in"
• Commit IS available in GitHub
• Commit IS available in the Git repository

4.0-721a:

• Build IS NOT available on the build server (was overwritten by 4.0-721b)
• Build details CANNOT be viewed through "dolp.in" (with or without the "a" suffix)
• Commit IS NOT available in GitHub
• Commit IS NOT available in the Git repository

4.0-721b:

• Build IS available on the build server
• Build details CANNOT be viewed through "dolp.in" (with or without the "b" suffix)
• Commit IS available in GitHub
• Commit IS NOT available in the Git repository

4.0-722a:

• Build IS NOT available on the build server (was overwritten by 4.0-722b)
• Build details CANNOT be viewed through "dolp.in" (with or without the "a" suffix)
• Commit IS available in GitHub
• Commit IS available in the Git repository

4.0-722b:

• Build IS available on the build server (but is identical to 4.0-720 in all but number)
• Build details CANNOT be viewed through "dolp.in" (with or without the "b" suffix)
• Commit IS available in GitHub
• Commit IS NOT available in the Git repository (but is identical to 4.0-720 in all but history)

DBT problems

Due to the above anomalies, DBT exhibits some problems. In particular, I had an issue with Dolphin itself which was actually caused by the first Dolphin 4.0-722 (called "4.0-722a" above). DBT reported to me that the issue occurred between 4.0-722 and 4.0-732. This was confusing as the changes between 4.0-722 (the first one) and 4.0-732 were all Android changes, and I was running on Windows. The second 4.0-722 was not in the ancestry chain of 4.0-732 so it seemed DBT could not be referring to the latter build as this would not make sense. Furthermore, DBT provided me with a choice to open the details page of 4.0-722, but as mentioned above, this causes an internal server error.

Of course, what actually happened is that the build which DBT calls "4.0-722" is actually the second 4.0-722, which is identical to 4.0-720 in all but number. This is also not in the ancestry chain of 4.0-732, so it doesn't make sense to say "between 4.0-720 and 4.0-732" (or similar). Instead, the best DBT can say in this situation is that the issue occurred between 4.0-720 and 4.0-732.

Possible solutions

Since the second 4.0-722 and both 4.0-721 builds are not in the commit ancestry chains of current Dolphin releases, it does not really make sense to include these in the bisection at all. However, if a user does get an issue (with Dolphin itself) which occurred between 4.0-720 and 4.0-732, this needs special handling. Normally, DBT assumes it has found a pair of consecutive builds which the issue occurred between, which means it's perfectly acceptable to suggest the user views the build details page for the lower numbered build. However 4.0-720 and 4.0-732 are not consecutive - it's just that the build in-between (the first 4.0-722) is no longer available on the build server and so cannot be tested. For example, DBT could display a message like:

"Your issue seemed to occur between non-consecutive builds 4.0-720 and 4.0-732. Do you want to open the build details page for 4.0-720 or the intermediate build 4.0-722?"

with two options. Of course, if the user elected to open the details page for 4,0-722, we would have to reference the build by the actual commit hash as opposed to the build number, as trying to reference by the build number triggers an internal server error as mentioned above, as the Dolphin website doesn't know which of the two 4.0-722 builds you want to load the details of.

Alternatively, we could even do a manual build of the first 4.0-722 based on the actual commit (still available in the Git repository) and make that available somewhere for DBT to pull instead of the 4.0-722 on the build server (which is basically 4.0-720 for all intents and purposes)?

[Helios747]

Oh, nice catch. I never realized we had builds like that. Hrm, yeah this is a bit of a tricky problem that we run into because the entire goal of the tool is to keep the user as far away from git as possible to the point of not even using it. This is going to inevitably going to lead to a hacky fix no matter what we do without just shipping git with DBT and using git to figure out which builds to get, which I don't like the idea of.

I'll think about this problem for awhile. Looking these builds up, they aren't trivial builds either.

In any case, I need to get focused on fixing the tool in general. Due to infra changes the tool isn't working at all. I've been slow to fix it due to being busy with life stuff.

[Helios747]

So the tool is fixed now, but I know this bug still remains, and might actually be worse now. Now that I have a proper buildlist implemented in infra, I took a look at the builds that infra produced for 721/722.

They're... Just the exact same names. Just multiple entries. So now what my bisect tool will do is treat it as a separate build, but it will be confusing as hell to the user if one of those builds ends up being the build that caused their bugs, because the issue becomes "okay which 4.0-721/722?"

I still can't think of a good solution to this and may end up hardcoding crap to work around this or at least inform the user that they hit a problem build.