Richard Bucker

Triggering hey Bill when a source code repository file changes is less than ideal

Posted at — Oct 10, 2013

Fossil source code manager is a very promising tool however it does not provide hooks that could be used to trigger a build upon commit. One possible solution is to watch the file system and look for updates to the file in both size and/or time. The challenge however is when the file is under load by multiple users or multiple commitments. The filesystem is going to trigger the watch process on the first change plus or minus whatever time interval is configured. As a result the second update might not actually get performed as part of the current build depending on the interleave between the trigger and the actual cloning of the original repository. Additionally if the actual commit taking place by the third and fourth parties is a number or series of commands that could adversely affect the build process as well.Other strategies like waiting for the files to settle after having determined that there was a change is plausible however the delay from the time of the trigger to the actual execution of build might also affect the effectiveness as additional changes are committed to the repository.The only way to ensure they clean improper build with continuous integration and deployment is with the implementation of commit hooks both pre-and post in the repository. If not the build process will have to be triggered manually prior to going into any sort of continuous integration workflow or something that looks like that.