Jenkins构建触发器内置的一共有四种方式，如图：

下面我们按照这四项逐个测试：

1、触发远程构建 (例如,使用脚本)

先看Jenkins的介绍：

Enable this option if you would like to trigger new builds by accessing a special predefined URL (convenient for scripts).
One typical example for this feature would be to trigger new build from the source control system’s hook script, when somebody has just committed a change into the repository, or from a script that parses your source control email notifications.
You’ll need to provide an authorization token in the form of a string so that only those who know it would be able to remotely trigger this project’s builds.

就是说，如果你想通过一个特殊的预定义的url来触发新的构建，你可以使用这个选项。
这个功能一个典型的应用场景是，当某人向一个源码管理系统的仓库提交并改变了源代码，源码管理系统的钩子脚本执行或者解析源码控制系统的邮件通知的脚本执行，从而触发新的构建。
您需要以字符串的形式提供授权令牌，以便只有那些知道它的人才能够远程触发这个项目的构建。

根据说明，我们选择并设置一个token，如图：

按照提示，我们可以通过JENKINS_URL/job/dev-job/build?token=TOKEN_NAME 或者 /buildWithParameters?token=TOKEN_NAME来触发构建，JENKINS_URL就是系统管理–>系统设置的jenkins URL，TOKEN_NAME就是我们填写的内容：
这里我们可以使用：

http://192.168.198.205:8080/jenkins/job/dev-job/build?token=88888888

此时构建历史如图：

这里简化操作，直接通过浏览器触发，浏览器中输入地址回车即可，然后查看构建历史，如图：

2、其他工程构建后触发

看介绍：

Set up a trigger so that when some other projects finish building, a new build is scheduled for this project. This is convenient for running an extensive test after a build is complete, for example.
This configuration complements the “Build other projects” section in the “Post-build Actions” of an upstream project, but is preferable when you want to configure the downstream project.

这里是说，设置一个触发器，当其他项目完成构建后，这个项目将进行一个新的构建。例如，这对于运行一个构建完成之后，运行一个充分的测试很方便。
此配置补充了上游项目的“构建后操作”中的“构建其他项目”部分，但在您要配置下游项目时更可取。

测试，新建一个项目dev-job-pre，内容如下：

dev-job触发器配置如下，多个项目可以用逗号分隔：

未构建dev-job-pre前，如图：

构建dev-job-pre后，如图：

分别查看控制台的输出，如图：

3、定时构建

看介绍：

Provides a cron-like feature to periodically execute this project.
This feature is primarily for using Jenkins as a cron replacement, and it is not ideal for continuously building software projects. When people first start continuous integration, they are often so used to the idea of regularly scheduled builds like nightly/weekly that they use this feature. However, the point of continuous integration is to start a build as soon as a change is made, to provide a quick feedback to the change. To do that you need to hook up SCM change notification to Jenkins.
So, before using this feature, stop and ask yourself if this is really what you want.

这个是说，提供类似cron的功能以定期执行此项目。
此功能主要用于将Jenkins用作cron替换，并且它不是持续构建软件项目的理想选择。 当人们第一次开始持续集成时，他们常常习惯于定期安排的构建，例如每晚/每周使用此功能。 但是，持续集成的目的是在更改后立即开始构建，以便为更改提供快速反馈。 为此，您需要将SCM中的更改通知Jenkins。
因此，在使用此功能之前，请停下来问自己这是否真的是您想要的。

测试，日程表的配置请点击右侧的问号，里面有详细的解释，表达式一个5个fields，分别代表
MINUTE HOUR DOM MONTH DOW
这里配置一个

* 13 * * *

代表每天的13点的每一分钟都执行一次，现在是13:53分，然后几分钟后查看构建历史情况，可以看到每分钟都会执行构建一次：

4、轮询 SCM

看介绍：

Configure Jenkins to poll changes in SCM.
Note that this is going to be an expensive operation for CVS, as every polling requires Jenkins to scan the entire workspace and verify it with the server. Consider setting up a “push” trigger to avoid this overhead, as described in this document

这里是说，配置Jenkins以轮询SCM中的更改。
注意，这对于CVS来说将是一项昂贵的操作，因为每次轮询都需要Jenkins扫描整个工作区并使用服务器进行验证。 此时应该考虑设置“推送”触发器以避免此开销，这里一般使用触发远程构建来实现。

测试，这里测试需要安装git,svn插件，从一个SCM中检出源码，并做修改后push才会生效，这里只是演示这个功能，所以从另一个已经安装好相关插件的Jenkins中做测试，

同样这里我们设置一个

代表每天的14点的每隔5分钟都执行一次，现在是14:17分，我们修改项目，并push：


如上图，14:17之后，14:18分，和14:23分各运行了一次，但是修改并push代码是14:18后做的事，所以只在 14:23轮询时，发现代码改变，故进行了构建。

好了，Jenkins内置的四种构建触发器介绍并测试完毕。