问题
We are using jenkins for continuous integration using a standard poll every 10 minute scheme, and it work fine.
Now I want to set up a job that is run on every revision in the repro, it will be generating something that is more or less a binary patch that corresponds to a specific commit.
The only way I have figured out is by using a post-commit hook on the svnserver that queue a job on the jenkins server, but I'd rather not do that since it would demand a new hole in the firewall (and I think that jenkins collapses all queued jobs into one).
回答1:
I haven't tried this myself, but you may be able to use another build to trigger your subversions builds.
For example you could setup a build that does standard polling every 10 minutes from your subversion repository. Then have this build determine all the new revision numbers that have happened since the last time. Then have it queue multiple parameterized build (one for each revision).
There are a variety of ways to do this, but if I was doing it I would probably have the master build use a python build step to compute all the revisions and then I would use the parameterized trigger plugin to queue the secondary builds.
This last step could be a bit messy because I don't know of any plugin that allows you to queue up multiple builds. It is brute force, but you could set a series of build variables (SVN_REV_1, SVN_REV_2, ...) and then setup several triggers (one for each of the potential variables). As long as you have more of them then you ever have come through as new revisions, you should be good. (note: there may be a better way to do this)
To help make sure you don't miss any of them, I would suggest increasing your polling to run every minute. We do something similar here for one of our builds and the load of polling more often has never been an issue.
来源：https://stackoverflow.com/questions/8310979/how-do-i-get-jenkins-to-build-every-revision-of-a-subversion-repository