This plugin allows use of GIT as a build SCM. Git 1.3.3 or newer is required.
* You may need to tell git who the user hudson is running as. In the latest versions of the plugin you can specify the user the project specific configuration for the git plugin. Alternatively on older Hudson installs on a Linux/Unix system edit the user's entry in /etc/passwd to set their login shell to /bin/bash instead of /bin/false. Then switch to that user which is probably tomcat6. Do this by using either of the following.
Now cd to the directory where the clone hudson created is and use git config user.name and git config user.email to set the values.
When you are done, log off as the hudson user and change the login shell back to /bin/false
[Version 2.2.5 or higher]
To minimize the delay between a push and a build, it is recommended to set up the post-receive hook in the repository to poke Hudson when a new commit is made. To do this, add the following line in your hooks/post-receive where "URL of the Git repository" is the fully URL you use to clone this repository.curl http://yourserver/hudson/git/notifyCommit?url=<URL of the Git repository>[&branches=branch1[,branch2]*]
This will scan all the jobs that's configured to check out the specified URL, the optional branches, and if they are also configured with polling, it'll immediately trigger the polling (and if that finds a change worth a build, a build will be triggered in turn). The polling is required to be configured on the job so that jobs that are supposed to be kicked from changes in the source tree are triggered.
This allows a script to remain the same when jobs come and go inHudson . Or if you have multiple repositories under a single repository host application (such as Gitosis), you can share a single post-receive hook script with all the repositories. Finally, this URL doesn't require authentication even for secured Hudson, because the server doesn't directly use anything that the client is sending. It runs polling to verify that there is a change, before it actually starts a build.
When successful, this will return the list of projects that it triggered polling as a response.
Continuous Integration tools such as Hudson are useful on projects as they give users early indication that a particular codebase is 'unstable' - and that if a developer checks it out, there will be trouble ahead (they won't be able to work on their own code, because someone else has broken something).
Unfortunately, by the time the build completes, this is often too late (particularly if the build cycle time is very long), as a developer has updated their working copy to the latest, unstable code in the repository and has begun work.
This can lead to the code base remaining unstable as developers tread on each others toes steadily fixing one thing, but breaking something else.
Some environments (e.g. TeamCity) attempt to fix this by making commits into SVN only 'really' happen once they have been tested. These kinds of 'delayed-commits' are problematic, because local SCM tools assume that commits will be immediately available, which can confuse them. In many ways this mechanism is a hack to get around the fact that branch management in SVN is very heavyweight.
Fortunately, with GIT and Hudson, you can achieve the same 'stable branches' with minimal effort.
Set up your hudson project, and leave the 'branch' field in the Git SCM blank. This will cause Hudson to consider any change on any branch for building.
Next, pick a particular branch name as the integration target in the 'Advanced' section - (e.g. 'master', or 'stable'), and select 'Merge before build'.
Select 'Push GIT tags back to origin repository' from the post-build actions (this is required to update your centralised git repo with the results of the build).
Now, developers should never commit directly to your integration branch (the 'master' or 'stable'). Instead, they should either use feature branches, or create new remote branches on commit (e.g : "git push origin HEAD:refs/heads/myNewFeature"). You could also set up your GIT repository to only accept commits onto the integration branch from Hudson.
You're done. Commits should now be automatically merged with the integration branch (they will fail if they do not merge cleanly), and built. If the build succeeds, the result of the merge will be pushed back to the remote git repository.
Since GIT is a Distributed SCM, it is possible in the Advanced section to specify multiple repositories. You may wish to do this to, for example, pull all in-progress work from individual developers machines, and pre-test them before they are committed to a centralised repository - this way developers may get an early warning that a branch in progress may not be stable.
The GIT plugin will make reasonable attempts to try and pull submodule states from distributed repositories, with the proviso that this feature is not currently well supported within GIT itself.
A common development pattern for many users is the use of a 'superproject' that aggregates a number of submodules. For example, ProjectA may have ComponentA, ComponentB and ComponentC. ComponentA is a shared library, and is set to use a particular revision (maybe on a branch called 'ProjectA' in case there are any changes). Usually, any changes to the project configuration require a commit to the ProjectA superproject.
However - there could be other changes happening on other branches of ComponentA (say to the development of the next version). Without someone generating commits into ProjectA to test these, any regressions or incompatibilities may be missed.
The autogenerate submodule configurations feature will create commits into ProjectA for all possible combinations of the branches present in the submodules that the project uses.
Add "Poll slaves" option (default on). If checked, the git repository on the last build slave is compared to the current state, and environment variables are obtained from the slave. If unchecked, the last build slave is never accessed and the git repository in the workspace on master is compared to the current state.
Use unsecured action introduced in Hudson 3.2.0 for SCM Hook. If unsecured actions enabled in Hudson, this allows git post-receive hooks to sent a postCommit request to Hudson without authentication. So far, this is the only unsecured action implemented.
Fix an NPE when scanning excluded commits.
Ensure git delegate is closed before replacing
Administrative fumble. A 2.2.9 was released with unknown contents not checked in to repo. Later, a second 2.2.9 was released (should be same as 2.2.10). To eliminate confusion - Hudson would not report new version available - 2.2.10 was released.
Upgrade to jgit 188.8.131.52403241930-r
Lower jacoco coverage to 0.28.
Ensure that the clean() call also cleans directories - as per the docs.