Closed Bug 1126165 Opened 11 years ago Closed 10 years ago

.hg/hgrc config files should get replicated during `hg pull`

Categories

(Developer Services :: Mercurial: hg.mozilla.org, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: gps, Unassigned)

References

Details

When hg.mozilla.org was all served off NFS, all hgrc files were automatically in sync. Now that we have separate servers, the hgrc files must be modified in several locations. We should use `hg pull` to synchronize hgrc files so we don't have to maintain custom code everywhere that hgrc files are modified. There is potentially a security concern here. hgrc files may reveal things like credentials. We should think long and hard about who has access to hgrc file content. In a SSH world, it should be trivial to whitelist access to the hgrc files to a specific user.
hwine and bkero: can either of you think of a good reason why we wouldn't want per-repo hgrc files to be synchronized completely? I know we're doing some wonky things around installing dummy extensions/hooks on hgweb machines to cancel out configs that are only appropriate to the server. I suppose I could build filtering into the syncing mechanism if it's a problem. But I'm more inclined to issue overrides for "read-only" mode in in the system hgrc. That way, we can do things like expose the set of enabled hooks via hgweb :)
Flags: needinfo?(hwine)
Flags: needinfo?(bkero)
I couldn't think of any reason _to_ do the sync until I saw the chat about phases in #vcs. For the special case of push server -> web head, I guess it makes sense. However, I don't think we'd want any hook configurations to be sync'd. (Certainly, we don't want to repeat the IDL check on every web head.) Maybe a white list of sections to be synchronized? Or is it "phases only"?
Flags: needinfo?(hwine)
The thing is we already have hooks installed on the webheads. Here is part of mozilla-central's hgrc: [hooks] pretxnchangegroup.a_treeclosure = python:mozhghooks.treeclosure.hook pretxnchangegroup.b_singlehead = python:mozhghooks.single_head_per_branch.hook pretxnchangegroup.c_commitmessage = python:mozhghooks.commit-message.hook pretxnchangegroup.d_webidl = python:mozhghooks.prevent_webidl_changes.hook changegroup.push_printurls = python:mozhghooks.push_printurls.hook We have .py files of the appropriate name installed in an "overrides" directory that essentially turn these hooks into no-ops. It is extremely hacky. However, I think it is less hacky than having some kind of selective sync. I'll have to think about this some more.
Ah, I see, there's also cruft from rsync-no-clone -- got it. Per other comments in IRC, it sounds like we'd benefit from recreating the webhead repos via cloning for other reasons. That still leaves an issue of propagating phase state from push heads to web heads. An explicit and visible replication of phase state feels much "cleaner". Separate push/web heads is not (yet) a common configuration for hg. There are likely other concerns for that mode of operation -- leaving room to handle that all separately would be my first choice.
This should have been fixed in 1089385.
Flags: needinfo?(bkero)
(In reply to Ben Kero [:bkero] from comment #5) > This should have been fixed in 1089385. Not quite. We replicate changes via pash, and only after certain actions. We still don't have auto replication during the course of normal events. We should keep this bug open until configs replicate automatically.
Blocks: 1089465
The new replication system replicates hgrc files via its own mechanism. We don't need `hg pull` to replicate hgrc files automatically.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.