I've got GitLab working (the same version that git.gnu.io uses) inside a VM, so now I can finally reply.
> Yes, that would be possible, but I think it would not meet the goal of > automating the mechanical aspects of a code review. I think we want to > test, then review, then merge, in that order. Okay, though, I think the other approach would be easier. Anyway, here is a more detailed workflow: 1. Someone opens a merge request. 2. The merge request hook sends json to Bake: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/web_hooks/web_hooks.md#merge-request-events (The URI can be provided in the GitLab UI.) The "state" attribute must be set to "opened" in this case. (The other ones are "reopened" and "closed".) 3. Bake uses the "object_attributes" fields to fetch the source branch. 4. Bake runs the tests. (Question: should Bake test after merging the source to target or not?) 5. Bake posts a report to a merge request using the API: http://doc.gitlab.com/ce/api/merge_requests.html#post-comment-to-mr It's not clear how to use web hooks to trigger Bake when someone pushes to a branch that's already associated with a merge request. Folks would definitely want to correct things (that's the point of having a review process after all). We could probably work around that by using the "comment on merge request" hook. Something like: "Bake it!" But I don't really like this solution since it's error-prone. I only know how to do it properly when people are allowed to push since there is a web hook for pushes. Ideas? _______________________________________________ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
