Pre-Commit validation for git master branch

[josh.k...@gmail.com]

We currently use Jenkins for our nightly build server but are evaluating a move towards Go because of the VSM and other niceties.  One really nice thing that Jenkins gives us is the pre-commit validation.  Specifically, there is a Gerrit plugin that works with Git so that when we commit to the master branch, there is an intermediate stage where we are able to run a pre-commit practice build and smoke test and vote on the build quality before submitting to master.  This is a really valuable way of keeping the build stable.

I assumed this was a solved problem so I just deferred the investigation.  Now, after scanning this google group and other resources I've come up empty.  Is anyone else doing this?  I can't imagine you would have a reliable CI process without it.  How do you do it?

[srinivas upadhya]

On Wednesday, October 22, 2014 6:46:08 AM UTC+5:30, josh.k...@gmail.com wrote:

We currently use Jenkins for our nightly build server but are evaluating a move towards Go because of the VSM and other niceties.

Awesome! Welcome :)

 

 One really nice thing that Jenkins gives us is the pre-commit validation.  Specifically, there is a Gerrit plugin that works with Git so that when we commit to the master branch, there is an intermediate stage where we are able to run a pre-commit practice build and smoke test and vote on the build quality before submitting to master.  This is a really valuable way of keeping the build stable.

I assumed this was a solved problem so I just deferred the investigation.  Now, after scanning this google group and other resources I've come up empty.  Is anyone else doing this?  I can't imagine you would have a reliable CI process without it.  How do you do it?

Here are some threads talking about support for feature branch if thats what you are looking for.

https://groups.google.com/forum/#!searchin/go-cd/branch/go-cd/phB6GBR2J6Y/X9gRwt6_AaAJ

https://groups.google.com/forum/#!searchin/go-cd-dev/branch/go-cd-dev/e0dbLDUsMK8/7TGHPaGkm7wJ

What we currently do is maintain "personal" pipelines - 1 per committer all of which are built off of a template that is same as master so there is no pipeline maintenance as such. We run our fork on that pipeline & make sure our Pull Request is "green" before merging to master (screenshots attached). We are seeing how we can make this available to others.

[Fredrik Wendt]

The tool is not what adds quality to the code - quality is added by humans writing code.

As such, you don't need pre-commit stages in order to keep quality high - simply make sure the individuals working together on the software have proper interactions (test and review = Gerrit) among them.

Some teams are better at this than other, so you mileage may vary. The point is: quality doesn't come from tools, but from humans. (First statement of the Agile Manifesto.)

You can setup Jenkins+Gerrit in front of Go.

You can of course setup a similar thing in Go. (Automated build+test step, Manual code review in some tool - both these must pass before next step executes: push code to another git repo (which would become new material picked up by Go)).

/ Fredrik 

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[josh.k...@gmail.com]

Thanks, Srinivas.

Actually, this doesn't quite answer my question.  Let me explain the workflow a little bit more that I am proposing:

1) Developer is working on a project.  We encourage submitting early and often so they submit something that is incomplete.

2) It turns out that it was a little too early and they introduced a build break.

3) As part of the pre-commit validation* Go runs a practice build.

4) The build fails and the code is never actually committed anywhere that could reach someone else.

It sounds like you're able to solve this since you're working on github and every developer repo is publicly accessible over http.  We have private repos and the dev branches only live on the dev machines.  Installing the Go Agent on every dev box and giving the Go Server access to scan for every commit isn't an option.

* Currently, we use Gerrit and Jenkins and there is a Jenkins plugins that does this and it works fine.  The Jenkins job watches the Gerrit code-review engine and when a new patch is submitted, it kicks off the build and test run.  Pending the results, Jenkins upvotes or downvotes the change appropriately.

[Charles Bryant]

I have never used Gerrit, but I would assume it has a command line interface. Maybe you can leverage Gerrit's command line to achieve the same thing that the Jenkins plug-in gives you. You would just need a GoCD pipeline before your build pipeline that executes the Gerrit command line to accomplish the same tasks as the Jenkins plug-in. I maybe over simplifying it, but so far I have found that you can do a lot of the same things found in plug-ins in other systems, just by using the command line on Go.

[srinivas upadhya]

Updates on #298 should be interesting to you. Gerrit builds are supported by build plugin. Im working on Gerrit support for notification plugin & I might need some help there. Let me know if you can find time for that. Thanks in advance.