I'm trying to finish the merges for comm-esr52, when pushing I get: ``` remote: ************************** ERROR **************************** remote: Error accessing https://api.pub.build.mozilla.org/treestatus/trees/comm-esr52-seamonkey : remote: HTTP Error 404: NOT FOUND remote: Unable to check if the tree is open - treating as if CLOSED. remote: To push regardless, include "CLOSED TREE" in your push comment. remote: ************************************************************* ``` My understanding is that there isn't a comm-esr52-seamonkey in treeherder (and SHOULDN'T be there), they release off of comm-release, not comm-esrXXX. There's no comm-esr45-seamonkey either. I just confirmed with Callek on IRC that they won't use comm-esr52. This seems related to https://hg.mozilla.org/hgcustom/version-control-tools/file/tip/hghooks/mozhghooks/treeclosure_comm_central.py / https://hg.mozilla.org/hgcustom/version-control-tools/file/tip/hghooks/mozhghooks/treeclosure.py

Also, my tip commit message is "Update client.py to pull from mozilla-esr52 by default a=release a=esrmerge ba=esrmerge CLOSED TREE" Which already has "CLOSED TREE" in it, so I think something is wrong (or this message is wrong saying that I can just add "CLOSED TREE" to avoid this message).

Treeherder != Tree Status; updating summary :-) It looks like your push succeeded: https://hg.mozilla.org/releases/comm-esr52/rev/835660435eaf ...which makes sense, since I see there's a bug in the error message. I've split this part out to bug 1345817. That said, the hghook should still be removed from this repo. (Someone from the hg.mozilla.org team will need to do this).

I didn't even consider looking if the push succeeded! Good to know. Sorry for the typo on treeherder/treestatus!

The only tree closure hook on this repo is: pretxnchangegroup.a_treeclosure = python:mozhghooks.treeclosure_comm_central.hook Please verify that this hook should be removed from comm-esr52.

I'm a confused. What's the difference between https://api.pub.build.mozilla.org/treestatus/trees/comm-central-seamonkey and https://api.pub.build.mozilla.org/treestatus/trees/comm-central-thunderbird? also, if in the near future SeaMonkey builds off comm-esr52, would we need a comm-esr52-seamonkey?

Any chance to get this fixed? I'm running into the problem when doing uplifts to comm-esr52. > Someone from the hg.mozilla.org team will need to do this. Ed, who do I ask?

