LEFT | RIGHT |
(no file at all) | |
| 1 # Mercurial hooks |
| 2 |
| 3 `sitescripts/hg` contains Mercurial hooks for integration with other components |
| 4 of our infrastructure. |
| 5 |
| 6 ## IRC integration |
| 7 |
| 8 `irchook.py` contains a commit hook that posts the information about new pushed |
| 9 commits to an IRC channel. |
| 10 |
| 11 ## Trac integration |
| 12 |
| 13 `update_issues.py` contains two hooks: `changegroup_hook` and `pushkey_hook`. |
| 14 They will recognise issue references in commit messages and update referenced |
| 15 issues in the Adblock Plus issue tracker. |
| 16 |
| 17 The format of the commit messages is "ISSUE-REFERENCE - MESSAGE" |
| 18 where ISSUE-REFERENCE is one of "Noissue", "Issue NUMBER" or "Fixes NUMBER". |
| 19 Several "Issue" and "Fixes" references separated by commas can be present |
| 20 in the same commit message (for example: "Issue 1, Fixes 2 - Two issues"). |
| 21 Such commit will affect all the referenced issues. |
| 22 |
| 23 * `changegroup_hook` will post a comment with the link to the commit into the |
| 24 issue if the issue is referenced from the commit message. |
| 25 * `pushkey_hook` will close the issues and assign milestones to them (based |
| 26 on their module) when the `master` bookmark passes over the commits that fix |
| 27 them. It will not assign a milestone if the issue already has one. |
| 28 |
| 29 ### Configuring the repository |
| 30 |
| 31 `changegroup_hook` should be installed as `changegroup` or |
| 32 `pretxnchangegroup` hook. `pushkey_hook` should be installed as |
| 33 `pushkey` or `prepushkey` hook. For example (in `.hg/hgrc`): |
| 34 |
| 35 [hooks] |
| 36 pretxnchangegroup = python:.../update_issues.py:changegroup_hook |
| 37 pushkey = python:.../update_issues.py:pushkey_hook |
| 38 |
| 39 ### Configuring the hooks |
| 40 |
| 41 The hooks are configured via `sitescripts.ini` in `hg` and |
| 42 `hg_module_milestones` sections. For example: |
| 43 |
| 44 [hg] |
| 45 trac_xmlrpc_url=https://abpbot:abpbot@issues.adblockplus.org/login/xmlrpc |
| 46 issue_url_template=https://issues.adblockplus.org/ticket/{id} |
| 47 |
| 48 [hg_module_milestones] |
| 49 platform=adblock-plus(-[\d\.]+)?-for-chrome-opera-safari(-next)? |
| 50 Adblock-Plus-for-Firefox=adblock-plus(-[\d\.]+)?-for-firefox(-next)? |
| 51 |
| 52 `hg.track_xmlrpc_url` key from is used to determine the address of XMLRPC |
| 53 interface of Trac and `hg.issue_url_template` as a template for producing links |
| 54 to the referenced issues that are displayed in the log. |
| 55 |
| 56 The keys of the `hg_module_milestones` section are module names and the values |
| 57 are corresponding milestone regular expressions (they are matched |
| 58 case-insensitively). The first open milestone that matches the regular |
| 59 expression of the issue's module will be assigned to the issue when the |
| 60 `master` bookmark passes a commit that fixes it. |
| 61 |
| 62 ### Master bookmark |
| 63 |
| 64 What exactly does it mean when we say _`master` bookmark is passing a commit_? |
| 65 The idea is that if the `master` bookmark _passed_ a commit we will have |
| 66 those changes in our working copy when we do `hg checkout master`. |
| 67 |
| 68 Let's first look at a simple case, linear commit history like this: |
| 69 |
| 70 one <- two <- three |
| 71 |
| 72 Here `one` is a parent commit of `two` and `two` is a parent of `three`. If |
| 73 the `master` bookmark was on `one` and then moved to `three`, we say that it |
| 74 passed `two` and `three`. This would happen naturally if we clone the |
| 75 repository that contains `one` with the `master` bookmark pointing to it, |
| 76 check out `master`, author two commits and then push them. |
| 77 |
| 78 A somewhat similar thing happens when we have branches: |
| 79 |
| 80 one <---- two <---- three |
| 81 \ / |
| 82 \-- dos <--/ |
| 83 |
| 84 Here `one` is a parent commit of `two` and `dos` and they are both parents |
| 85 of `three`. If the `master` bookmark was on `two` and now is on `three`, |
| 86 we say that it passed `three` and `dos`. What happened here is that by `three` |
| 87 we've merged a branch containing `dos` into the master branch that was going |
| 88 through `one` and `two`. |
LEFT | RIGHT |