Opened 12 years ago

Last modified 8 years ago

#97 new enhancement

Autoinstaller deploy/deploydev should use Git

Reported by: ezyang Owned by:
Priority: normal Milestone:
Component: autoinstallers Keywords:
Cc:

Description (last modified by adehnert)

Autoinstallers are no longer all on svn trunk, but they are still using svn. We may want to convert to git. (See below for Mitch's conditions.)

Change History (7)

comment:1 Changed 12 years ago by mitchb

deploy and deploydev have been on different branches for some time now, so the crucial problem is solved. As for switching to git, decisions about whether we'd like to aside, that really blocks on being able to do some form of auth for git without necessarily having login access to the account (so that people not on scripts-root could push to the repo). What would be really nice is GSSAPI analogous to what's desired for svn in ticket #79, but even password auth like we can kludge for svn presently via Apache would be a step up. We've asked for a git version bump in Fedora to get us a version that knows how to handle http and may be able to remove the block.

comment:2 Changed 11 years ago by adehnert

We have the necessary git technology now, I believe.

Can people with concerns about a switch to git articulate them? I'd like to at least seriously consider a switch.

comment:3 follow-ups: Changed 11 years ago by adehnert

Mitch says:

-> scripts / trac-#97 / AUTH: mitchb  2011-05-02 18:07:08  (Bell Labs Unix -- Reach out and grep someone.) / BYTE-ME.MIT.EDU
       A recent instance should be in
       /mit/sipbzlog/scripts-by-instance/packagefab

       """
       The things I want to insist on before we switch are:
       1) Authenticated push to scripts-hosted repos
       2) Unbypassable server-side hooks
       3) Commit mail (as a server-side hook) that contains the actual diff,
       and not just a cutesy-looking meaningless diffstat.

       We get all three of those with svn now, and they're important to
       tamper-resistance and ease of code review.
       """

(These are doable. It sounds like if we attain them, Mitch is okay with switching.)

comment:4 Changed 10 years ago by ezyang

  • Type changed from defect to enhancement

comment:5 Changed 9 years ago by adehnert

  • Description modified (diff)
  • Summary changed from Autoinstaller deploy/deploydev should be on different branches + use Git to Autoinstaller deploy/deploydev should use Git

comment:6 in reply to: ↑ 3 Changed 9 years ago by adehnert

Replying to Mitch (via adehnert):

The things I want to insist on before we switch are:

The ASA DB has all of these.

  1. Authenticated push to scripts-hosted repos

We use personal certs to authenticate users. .htpasswd files could also be used, I'm pretty sure.

  1. Unbypassable server-side hooks

This is true, except insofaras anybody with rlidwka on the repo could presumably suppress them. But that's presumably true of svn as well and ~unavoidable. I'm pretty sure that people pushing over HTTPS will cause the hook to execute (on scripts, so they can't avoid it).

  1. Commit mail (as a server-side hook) that contains the actual diff, and not just a cutesy-looking meaningless diffstat.

The current asa-db.git commit emails include diffs (I can post/forward a sample if anybody cares). (It also zephyrs the commit message and diffstat. It does not zephyr the full commit, though we can presumably change that easily enough if we care.)

comment:7 in reply to: ↑ 3 Changed 8 years ago by adehnert

Replying to adehnert:

2) Unbypassable server-side hooks

Mitch clarified:

scripts / trac-#325 / AUTH: mitchb  2013-06-27 04:00:50  (Microsoft: How do you want to crash today?) / BYTE-ME.MIT.EDU
   But yeah, mortals (including our null instances) being unable to
   bypass the hooks and silently commit stuff was the point.

Preventing the servers or maintainers (with their root instances) from bypassing the hooks is out-of-scope (and probably very difficult).

Note: See TracTickets for help on using tickets.