Opened 3 years ago

Closed 3 years ago

#3532 closed defect (fixed)

Inconsistence in foreign key makes changes related schedulers not firing

Reported by: gracinet Owned by: gracinet
Priority: major Milestone: 0.9.0
Version: 0.9.0b7 Keywords:
Cc:

Description

Main symptom: only some of the SingleBranchScheduler and other changesources oriented schedulers actually launch builds.

The reason is that at some point, once the change has been analysed and categorized as "important", this information gets stored in the scheduler_changes table to serve as a basis to launch the builds. This table as a column schedulerid, but the code actually uses the objectid attribute, that is the id of the scheduler in the objects table, not the one in schedulers table.

As a result, those schedulers whose id in the objects table is not an existing id of the schedulers table aren't able to launch any build, because the line in scheduler_changes cannot be written (this should probably be more evident in buildbot logs).

Given that the code is completely consistent on this, I see two possible ways of fixing this:

  1. make it official that the schedulerid column of the scheduler_changes table is a reference to the objects table, i.e., change foreign key definition
  2. have the code reading and writing to that table actually use the id from the schedulers table

If I understand correctly, the objects table is meant to be referenced from the object_state table (somewhat unstructured state data) and 2. should be the preferred solution, although it entails more changes to the code.

Change History (4)

comment:1 Changed 3 years ago by tardyp

if I understand correctly, this should be fixed by https://github.com/buildbot/buildbot/pull/2190

Please close if I'm right

comment:2 Changed 3 years ago by tardyp

  • Owner set to gracinet
  • Status changed from new to assigned

comment:3 Changed 3 years ago by rutsky

@gracinet, ping. Is this issue resolved?

comment:4 Changed 3 years ago by gracinet

  • Resolution set to fixed
  • Status changed from assigned to closed

@rutsky, yes it works for me (just rechecked that)

Note: See TracTickets for help on using tickets.