This plugin allows use of GIT as a build SCM. Git 1.3.3 or newer is required.

Plugin Information

Download latest version 0.7.3

Bugs

• Check the open issues carefully to see if the issue has already been reported
• Create an issue if needed, and make sure to choose the git sub-component.  Make sure to mention the plugin version number in the issue description.

Note for contributors: Please read SVN_USERS_PLEASE_READ_MEproperly before checking out the sources.  Those instructions are useful if you wish to use Git to contribute and request Nigel Magnay to pull your changes.

Gotchas

• If you are seeing output indicating Git could not clone, something like the output below, go to to the Hudson configuration settings (not the project settings, the global ones) and change the Git path to a fully qualified path (eg. not "git" but "/usr/bin/git" or wherever your Git binary is installed). You should also verify that the permissions are correct if you are doing a file system based clone.

Started by user anonymous
Checkout:workspace / C:\Documents and Settings\Administrator\.hudson\jobs\watir\workspace - hudson.remoting.LocalChannel@1a1f370
Last Build : #4
Checkout:workspace / C:\Documents and Settings\Administrator\.hudson\jobs\watir\workspace - hudson.remoting.LocalChannel@1a1f370
Cloning the remote Git repository
Cloning repository origin
$ git clone -o origin git://github.com/bret/watir.git "C:\Documents and Settings\Administrator\.hudson\jobs\watir\workspace"
Trying next repository
ERROR: Could not clone from a repository
FATAL: Could not clone
hudson.plugins.git.GitException: Could not clone
    at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:400)
    at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:358)
    at hudson.FilePath.act(FilePath.java:676)
    at hudson.FilePath.act(FilePath.java:660)
    at hudson.plugins.git.GitSCM.checkout(GitSCM.java:358)
    at hudson.model.AbstractProject.checkout(AbstractProject.java:833)
    at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:314)
    at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:266)
    at hudson.model.Run.run(Run.java:948)
    at hudson.model.Build.run(Build.java:112)
    at hudson.model.ResourceController.execute(ResourceController.java:93)
    at hudson.model.Executor.run(Executor.java:118)

• You man need to tell git who the user hudson is running as is. To do this 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.

  $ su tomcat6
  $ sudo su tomcat6
  

  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.

  $ cd /srv/hudson/jobs/project/workspace
  $ git config user.email "some@email.com"
  $ git config user.name "hudson"
  

  When you are done, log off as the hudson user and change the login shell back to /bin/false

Changelog

Version 0.7.3

FIXME this changelog entry is incomplete! Please give me some love!

• [FIXED HUDSON-2931] git tag freezing job execution (jbq)
• Improve log messages (jbq)
• Use build listener to report messages when pushing tags to origin (jbq)
• [FIXED HUDSON-2762] Fail to clone a repository on Windows (jbq)

Version 0.5

• Fix git plugin which was very broken when running on a remote server (magnayn)
• Fix NPE in GitChangeLogParser upon project's first build (jbq)
• Change workspace to a FilePath in GitAPI (jbq)
• Use git rev-list once instead of invoking git rev-parse indefinitely to find last build, see Issue 2469: GIT plugin very slow (jbq)
• Handle null-value of the repositories field to ensure backwards-compatibility with version 0.3,
  ie when the project configuration is missing the <repositories/> XML element (jbq)
• Improve error handling in revParse() (jbq)
• Fix handling of the "branch" configuration parameter (jbq)
• Improve tag handling, use show-ref instead of rev-parse to resolve the tag reference (jbq)
• Fix Issue 2675: Git fails on remote slaves (jbq)

Version 0.4 (never released)

• Allow multiple GIT repositories to be specified (magnayn)
• Allow submodule configurations to be generated on the fly (magnayn)
• Avoid infinite loops when git doesn't contains tags (david_calavera)
• Don't do a log of the entire branch if it's never been built (magnayn)

 Version 0.3

• Add support for pre-build branch merges

 Version 0.2

• Improve handling of git repositories (use local tags to identify up to date versions rather than the wc HEAD)
• Don't have to specify a branch, in which case all branches are examined for changes and built
• Includes a publisher which can be used to push build success/failure tags back up to the upstream repository

 Version 0.1

• Initial Release

Advanced Features

Using Git, Hudson and pre-build branch merging

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.

Using Extra Repositories

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.

Autogenerate submodule configurations

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.