886522 - allow post release tasks to be triggered from ship it

Status: RESOLVED WONTFIX

(Release Engineering :: Applications: Shipit, defect, P3)

Description

[[e-mail] (:bhearsum)]

Right now we kickoff a "postrelease" builder to do some things. This is a simple "force build" from the Buildbot interface. We should have a button on Ship It that does this, and any other automated post release tasks. Eg, pushsnip and bouncer entries once they're automated.

Comment 1

[[e-mail] (:bhearsum)]

Rail and I talked about this today and figured out a plan.

Ship It currently tracks a release from initial submission, through review, and until the automation starts (currently known as "complete"). Properly fixing this bug requires that we change this model to track releases from initial submission all the way through to shipping. This will require some non-trivial schema changes and additional communication with Ship It throughout the release process.

We currently have a few different states for a release to be in: Submitted, Pending, Running (currently known as "complete"). We currently have two columns ("ready" and "complete") that let us represent this state in the database. After this work is complete we will have more states for the overall release: Submitted, Pending, Running. In order to avoid column explosion, we'll be replacing the "ready" and "complete" columns with a single enum known as "kickoffStatus".

Once a release successful runs through the automation it will be in a separately tracked state known as "readyForRelease".

We will also need statuses for the post-release tasks, which need to be tracked separately because they can happen in parallel. Both pushsnip and postrelease could be in any of these states: Not run, Pending, Running, Complete, or Failed. These will be tracked in "pushsnipStatus" and "postrelease" status enum columns.

Once both postrelease and pushsnip are Complete, a release is considered to be fully complete.

In-between the kickoffStatus and postrelease/pushsnip statuses we 

Below is a listing of all the statuses in the new world, and what sets them:
* kickoffStatus:
** Submitted - initial state
** Pending - set after a release is reviewed through the web
** Running - set by release runner after release is successfully
* readyForRelease - set by the "ready for release" Buildbot builder
* pushsnipStatus/postreleaseStatus:
** Not run - initial state
** Pending - set after the button is clicked on web interface
** Running - set by release runner after it successfully submits a the job to Buildbot
** Complete - set by the the builder after it successfully pushes snipptes
** Failed - set by the the builder if it fails to push snippets

The fully complete state is not explicitly set in the database but rather inferred by pushsnipStatus and postreleaseStatus both being "Complete".

Other things we need to do:
* UI changes to separate releases at different points into different sections and expose the "pushsnip" and "postrelease" buttons only at appropriate times
* Implement a new Builder that will run pushsnip and hook it and the existing postrelease builder up to their own Schedulers that can be triggered through SendChange
* Update postrelease script to talk to report status to Ship It
* Update release runner to use new status fields, and be able to trigger pushsnip and postrelease builders through SendChange


This work should probably get farmed off into different bugs.

Comment 2

[[e-mail] (:bhearsum)]

We should probably prevent system accounts from being able to trigger new releases via some sort of ACL or hardcoded exception list.

Comment 3

[[e-mail] (:bhearsum)]

per-locale support in patcher-configs/snippet tools tracked in bug 894541.

Comment 4

[[e-mail] (:bhearsum)]

bug 1038596 talks about confusion surrounding ship it requiring build #s for previous releases, and things like the updates builder not taking them into account. When this bug is implemented we should be able to programmatically detect which build # for a release was shipped. When we have that, we should be able to only required version numbers for previous releases, and find the build # ourselves.

Comment 6

[[e-mail] (:bhearsum)]

Mass component change for ship it bugs.

Comment 7

[Rail Aliiev [:rail]]

shipitv2ftw