If the tests are reasonable, consider a 'pre-push' git hook. We started doing that for gems/gmml, and it works pretty well. But, it has to be a *minimal* set of tests or folks will defeat it.
How it works for us:
The make script (could be config, etc.) detects whether you are in a git repo. If so, it copies certain scripts to the .git/hooks directory. After that, a person can commit all they want, and others can pull from them. But, if they want to push, they can't do it unless the tests pass.
Of course, this doesn't deal with all the different compilers/OS's/etc. But, it at least makes sure things aren't broken for that developer before the commit.
Our pre-push tests also force a build before the tests are run.
:-) Lachele
Dr. B. Lachele Foley
Associate Research Scientist
Complex Carbohydrate Research Center
The University of Georgia
Athens, GA USA
lfoley.uga.edu
http://glycam.org
________________________________
From: Hai Nguyen <nhai.qn.gmail.com>
Sent: Wednesday, September 6, 2017 9:12 AM
To: AMBER Developers Mailing List; david.case.rutgers.edu
Subject: Re: [AMBER-Developers] Looking for another volunteer--make a "fast" test suite?
Per broken commit: I think the typical workflow is: if the commit broke the
test case or broke the build, we should revert the commit immediately and
let the author fix that in different branch and then merge back to master
if all are ok. It's really hard to fix things after a tons of commit. So
hopefully no one feels upset if your commit was reverted.
.Dave: per download time: i will check, and would be great if that work.
That makes running full test suit in just 30 minutes.
Hai
On Wed, Sep 6, 2017 at 9:01 AM David A Case <david.case.rutgers.edu> wrote:
> Hi everyone:
>
> It's clear that people are generally not running tests before making
> commits to master. Part of that is bad habits, but a big part is probably
> that it takes forever to run the full test suite.
>
> So, I'm looking for a volunteer to create a "fast/short" test suite: i.e.
> a target in $AMBERHOME/test/Makefile that would cover the basics and could
> complete in a few minutes. Some discretion is needed, but such a thing
> would clearly skip the mmpbsa/FEW tests, only do a few of the hundreds
> of qmmm tests, etc. This could skip problematic tests as well, so the
> expectation would be that everything in the "fast/short" suite would PASS.
>
> Then we could really lean on people who make commits to master that break
> things, and automated nightly tests could (often) use just the shorter
> version.
>
> I don't think it is really necessary to do this for pmemd, since those
> tests run reasonably quickly as is. But I'm open to counterarguments
> there.
>
> Post a note on amber-developers if you decide to take this on, so we don't
> get
> duplicate efforts.
>
> ...thx...dac
>
> p.s.: my last request for help worked great: Lachele was able to bring
> the wiki up to current php standards, and to demonstrate that the code
> worked on her machine. That enabled me to push our admins to find the
> problem at ambermd.org, which turned out to be a glitch in the way remote
> storage was configured. (Before that, our admins just said "there must
> be something wrong with your code.")
>
> So kudo's to Lachele. Let me know if you see things wrong with
> ambermd.org.
> Hai: you might see if download times have improved.
> Jamie: we don't have a fix yet for the font/color change you requested.
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Sep 06 2017 - 06:30:05 PDT