(In reply to Kendall Libby [:fubar] from comment #4) > The only tree closure hook on this repo is: > > pretxnchangegroup.a_treeclosure = > python:mozhghooks.treeclosure_comm_central.hook > > Please verify that this hook should be removed from comm-esr52. I doubt this hook should be removed, as far as I can tell this is what checks if comm-esr52-thunderbird is open or not. What hook is running on comm-esr45? That hook is configured appropriately, to my knowledge.

(In reply to Edmund Wong (:ewong) from comment #5) > I'm a confused. > > What's the difference between > https://api.pub.build.mozilla.org/treestatus/trees/comm-central-seamonkey > and > https://api.pub.build.mozilla.org/treestatus/trees/comm-central-thunderbird? SeaMonkey and Thunderbird can individually have their trees open/closed/approval-needed. (This exists for every iteration of the comm-* tree.) Thus if SeaMonkey is closed you can check if files under mail/ without doing anything special, but suite/ and mailnews/ will require approval flags. > also, if in the near future SeaMonkey builds off comm-esr52, would we need > a comm-esr52-seamonkey? Yes. As far as I know, SeaMonkey has no plans to start using ESRs.

(In reply to Jorg K (GMT+1) from comment #6) > Any chance to get this fixed? I'm running into the problem when doing > uplifts to comm-esr52. > > > Someone from the hg.mozilla.org team will need to do this. > Ed, who do I ask? :gps or :fubar

(In reply to Patrick Cloke [:clokep] from comment #7) > > I doubt this hook should be removed, as far as I can tell this is what > checks if comm-esr52-thunderbird is open or not. > > What hook is running on comm-esr45? That hook is configured appropriately, > to my knowledge. There is no difference in hooks between comm-esr45 and comm-esr52. hgssh4.dmz.scl3# diff comm-esr45/.hg/hgrc comm-esr52/.hg/hgrc 0a1,5 > [format] > usegeneraldelta = true > generaldelta = true > aggressivemergedeltas = true > 9c14 < description = Thunderbird Extended Support Release 45 --- > description = Thunderbird Extended Support Release 52 12c17,18 < treeherder_repo = comm-esr45 --- > treeherder_repo = comm-esr52 > AFAICT there's something amiss in treeclosure_comm_central.py but it exceeds my knowledge. Thankfully, gps is back; NI set.

(In reply to Patrick Cloke [:clokep] from comment #8) > (In reply to Edmund Wong (:ewong) from comment #5) > > I'm a confused. > > > > What's the difference between > > https://api.pub.build.mozilla.org/treestatus/trees/comm-central-seamonkey > > and > > https://api.pub.build.mozilla.org/treestatus/trees/comm-central-thunderbird? > > SeaMonkey and Thunderbird can individually have their trees > open/closed/approval-needed. (This exists for every iteration of the comm-* > tree.) Thus if SeaMonkey is closed you can check if files under mail/ > without doing anything special, but suite/ and mailnews/ will require > approval flags. > > > also, if in the near future SeaMonkey builds off comm-esr52, would we need > > a comm-esr52-seamonkey? > > Yes. As far as I know, SeaMonkey has no plans to start using ESRs. There are plans to use ESR52 by SeaMonkey, so what needs doing to fix the 404 issue?

I checked with Callek again on IRC and he confirmed that IanN and ewong know more up-to-date plans for SeaMonkey. Sounds like we "just" need to add this to treestatus then! Hopefully choosing the right component here...

Added comm-esr52-seamonkey to treestatus. Default state is Closed.

I think adding the entry to treestatus fixed this and no hg.mo change is needed?

The hook still seems broken beyond the bug 1345817 brokenness, if comment 0 is correctly reporting that it checked isPushAllowed(comm-esr52, comm-esr52-seamonkey) for a push which touched /client.py and /mail/confvars.sh, since https://hg.mozilla.org/hgcustom/version-control-tools/file/06154c69e174/hghooks/mozhghooks/treeclosure_comm_central.py#l25 should only cause that to be checked for pushes which touch a file in /suite/. Without understanding and fixing that, we can only claim it's fixed by adding the treestatus entry if we update the docs on creating a comm-esr branch to say "because the hook is broken, create or ask to have created a treestatus entry for both comm-esrnn and comm-esrnn-seamonkey whether or not SeaMonkey is planning on using this branch."

(In reply to Wes Kocher (:KWierso) from comment #13) > Added comm-esr52-seamonkey to treestatus. Default state is Closed. Thanks Wes!

(In reply to Phil Ringnalda (:philor) from comment #15) > The hook still seems broken beyond the bug 1345817 brokenness, if comment 0 > is correctly reporting that it checked isPushAllowed(comm-esr52, > comm-esr52-seamonkey) for a push which touched /client.py and > /mail/confvars.sh, since > https://hg.mozilla.org/hgcustom/version-control-tools/file/06154c69e174/ > hghooks/mozhghooks/treeclosure_comm_central.py#l25 should only cause that to > be checked for pushes which touch a file in /suite/. Without understanding > and fixing that, we can only claim it's fixed by adding the treestatus entry > if we update the docs on creating a comm-esr branch to say "because the hook > is broken, create or ask to have created a treestatus entry for both > comm-esrnn and comm-esrnn-seamonkey whether or not SeaMonkey is planning on > using this branch." I don't think this is right. Why do you say it touched only client.py and mail/confvars.sh? This was during merges, I was touching tons of files (including suite/ files). jorgk can you verify if this is fixed during your next uplift?

(In reply to Patrick Cloke [:clokep] from comment #17) > jorgk can you verify if this is fixed during your next uplift? Yes and no. I only get problems when landing something on suite/ but I don't know when I'll have to do that next time.

I landet some patches yesterday evening but they had closed tree in them. The push output looked normal.

I think this is all set then! Thanks Frank and Jorg for verifying.