Re: Preventing Dirty Checkins
Pierre Asselin wrote: Hm, my language was ambiguous. What the loginfo would trigger is one script, running on the test machine, that updates the test sandbox, builds, runs the tests, and finally moves the tag if the tests pass. Trigging rebuilds for every commit is insane. I run a job for one project every 15 minutes that checks if there are any checkins since the previous build using cvs histor and also checks that non checkins happened during the last ten minutes. The ten minute check is there to lessen the risk that a build starts in the middle of a check-in, giving false negative status reports). Then the build process starts, tagging everything in the project with a unique tag, exporting from CVS using that tag and then it building the project. The compilation errors and a summary are sent via e-mail to all interested parties and an internal web is updates with a pass/fail flags and a link to the build directory for reference and retrieval of the results. It does waste disk space, but that's cheap. It is also easy to prune old directories. -- robin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
Robin Rosenberg [EMAIL PROTECTED]@dewire.kom wrote: Pierre Asselin wrote: Hm, my language was ambiguous. What the loginfo would trigger is one script, running on the test machine, that updates the test sandbox, builds, runs the tests, and finally moves the tag if the tests pass. Trigging rebuilds for every commit is insane. Well, the OP wanted to trigger a test build in the pre-commit check. I was proposing a less heavy-handed solution. Not that it's entirely free of gatchas. [ sane process elided ] -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
Maarten de Boer [EMAIL PROTECTED] wrote: What you *could* do is trigger the build from loginfo (post-commit) and update a moving tag if the build is successful. [ ... ] But why would you to that from the loginfo? Wouldn't it be easier to have that tag moved by a virtual user, the dedicated test build machine, which is building and testing in a loop, everytime the compilation is correct? Hm, my language was ambiguous. What the loginfo would trigger is one script, running on the test machine, that updates the test sandbox, builds, runs the tests, and finally moves the tag if the tests pass. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
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 why would you to that from the loginfo? Wouldn't it be easier to have that tag moved by a virtual user, the dedicated test build machine, which is building and testing in a loop, everytime the compilation is correct? Maarten ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Preventing Dirty Checkins
Todd Denniston wrote: you probably want to look into commitinfo in the Administrative files section of the manual [...] make your command (or script) build the software and if it fails return nonuser. Checkin's will take a long time if you force 'make clean world', In my case, a long time would be several hours ;=) One catch I can see with this approach is the platform. For example, our development platform is Windows using Microsoft Visual Studio, and our repository is on a Solaris machine. Despite all my writing about portable code (see URL in .sig) much of our code is extremely MSVC-centric. opinionThe better method would be to hire engineers who understand the process of making good checkins, and/or use a process that involves the engineer doing the check before committing and dock his/her pay for bad commits\opinion I agree - that is by far the better approach. In our shop, we rarely have broken builds. We have an automated build that runs once a day, and emails every member of the team the build results in summary form, with a link to the full build log. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Preventing Dirty Checkins
[EMAIL PROTECTED] wrote: Simple question: why can't the developers do a top-level make test before committing, and sidestep the question ? Sometimes ya just forget to 'cvs add' a file ;=) -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Preventing Dirty Checkins
[EMAIL PROTECTED] wrote: Yet another method is to divorce the notion of latest checked in from eligible for build. I personally would never discourage anyone from checking in their work, I actively encourage frequent checkins. If you have something that will (or might) break the build, then create a private, temporary branch and check it in there. The important thing is that your work is safe in the repository; I've had a few too many hard drive crashes to leave it to chance. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
One catch I can see with this approach is the platform. For example, our development platform is Windows using Microsoft Visual Studio, and our repository is on a Solaris machine. So, the testing machine could be Windows with Visual, which could compile, test, and move the compiles-correctly tag. Maarten ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Preventing Dirty Checkins
Maarten de Boer wrote: One catch I can see with this approach is the platform. For example, our development platform is Windows using Microsoft Visual Studio, and our repository is on a Solaris machine. So, the testing machine could be Windows with Visual, which could compile, test, and move the compiles-correctly tag. But that's a different approach from what was suggested. The suggested approach was a commitinfo script. Commitinfo runs *only* on the server. I'm not saying the suggested approach was the best, or even workable. I'm just pointing out a potential problem with the suggestion. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
But that's a different approach from what was suggested. The suggested approach was a commitinfo script. Commitinfo runs *only* on the server. I'm not saying the suggested approach was the best, or even workable. I'm just pointing out a potential problem with the suggestion. Yes, yes, I know, I suggested the different approach (a dedicated test machine) in a previous mail, and saw this as another argument in favor. I should have been more clear. Maarten ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Preventing Dirty Checkins
--- Forwarded mail from [EMAIL PROTECTED] Maarten de Boer wrote: One catch I can see with this approach is the platform. For example, our development platform is Windows using Microsoft Visual Studio, and our repository is on a Solaris machine. So, the testing machine could be Windows with Visual, which could compile, test, and move the compiles-correctly tag. But that's a different approach from what was suggested. The suggested approach was a commitinfo script. Commitinfo runs *only* on the server. I'm not saying the suggested approach was the best, or even workable. I'm just pointing out a potential problem with the suggestion. Another is what to do if your shop compiles on more than one platform. How do you test that the compile is successful everywhere? About the third time you do this, you start thinking that scheduled builds combined with good change control and a promotion system look pretty good. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
[ On , September 28, 2004 at 12:06:18 (-0700), Ones Self wrote: ] Subject: Preventing Dirty Checkins 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. You don't want to use CVS then. You need and want to use a tool called Aegis, or else something very much like it. I.e. you need to use a version tracking system that inherently supports the concept of a two-phase commit. Aegis acutally does the regression tests on every commit (or at least it does this by default), as well as (optionally) implementing a manual second approval commit (so in a sense Aegis is a three-phase system). Furthermore new changes cannot be committed unless a new test is also provided to make sure the changes are not broken ever again (unless they are explicitly undone). -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
Ones Self wrote: Hi, 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. you probably want to look into commitinfo in the Administrative files section of the manual Administrative files https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC158 The commit support files https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC167 commitinfo https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC169 instead of preventing checkouts, it prevents check in If the command (or script) returns a non-zero exit status the commit will be aborted. make your command (or script) build the software and if it fails return nonuser. Checkin's will take a long time if you force 'make clean world', but you can choose the implementation level that is right for you. This way only acceptable things make it in the base line. opinionThe better method would be to hire engineers who understand the process of making good checkins, and/or use a process that involves the engineer doing the check before committing and dock his/her pay for bad commits\opinion, but you may implement what ever mechanisms make you or your boss happy. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
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. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
--- Forwarded mail from [EMAIL PROTECTED] Ones Self wrote: Hi, 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. make your command (or script) build the software and if it fails return nonuser. Checkin's will take a long time if you force 'make clean world', but you can choose the implementation level that is right for you. This way only acceptable things make it in the base line. opinionThe better method would be to hire engineers who understand the process of making good checkins, and/or use a process that involves the engineer doing the check before committing and dock his/her pay for bad commits\opinion, but you may implement what ever mechanisms make you or your boss happy. Yet another method is to divorce the notion of latest checked in from eligible for build. I personally would never discourage anyone from checking in their work, and I found that providing a handoff method in which the user explicitly guarantees that the code will build is a useful tool. Collecting up the bits for inclusion (or exclusion) in the next build is a simple form of change control that also improves the quality of the builds overall because changes can be undone (sometimes automatically!) under error conditions. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
--- 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
