Closed Bug 1561934 Opened 3 months ago Closed 3 months ago

Please clone comm-beta to releases/comm-esr68


(Developer Services :: Mercurial:, task)

Not set


(Not tracked)



(Reporter: rjl, Assigned: sheehan)




(6 files)

Please clone the default branch of comm-beta to releases/comm-esr68. The configuration should be the same as comm-esr60.
The earliest we'll need it is merge day on 7/8.

I will kick this off this afternoon.

Bug 1555777 contains similar work done for esr68.

Assignee: nobody → sheehan
See Also: → 1555777

The repo is already cloned on-disk, this will make it available
over http.

This will make the hgweb mirrors in AWS take action on events
for the new repo. The rule has already been manually set on
the mirrors to allow the initial clone to replicate.

Closed: 3 months ago
Resolution: --- → FIXED

Landed all the patches and created the repo, but I still need to deploy this.

Resolution: FIXED → ---

(In reply to Jorg K (GMT+2) from comment #7)

Yes, like doesn't work right now. What about a treeherder -

It will show up after the deploy, which I have just kicked off. I've set the required Treeherder variable in the hgrc, but you may need to coordinate with Treeherder to get CI running (I'm not actually sure).

Closed: 3 months ago3 months ago
Resolution: --- → FIXED

Repository is already set up.

When trying to push to comm-esr68 today I get the following:

pushing to ssh://
searching for changes
remote: abort: could not lock working directory of /repo/hg/mozilla/releases/comm-esr68: Permission denied                                                      
abort: stream ended unexpectedly (got 0 bytes, expected 4)

Talked to Tom Prince on IRC and he suggested:

I bet it doesn't have the proper owner. clokep: I'd ni sh.eehan on the creation bug with that error

Thanks in advance!

Flags: needinfo?(sheehan)

I doubled checked the permissions and they seem to be in order. Just to be safe I ran the permission setting script, and it did change the mode on some files. Try again and see if that helped (though I doubt it would have mattered).

I'd say it's more likely you have lost your push privileges on due to inactivity. Try directly SSH'ing in to and making sure you are able to push to scm_level_3 repositories (something like ssh -i <path to your key>). If you don't have the permissions any more, you need to file a bug to have them re-instated. Usually it's quite quick turnaround as long as you've had scm_level_3 at some point in the recent past.

Flags: needinfo?(sheehan)

Patrick pushed to C-C and C-B as part of the merges, so his privileges worked yesterday :-)

(In reply to Jorg K (GMT+2) from comment #13)

Patrick pushed to C-C and C-B as part of the merges, so his privileges worked yesterday :-)

Hmmmm in that case, it probably was those files with bad modes. Try pushing again and let me know if you still can't get through. :)

I just pushed again and it worked fine, so seems like it was a bad file permission. Thanks for taking care of this!

Attachment #9076639 - Flags: review?(cdawson) → review+
You need to log in before you can comment on or make changes to this bug.