1310207 - add "signoff" condition to scheduled changes

Status: RESOLVED DUPLICATE of bug 1310210

(Release Engineering Graveyard :: Applications: Balrog (backend), defect)

Description

[[e-mail] (:bhearsum)]

Multiple Signoffs will be implemented as a special type of condition on Scheduled Changes. Unlike existing conditions, it will not be something that a user can set when creating a change, it will always be required if the associated table has Signoffs enabled.

It also must be possible to use the Signoff condition in addition to one of the others, so some of the condition validation may need reworking as part of this.

The Signoff condition is considered to be fulfilled when Signoffs are found for all of the Required Roles. Signoffs will be stored in a separate table, that will associate sc_id's with individual Signoffs, so the Scheduled Changes table will need to look them up there. Required Roles will also be stored in a separate table, and should be looked up there.

Comment 1

[[e-mail] (:bhearsum)]

A special note about evaluating the "channel" in Required Roles: “channel” may have wildcards in it, (eg: release*), which must be considered when checking if a change needs Signoff. Wildcards will not be interpreted in the “channel” column of Required Roles (to avoid confusion and footguns), but the channel in a Rule must be interpreted and compared against the Required Role's channel.

Comment 2

[[e-mail] (:bhearsum)]

On open question here is whether or not the ScheduledChangesTable needs to know anything about this. Currently, the Balrog Agent is responsible for all interpretation of "is condition satisfied", so this logic may fully end up there. It may be a odd or non-obvious to have no references to Signoffs in the ScheduledChangesTable. Should think about this more when this bug is ready to be worked on - an obvious solution may present itself once the deps are fixed.

Comment 3

[[e-mail] (:bhearsum)]

This ended up happening as part of bug 1310210. We didn't end up creating a "signoff" condition that can be explicitly enabled or disabled the way "uptake" or "time" can, but rather it's a condition that's implied if the table can return Required Signoffs in getPotentialRequiredSignoffs.