>--- Forwarded mail from [EMAIL PROTECTED] >Ones Self <[EMAIL PROTECTED]> wrote:
>> I'm running a CVS server which compiles and tests the current >> files in CVS every hour. I would like to make new checkins >> available _only_ if they compile and pass the tests. >> So, if a user checks in something which does not compile, for >> example, other users who check out at that time will not get >> the new version until the problem is fixed. Everytime you >> do an update, you know you're getting a clean version of the >> source; one that compiles, and in which the tests pass. >I don't think you can do that. Well, you could trigger a full >recompile from commitinfo and allow the commit only if the build >succeeds, but your commits would be a bit sluggish that way. >What you *could* do is trigger the build from loginfo (post-commit) >and update a moving tag if the build is successful. That way >your trunk can contain garbage, but the last successfully built >commit will have an unambiguous marker on it. Your users can >choose the unstable tip, > cvs checkout foo >or the last known good version, > cvs checkout -rLAST_GOOD foo >but in the latter case they won't be able to commit changes. >(Well, they could start a branch, but that's taking us off-topic.) >The loginfo trigger would be asynchronous, as in >https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC175 >and there would be negligible delay to a commit. >Simple question: why can't the developers do a top-level "make test" >before committing, and sidestep the question ? Or do the unit tests >take that long to run ? If the latter, you'll have to guard your >build-test-retag script against multiple instances of itself. Seems like the triggers and build procedures could conspire to enforce a policy that developers complete successful builds, too. The build procedure could have a target that lists its products, one of which be a summary report. The trigger could audit the summary and make sure that the targets are all newer than the sources and fail if anything was done out of order. >--- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
