Steps completed at the same time shown in wrong order

[ebray]

This is similar to ​trac:#5153. On build listings the individual steps can be shown in the wrong order if they completed at the same time. This is because they're retrieved via BuildStatus.select() which returns the steps ordered by stop time.

A reasonable temporary fix might be to order the steps by start time instead:

model.py

@@ -654 +654 @@
             where = ""
 
         cursor = db.cursor()
-        cursor.execute("SELECT build,name FROM bitten_step %s ORDER BY stopped"
+        cursor.execute("SELECT build,name FROM bitten_step %s ORDER BY started"
                        % where, [wc[1] for wc in where_clauses])
         for build, name in cursor:
             yield BuildStep.fetch(env, build, name, db=db)

This fixes the problem in my case. But one could also probably create a case where two steps started at the same second. A long term solution would be to find a way to ensure that steps are always ordered according to their order in the build recipe.

[osimons]

In [702] I've included a fix for this - slave basically halts for 1 second if previous step finished in the same second as the current one. This should ensure that in common usage this issue should no longer arise (for newer builds that is).

[osimons]

...and closing.

[hodgestar+bitten@…]

Patch that adds a stepno field to Build Step?.

[hodgestar+bitten@…]

For what it's worth I've attached a patch that adds a stepno field that keeps track of the correct order for build steps. It's missing a database upgrade script and some more thorough testing but I can add those if there is interest in applying the patch.

[dfraser]

Replying to hodgestar+bitten@…:

For what it's worth I've attached a patch that adds a stepno field that keeps track of the correct order for build steps. It's missing a database upgrade script and some more thorough testing but I can add those if there is interest in applying the patch.

I think it's worth having the stepno included, it's a more complete and reliable solution than the current one.