851696 - B2G build should contain something saying what code it was built from

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: GonkIntegration, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It's generally good practice to be able to replicate builds of software.  This makes it possible to do things like bisect regressions.

The B2G (Firefox OS) builds from a large number of repositories; a regression could in theory come from any of these.

Just like a firefox build comes with a file (application.ini) that says what source code that build was built from, a B2G device should contain a file that says what source code it was built from.

The "repo" command has a great way to generate such a file, the "repo manifest -r" command.  For example, "repo manifest -r -o -" outputs a repo manifest that describes all of the repositories pulled by repo.  (There's one catch here, which is that it's missing the root B2G repository that contains repo.)

The build process ought to include this information (the output of "repo manifest -r" and the equivalent for the B2G repository) in the build output (i.e., what gets put on the phone) so that we can figure out what sources builds are built from and so we are able to bisect regressions in any repository.

(And, in the long term, once we're generating this information, we ought to store it somewhere, but that's separate from this bug.)

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Er, never mind, system/sources.xml already does this.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(Though the sources.xml doesn't seem to be updated correctly unless I clobber the output directory (or part of it, presumably).  I'll try to look into that sometime...)

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #2)
> (Though the sources.xml doesn't seem to be updated correctly unless I
> clobber the output directory (or part of it, presumably).  I'll try to look
> into that sometime...)

filed bug 854121