Build and unit test on push?

I'm consid开发者_如何学编程ering having the central repository (Mercurial) run a pre-commit hook that validates the code that has come in, and if it results in a failed build or unit test, disallows the push.

One obvious downside for this is that the build takes a couple of minutes, and would leave the developer hanging until it was complete.

Has anyone done anything similar, or have any comments?

---

To me, this is an anti-pattern. Mercurial, a VERSION CONTROL SYSTEM, is to version your sources. It is not a build system, continuous integration system, unit testing suite or anything like that. You should delegate things like this to the appropriate tool and a pre-commit type hook is not the place. I would use the open source continuous integration suite called Jenkins (http://jenkins-ci.org/) and do the build/test/etc upon commit/push. You can configure Jenkins to do a plethora of things based on the build results.

---

Its called a gated check-in, or pretested-commit. Some CI systems allow it, some don't.

Here's a blog article about TFS doing such a thing: http://spandothers.wordpress.com/2010/06/08/tfs-2010-gated-check-ins/

IMHO, its a meh feature. Check-in, break the build, fix-it, and move-on. Breaking the build should not be that big of a deal.

---

The Mercurial book covers this case http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html . but here are a few notes:

• You need to use a pretxnchangegroup hook not a precommit hook since the users aren't committing to the central repo, they're just pushing to it.
• Make sure to only test the latest changeset in a push's changegroup so that people can fix their mistakes and retry the push
• the repo will be locked against all other pushes while the tests are running, which really ruins half the point of a DVCS

You're better off just having your continuous integration system watch the central repo, run a build whenever there are new changesets and sound the alarm when tests fail. People who pulled before the alarm sounded will be easily able to pull down the fixes from the embarassed coder who broke the build. http://www.youbrokethebuild.com/

---

I know it by the names of "gated check-in" or "staged check-in".

Big companies like Microsoft (where I used to work) and Sun (could not find the link) favor the added assurance and productivity of the testing systems ("build can't break, by design") over the productivity of developers ("check-in takes 1-2 hours"). People which worked only on small companies or small projects usually freak out by the idea, but you should do your own math.

I've seen two ways to implement it yourself (and am not aware of any product which do so):
* Client-side: replace the common check-in tool (CL, GUI) with your own which will commit the changes into a temporary branch (or will just put the diff file in some temporary location), then trigger the execution of some remote build agent which will take the changes and perform a fast build and basic testing (aka smote tests). When all is well, the changes are really checked-in.
* Server-side: set up your version control in such a way that people get code from a "stable" location but push changes into "work" location (one per developer, team, whatever). Then have a CI server triggered by check-ins into the work location and automatically push them into the "stable branch" upon success or revert them upon failure.

I don't advocate this approach, just see what fits your needs.