How do you reset the Buildbot build number

Question

I'm setting up a new automated build. Of course, I'm not getting it right on the first try. I'm already at my 9th attempt and so the build number is already up to 9 build using "%(prop:buildnumber)". buildbot is incrementing the build number with each build as expected.

We are using the build number as part of the version number of our product. after I get it all working, I'd like to start with build 1.

Answer 1

I also found myself wanting to do this recently. As far as I know, there are three options:

1. Remove and re-initialize the sqlite database (destructive choice);
2. Create a new master that will start again at buildnumber:1 (safest choice);
3. Strip out the buildsets you don't want from the sqlite database (least safe choice);

The database:

Each Buildbot master stores all its information about past and present builds in the sqlite database file state.sqlite.

You can view that information stored within the tables of that database:

$ sqlite3 state.sqlite 
sqlite> .mode table
sqlite> SELECT * FROM builds;

Output:

+----+--------+-----------+----------------+----------+----------+------------+-------------+--------------------------------+---------+
| id | number | builderid | buildrequestid | workerid | masterid | started_at | complete_at |          state_string          | results |
+----+--------+-----------+----------------+----------+----------+------------+-------------+--------------------------------+---------+
| 1  | 1      | 1         | 1              | 1        | 1        | 1674211399 | 1674211399  | failed update (failure)        | 2       |
| 2  | 2      | 1         | 2              | 1        | 1        | 1674211660 | 1674211681  | failed update (failure)        | 2       |
| 3  | 3      | 1         | 3              | 1        | 1        | 1674211933 | 1674211933  | failed 'trial hello' (failure) | 2       |
| 4  | 4      | 1         | 4              | 1        | 1        | 1674211995 | 1674211996  | build successful               | 0       |
| 5  | 5      | 1         | 5              | 1        | 1        | 1677067881 | 1677067881  | build successful               | 0       |
| 6  | 6      | 1         | 6              | 1        | 1        | 1677067888 | 1677067889  | build successful               | 0       |
| 7  | 7      | 1         | 7              | 1        | 1        | 1677068026 | 1677068027  | build successful               | 0       |
| 8  | 8      | 1         | 8              | 1        | 1        | 1677068077 | 1677068077  | build successful               | 0       |
| 9  | 9      | 1         | 9              | 1        | 1        | 1677068113 | 1677068114  | build successful               | 0       |
| 10 | 10     | 1         | 10             | 1        | 1        | 1677068129 | 1677068130  | build successful               | 0       |
| 11 | 11     | 1         | 11             | 1        | 1        | 1677068181 | 1677068182  | build successful               | 0       |
| 12 | 12     | 1         | 12             | 1        | 1        | 1677068371 | 1677068371  | build successful               | 0       |
| 13 | 13     | 1         | 13             | 1        | 1        | 1677068499 | 1677068500  | build successful               | 0       |
| 14 | 1      | 2         | 14             | 1        | 1        | 1677069371 | 1677069372  | build successful               | 0       |
| 15 | 2      | 2         | 15             | 1        | 1        | 1677069374 | 1677069375  | build successful               | 0       |
+----+--------+-----------+----------------+----------+----------+------------+-------------+--------------------------------+---------+

As shown on the Web UI:

Option 1: If you want to blow away everything and start from scratch, simply move the database and re-initialize it:

# Stop master
buildbot stop msample

# Move (backup) the old database
mv msample/state.sqlite ~/backups

# Re-initialize the database and restart
buildbot upgrade-master /var/lib/buildbot/masters/msample
buildbot start msample/

After that you'll notice that most of the tables are empty, and that none of the builders have any history on the web UI.

Option 2: If you add a new builder, you can start counting from buildnumber:1 again, without losing any historical records of completed builds.

Create a new builder in your config, pointing to the same build factory and same worker:

c['builders'].append(
    util.BuilderConfig(name="runtests3",
      workernames=["foobar"],
      factory=factory))

And then add a scheduler that triggers that new builder. Here I kept a ForceScheduler pointing to runtests1 and runtests2 builders, because every builder needs a scheduler to drive it, or otherwise the master won't restart:

c['schedulers'] = []
c['schedulers'].append(schedulers.AnyBranchScheduler(
                            name="all",
                            treeStableTimer=None,
                            builderNames=["runtests3"]))
c['schedulers'].append(schedulers.ForceScheduler(
                            name="force",
                            builderNames=["runtests", "runtests2", "runtests3"]))

Then you'll have a new builder that does exactly the same thing, but starts counting from buildnumber:1 again:

Option 3: If you like to live dangerously, you can probably strip out the buildset ids that you wish never happened, or don't want to show on the web UI. I would back up your state.sqlite database file before doing this:

DELETE FROM "buildsets" WHERE ("rowid" = 1172)