>One of the practices from Continuous Integration is that builds should be run locally before committing to the main repository. Recently I’ve been working with Hudson and git to setup a local continuous integration server. With git I have a complete version of the repository and can commit locally. With Hudson, I can setup a job that monitors the local repository for any new changes. This way when I either commit code to the local repository, or pull in code from remote repository, hudson can trigger a local build.
Why do this? So that I make sure that my code is known to work at that particular point in time outside of my particular workspace environment. Builds should be IDE agnostic. Not everybody uses the same ide (I hear the eclipse community gasp).
Here are the steps:
- Download a copy of the Hudson war file.
- Start hudson with the following command: java -jar hudson.war –httpPort=8081 (Note: I choose to start it on a unique part due to possible local server conflicts that can occur)
- Access the local running hudson instance by going to http://localhost:8081/
- Go to Manage Hudson
- On the Available Plugins page select the git plugin, and install it.
- Restart Hudson
By installing the git plugin you will be able to have Hudson monitor the git repositories that you want to build against. You can setup multiple jobs for hudson. The next steps assume that you have already have a git repository on your local development machine.
- Go to http://localhost:8081/
- If one does not exist, create a new Job.
- On the configuration screen fill in the necessary information on how you want the job to be created.
- For the Source Code Management options, select git.
- Add a git repository.
- For the URL you can use a file based path like: file:///home/dcarver/Work/somegitproject
- Configure the branch you want to build against: origin/replacemewithbranch
- In the build section of the configuration page, select Poll SCM.
- Set up an appropriate polling schedule to check for changes in your local git repository.
- Fill in the rest of the build configuration steps.
If you setup your Polling for every 45 minutes. Your local running hudson will check your local git repository for changes every 45 minutes, if there are new commits or you have pulled recently from a remote repository it will start a build.
You can setup your local hudson to notify you be email, or however you want, if the local build fails. This way you can be sure that the code you are working on is working with out having to remember to jump out and run a build after making some changes. Some builds can take a while so you may or may not want to run an entire build but only critical pieces.
A DVCS system like git allows for this new type of workflow, and with the ease of setup of Hudson, one can easily setup a job that just runs in the background. If you happen to have a spare local machine laying around doing nothing, you could set that up as your local CI server and let it build the system for you as well.
Being able to catch issues while they are still close to the code that you worked on is critical in helping improve the code, and reduce the number of bugs we introduce into the upstream repository. This method may not catch all the bugs, but it should help catch a number of them.
Note: I may update this particular entry from time to time.