692301 - PGO builds not showing up, even though PGO tests are

Status: RESOLVED FIXED

(Tree Management Graveyard :: TBPL, defect)

Description

[John Ford [:jhford] CET/CEST Berlin Time]

Example https://tbpl.mozilla.org/?rev=9424f920e6ac

In case that falls off, the Windows build *is* a PGO build,

http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32-pgo

But it doesn't have a B for Win pgo

Win optBBm 1 2 3 4 5 oth C J R XT T T T T T T T T T T
Win pgo 1 2 3 4 5 oth C J R XT T T T T T T T T T T
Win debugB 1 2 3 4 5 oth C J R X

This is important to fix soon as it could increase our regression range for a PGO failure from 4h to 24h because PGO build failure will only be indicated by nightly builds

Comment 1

[Phil Ringnalda (:philor)]

I think this is from them being manually triggered, and having a got_revision but not a revision, and both ends of that, tbpl's "fall back to got_revision" and releng's "set a revision for manually triggered things" are filed, but I may be wrong. Hoping that the scheduled one will show properly.

Comment 2

[Arpad Borsos [:Swatinem]]

Yep, looking at the build json, those runs don’t have a proper revision set.

Comment 3

[Phil Ringnalda (:philor)]

The same is true of regularly scheduled pgo builds, both that they don't show, and that they don't have revision set.

Did we do a bad job of reverse engineering, and got_revision is actually the true revision, or are there other jobs I'm not seeing right now, which have a revision but not a got_revision? If both exist, are they always the same?

Comment 4

[Phil Ringnalda (:philor)]

Ah. Builds have a got_revision, and may or may not have a revision depending on what they are and how they got triggered, tests have a revision and do not have a got_revision.

Comment 5

[John Ford [:jhford] CET/CEST Berlin Time]

so... in the default case 'revision' is the revision, if set, from the change source (e.g. HGPoller).  Forced builds may or may not have this depending on whether one is inserted.

'got_revision' is a property set by default for all build steps.  By default, if you use a source step and are given a revision by the change source, got_revision should equal revision.

The short version is that 'revision' is what you asked for, 'got_revision' is what you got.  We have a couple places where we do nifty things which change which revision is actually there.  This new revision is set in the 'got_revision' property when we do make those changes.

If this were python, i'd personally do:

revision_to_display = properties.get('got_revision', properties.get('revision'))

Comment 6

[Arpad Borsos [:Swatinem]]

Is it possible that this revision/got_revision difference is the reason for bug 692353?

Comment 7

[Phil Ringnalda (:philor)]

Fixed by bug 689952