Bileto

Lock silos marked ready for QA

Bug #1606816 reported by Jean-Baptiste Lallement
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bileto
Invalid
Low
Unassigned

Bug Description

Regularly, teams modify silos already marked 'ready for QA' and already being verified by adding new branches. It completely invalidates the verification which must be redone. It's a waste of time for everyone.

Since self discipline doesn't work, we'd need to enforce this rule in bileto:
- When a silo is marked 'ready for qa' (after britney set automated tests to pass, or set manually), it cannot be modified until the QA state is set to pass (ready to publish) or fail.
- If the silo is set to fail QA, the silo is unlocked and MPs can be modified or added.

Revision history for this message
Dave Morley (davmor2) wrote :

I can confirm that I have gone to install a silo before now the ticket has been good but the silo has failed to install, you go back to the ticket and a rebuild has been triggered.

The whole point of ready for QA is it is read for qa, not well you can test it as it is but we'll be adding more stuff. :)

Many thanks

Changed in bileto:
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Robert Bruce Park (robru) wrote :

Are you sure that locking the ticket is the correct thing to do? It is already the case that a rebuild will clear the "QA ready" state, and various other failures will as well. I think the bot that creates the Trello cards should remove the cards from the queue when the QA state stops being ready. Eg instead of locking out Landers you guys just need to start noticing when a lander has done something to drop out of the queue.

There might also be bugs where some things should clear QA ready but don't, that's something we should look at, but QA state gets cleared by a lot of things already.

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

Yeah, you're right. That would just address one case. What we need to know if is a rebuild has been triggered because the content of the silo has changed or because of an external factor (like another silo with the same component has landed)

Changed in bileto:
importance: High → Low
Revision history for this message
Robert Bruce Park (robru) wrote :

I don't understand why you need to make that distinction? If another silo has landed and then this silo was rebuilt to incorporate it, either way the packages are rebuilt with different contents that need to be verified.

Changed in bileto:
status: Confirmed → Incomplete
Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

I fixed this case with the bt to detect silos that changed under QA's feet. This is no longer an issue and I'm closing this report.

Changed in bileto:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.