implement shippable builds

NEW
Unassigned

Status

P3
normal
2 years ago
3 months ago

People

(Reporter: aki, Unassigned)

Tracking

(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [releng:q32018])

(Reporter)

Description

2 years ago
Shippable builds will most likely require taskcluster nightlies... so we *could* proceed with linux and android at this point, or wait until osx and windows are on TC.

This is a writeup of https://github.com/mozilla/build-relengdocs/blob/master/future/index.rst#shippable-builds and https://groups.google.com/forum/#!topic/mozilla.release.engineering/MRfHnhaVI48 .

Let's:
- rename 'nightly' builds to 'shippable' builds

- get rid of 'pgo' builds

- have a second promotion graph to ship shippable builds

- (possibly rename 'depend' to 'ci', but that doesn't have full agreement.)

promotion graph
===============

- move the actual shipping tasks (beetmover, balrog, pushapk) to a second promotion graph.  These should depend on the build or signing tasks in the build graph as their upstreamArtifacts.

    - the decision task for the second promotion graph needs to be able find the latest successful shippable graph, possibly through dummy task indexes, on mozilla-central and mozilla-aurora.  On mozilla-beta, mozilla-release, and mozilla-esr, we can specify the shippable graph/tasks to use.

scheduling
==========

- shippable builds should periodically on integration branches, with backfill capability.

    - every 4 hours?  Ideally let's not automatically re-run a shippable build on revision X if one has already successfully been triggered.

- both depend and shippable builds should be choosable using try syntax.

- on central/aurora/beta/release/esr*, let's build shippable builds on push and drop depend opt builds.
(Reporter)

Comment 1

2 years ago
:jmaher, periodic shippable builds on integration branches may be problematic if talos still needs to run in chronological order.  I know that was the case in the graph.m.o days; is that still the case with perfherder?
Flags: needinfo?(jmaher)
perfherder stores data by the revision, not by the date the data was generated, so if I understand the definition of chronological order in reference to the question, then this will not be problematic :)
Flags: needinfo?(jmaher)
Priority: -- → P3

Updated

9 months ago
Duplicate of this bug: 932211

Updated

9 months ago
Depends on: 1416538
(Assignee)

Updated

6 months ago
Component: General Automation → General
Product: Release Engineering → Release Engineering

Updated

3 months ago
Whiteboard: [releng:q32018]
You need to log in before you can comment on or make changes to this bug.