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內建的四種構建觸發器介紹並測試完畢。