I have a job that I want to run every time a commit is made to a repository. I want to avoid pulling this code down, I only want the notification build trigger. So, is there either a way to not pull down certain repositories in your SCM upon a build or a way to poll things that aren't in the SCM for a build?
+1
A:
you could use a post commit hook to trigger your hudson job.
Matthew J Morrison
2010-08-12 01:25:03
There is no way that Hudson checks an SCM for updates and then doesn't pull the sources.
Peter Schuetze
2010-08-12 12:26:01
@Peter - not true, a Hudson Job can run any shell command and doesn't need to do anything with source code at all. You can trigger any Hudson job from a post commit hook.
Matthew J Morrison
2010-08-12 12:36:05
That would involve altering the SVN commit hooks, an intrusive operation I would like to avoid while still developing our CI server.
dhackner
2010-08-12 17:48:07
@Matthew: The question specifically ask about Hudson detecting the change by itself (without another app tipping it on the should, like a post commit does.) So check a repository and then don't poll the sources is not an option at all. So, no way that _Hudson_ checks the SVN but does not pull the sources. So I fully support your way off implementing it.
Peter Schuetze
2010-08-13 16:27:20
A:
Since you want to avoid changing SVN, you have to write a job that gets executed every so often (may be every 5 Minutes). This jobs runs a svn command using windows bach or shell script task to get the current revision for the branch in question. You can set the status of the job to unstable if there is a change. Don't use failure because you can't distinguish than between a real failure and a repository change. I think there is a plugin that sets the job status depending on the contents of you output.
You can then use the email extension plugin to send an email every time the revision changes. You can get the revision number from the last (or better the last successful or unstable) job. You can archive a file containing the revision number on the jobs or you can set the description for the job to the revision using the description setter plugin. Have a look at Hudsons remote API for ideas on how to get the information from the previous job.
Since you run your job very often during the day. don't forget to delete old job runs. But I would keep at least two days worth of history, just in case your svn is down for 24 hours.
Peter Schuetze
2010-08-13 16:42:55