Closed Bug 1374458 Opened 5 years ago Closed 4 years ago

automation should safeguard against short revisions in releasetasks_gen script

Categories

(Release Engineering :: Release Automation: Other, enhancement, P2)

enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mtabara, Unassigned)

References

Details

(Keywords: good-first-bug, Whiteboard: [releaseduty])

We need release runner + releasetasks_gen script to prevent and sanity check the revision is not shorter than 40chrs. I suspect release runner already does so, it's only a matter of releasetasks_gen.py script.
Or finish bug 1347635 sooner so that all the release-runner sanity checks are enabled for Fennec as well. 
 
&garndt> jlund: do you know about this task? https://github.com/mozilla-releng/releasetasks/blob/master/releasetasks/templates/desktop/beetmove_image.yml.tmpl#L3
22:15:26 <&garndt> I noticed an error when that task try to be reported to treeherder because the revision is only 12 characters (it failed schema validation which requires it to be 40 characters)
22:17:51 <jlund> garndt: revision from payload.env?
22:17:51 <jlund> I'm surprised only that task failed. the revision would be shared across all tasks within releasetasks for a given release
22:19:33 <&garndt> hrm
22:20:11 <&garndt> it's this task
22:20:12 <&garndt> https://tools.taskcluster.net/task-inspector/#IFBO6-E_Rm6MbS_PEBouCw/
22:20:32 <&garndt> and the revision that's in the routes is 12 characters, not sure why that is for this task
22:20:49 <&garndt> (same for payload.env.gecko_head_rev)
22:22:04 <jlund> garndt: sometimes we trigger a release and only specify the short hash in form field (via shipit)
22:22:17 <&garndt> ah, maybe that's why
22:22:17 <jlund> is it a new schema requirement to use 40 char?
22:22:25 <&garndt> it's been that way for quite some time now
22:23:06 <&garndt> https://github.com/taskcluster/taskcluster-treeherder/blob/master/schemas/pulse-job.yml#L58
22:23:13 <&garndt> since May 3, 2016 when we started using this
22:29:19 <jlund> jcristau: ^ looks like you used the short rev for Fennec-55.0b3-build1 in shipit
22:29:33 <jcristau> jlund: i did
22:29:53 ⇐ davehunt quit (davehunt@moz-iti21q.zen.co.uk) Quit: Leaving...
22:30:08 <jcristau> i guess usually i use tip and it's auto-completed, and this time i didn't
22:31:39 <jlund> hm, we should have sanity checks in place: https://dxr.mozilla.org/build-central/source/tools/buildfarm/release/release-runner.py#62
22:32:41 <jlund> Callek: mtabara ^ fyi. I suspect we run into issues using short revision with fennec because actual releasetasks graph gen is manual and outside our sanity check?
22:44:15 <mtabara> jlund: who said we run into issues? our automation is perfect :)
22:44:58 <jlund> :)
22:51:47 <jcristau> jlund: should i start a fennec build2 or can you/releaseduty sort it out?
22:56:38 — mtabara tries to catchup with context
22:57:12 <mtabara> are we afraid that other pieces might be falling apart down-the-streap if we rely on the current fennec 55.0b3-build1? because the graph is green so far
22:57:18 <mtabara> *stream
22:57:36 KWierso → KWierso|brb
22:57:39 <&garndt> from my perspective, I was only reporting the issue when it comes to delivering the results to treeherder.  I'm not sure if there are other issues down stream
22:58:29 <jlund> yeah, I think the routes will be different but not broken
Priority: -- → P2
Back to the releaseduty pool.
Assignee: mtabara → nobody
Keywords: good-first-bug
Whiteboard: [releaseduty]
releasetasks is no more.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.