On Thu, Jul 30, 2015 at 07:38:45PM +0300, Nikita Karetnikov wrote: > So I'm looking into Bake integration with Gitlab. Here's the rough > plan: > > 1. Setup web hooks as described here: > > https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/web_hooks/web_hooks.md > > 2. Parse that on the Bake side. > > 3. Give Bake push access to master.
Let's take a step back and start with the goals and purpose. Then we can be sure the plan fulfills them. Here's my proposal: Gitlab merge requests are a tool we use for code review. That will always be a manual process, by definition. The review team manually reads the code, interacts with the contributor, and ultimately accepts or rejects the patch. There are some mechanical steps to a good code review, however, and CI can perform those automatically. The purpose of doing these things automatically is to provide quick, automatic feedback to a contributor, as well as to save time and effort from the review team. The two primary mechanical tasks are (1) merging the patch with master, (2) compiling the merged code, (3) testing it, and (4) reporting on any errors in the first three steps. The goal for bake, then, is to automate these tasks. --- I think to satisfy these goals, we *don't* want bake pushing to master. That should be a manual step. What bake should do instead is report, by adding comments or tags to the merge request. > It'd be ideal if Bake could test merge requests, but there are > some challenges. There's only one object type for merge requests, > which can be in multiple states: open, updated, merged, closed. So > there doesn't seem to be a way to clearly indicate: "test this!" Whether bake does too many builds (e.g. for closed or merged requests) is not a dealbreaker, but obviously it would be nice to inspect the web hook payload and only run for open or updated requests. I take it there is no way to control bake's behavior? It sounds like that migt be necessary for both how Gitlab interact with bake, and how bake interacts with Gitlab. If it is not possible, I can think of a couple possible solutions: 1. Add hooks on bake's side! 2. Add a proxy between Gitlab and bake. 3. Others? > ... > Then, the workflow becomes: a user pushes to a feature branch on the > main repo, Bake takes that as "ready for merge" and tests; merges if > appropriate. Is it possible with Gitlab? 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. I'm happy that you're working on this, by the way. I think it would be a great addition to our workflow.
signature.asc
Description: Digital signature
_______________________________________________ Dev mailing list [email protected] https://lists.snowdrift.coop/mailman/listinfo/dev
