{"push_id":659051417,"size":1,"distinct_size":0,"ref":"refs/heads/master","head":"bd5cf6d775bf9a2562e778d08043bf49cabdb8ef","before":"18cc888f4c0afcd0b35a8c299afd8dce68cee5ae","commits":[{"sha":"bd5cf6d775bf9a2562e778d08043bf49cabdb8ef","author":{"email":"3545c9e690e6f1fe34bf04279c8aa1ba0bf6192d@mozilla.com","name":"Ed Morley"},"message":"Bug 1093743 - Attempt to generate job_guids more consistently\n\nIn order that Treeherder can track a buildbot ingested job as it moves\nfrom pending to running to completed, a unique job_guid must be\ngenerated, since buildbot doesn't directly give us one. To make things\nworse, each of the three data sources (builds-{pending,running,4hr})\nmake slightly different properties available to us, and the data in them\nis not always correct. Until now we've been calculating the guid in such\na way that as some jobs (particularly those that are coalesced) change\nstate, the guid generated changes, causing us to think it's a brand new\njob, thereby leaving behind an orphaned pending/running job.\n\nThe new method of generating a guid uses only the single request_id\ncorresponding to the job that ran, rather than all of the request_ids.\nThis is because when in the pending state, there is only ever one\nrequest id, so if we use the full list later on, there is no way it will\nmatch, if the job had others coalesced into it.\n\nIn addition, the request_times properties are known to be unreliable\n(see bug 1141603), so we've stopped using them. This isn't a problem,\nsince they didn't help us with the buildbot retry case anyway (where the\nrequest id is recycled), and we already handle that by using endtime.\nWe instead now use the buildername to add uniqueness rather than the\nrequest_times.","distinct":false,"url":"https://api.github.com/repos/mozilla/treeherder/commits/bd5cf6d775bf9a2562e778d08043bf49cabdb8ef"}]}