Add a basic push log for recording repository push events
ClosedPublic
Actions

Authored by epriestley on Dec 5 2013, 1:29 AM.

Details

Reviewers

btrahan

Maniphest Tasks

T4195: Implement pre-commit Herald rules

Commits

Summary

Ref T4195. This log serves two purposes:

It's a log, so you can see what happened. Particularly, in Git/Hg, there is no other way to tell:
- Who pushed a change (vs committed / authored)?
- When was a change pushed?
- What was the old value of some tag/branch before someone destroyed it?
We can hand these objects off to Herald to implement pre-commit rules.

This is a very basic implementation, but gets some data written and has a basic UI for it.

Test Plan

{F87339}

Lint

Lint Skipped

Unit

Tests Skipped

resources/sql/patches/20131204.pushlog.sql
12–13	This is a new thing, but we have a couple of issues now where repositories can have non-utf8 paths and data and we don't deal with it very well. I'm testing the waters of storing separate "raw value" and "value encoding" fields. If this approach works well, we can use it for paths/diffs eventually (e.g., see T4045).
src/applications/diffusion/engine/DiffusionCommitHookEngine.php
86–87	This just lets us tell which ref changes showed up at the same time -- they'll all have the same transaction key.
94–95	Need to add more ENV stuff to get these populated.

btrahan added inline comments.

src/applications/repository/storage/PhabricatorRepositoryPushLog.php
32	this will be what an arbitrary, user-added commit hook would use for its reject code?

src/applications/repository/storage/PhabricatorRepositoryPushLog.php
32	Yeah. The idea is that we can use `rejectDetails` to store a Herald Rule PHID for herald rejects, and the name of the script/hook which rejected the push for external things. We could capture more stuff, but this seems like a reasonable balance of concerns for now.