changing oldest revision in build recipe doesn't affect queued builds

[jared.jennings@…]

When I change the 'oldest revision' in the build recipe, e.g. change it to 654 because my revision 653 causes my build slave to hang with an OSError because of #103 ;), save the changes, then restart the build slave, the build master doesn't take the change into account. It still tries to get the slave to build 653, because (in this case) it never got a reply from the slave as to its success or failure, and I believe that means 653 is still in the master's queue. Restarting the master alleviates this problem.

(I'm using 0.5.2 but there isn't a version entry for that.)

[anonymous]

Actually restarting the build master does not appear to help. The build slave still tries to build a revision one less than the oldest one I specified.

[jared.jennings@…]

Oops, the comment above is mine.

[matt.hughes@…]

Slaves continue to run builds with rev numbers < min_rev because changing the min_rev has no effect on the existing queue of pending builds. This patch changes the type of the rev numbers to int and deletes pending builds for revisions < min_rev when a build config is updated. Assumes that the author criteria patch of ticket #110 has been applied.

[cmlenz]

Unfortunately, we can't assume that the revision is a serial integer. It is in Subversion, but not necessarily so in other version control systems.

[cmlenz]

AFAICT this no longer applies to trunk and the upcoming 0.6. There is no long-running master process, and obsolete builds are explicitly purged from the database.