If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

HSTS and HPKP automatic updates are missing the revision prop so don't appear in Treeherder



Release Engineering
General Automation
10 months ago
9 months ago


(Reporter: aobreja, Unassigned)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)




10 months ago
Need this job (periodic file update) to be visible on Treeherder, for the moment we can check the logs at the bottom of this URL (1) but the job will not be visible on Treeherder as the script_repo_revision's value is not added  to revision of this job (check (2))

(2) https://bug1093196.bmoattachments.org/attachment.cgi?id=8804224

Comment 1

10 months ago
There are currently three ways in which jobs can end up in Treeherder:
1) If they are present in builds-(4hr,pending,running) with valid metadata
2) If they are submitted via Pulse (currently only Taskcluster hooked up to do this, but we want to encourage third parties to switch to this from the API too)
3) Via Treeherder's REST API (will be deprecated in the future)

It sounds like these jobs are supposed to be coming in via #1, but aren't due to them missing the revision property.

This isn't something Treeherder can (or would want to) resolve, so either the missing revision needs to be added, or if that's not possible, then these jobs will need to be submitted via #2 or #3 (ideally via #2 using Taskcluster). All of these alternatives are really release engineering tasks, so moving this to the appropriate component :-)
Component: Treeherder → General Automation
Product: Tree Management → Release Engineering
QA Contact: catlee
Summary: Make HSTS and HPKP automatic updates to be visible on treeherder → HSTS and HPKP automatic updates are missing the revision prop so don't appear in Treeherder
script_repo_revision is a https://hg.mozilla.org/build/tools/ revision, it's not going to do any good whatsoever.

What you need is bug 1093196 comment 14, to capture the revision which is created in the final three seconds of the script running, when it actually pushes, which will do very little good since the revision only exists when the script succeeded and nobody has any real interest in looking at the log. Actually fixing the intent of the second half of the morphing of bug 1093196 requires morphing it yet again, to be "find a way other than treeherder of notifying someone who cares when the periodic update task fails and thus fails to push anything."

Comment 3

9 months ago
Andrei: Were you able to setup a dev-master to test this?  I recall earlier talking to you about connecting a loaner to your dev-master and then applying your patches to a user repo copy of mozilla-central (or appropriate repo) 


Comment 4

9 months ago
Andrei, I looked at

/builds/buildbot/aobreja/test-hsts on dev-master2 after our conversation this  morning/.  Is this the master you setup to investigate this bug?

This appears to be setup as a test master, not a build master.  The job you are trying to debug is a build job.  


Comment 5

9 months ago
Yes Kim you are right,so I deleted the test master and created a build master  /builds/buildbot/aobreja/build-hsts on dev-master2

Comment 6

9 months ago
Andrei, you asked the other day how you could test this on your master without triggering a real test in production.  I'm not that familiar with these scripts, but if I look here 


looking here 
hg -R mozilla-aurora push -e "ssh -l ffxbld -i ~cltbld/.ssh/ffxbld_rsa" ssh://hg.mozilla.org/releases/mozilla-aurora
pushing to ssh://hg.mozilla.org/releases/mozilla-aurora

If you remove the ~cltbld/.ssh/ffxbld_rsa keys on your loaner I assume this would stop it from pushing to production
You need to log in before you can comment on or make changes to this bug.