Add Trigger Support
Last updated
Was this helpful?
Last updated
Was this helpful?
A trigger is a mechanism in a software application that indicates the completion of a particular process and then initiates the next process.
A CI-CD pipeline is a set of tasks that are executed in a specific order, as we learned in previous chapters. Triggers play an important role in automating and enhancing the capabilities of these pipelines.
A pipeline trigger specifies when a pipeline should be run automatically. Many types of triggers available such as Jenkins jobs, webhooks, CRON jobs, and even other pipelines. When you add a trigger to your pipeline, it means the pipeline will run whenever the triggering event occurs. It is worth noting that whether or not you have set up a pipeline trigger, you can always run your pipeline manually.
Set up Jenkins as a continuous integration system in Spinnaker deployment
Create a pipeline.
Add a trigger In the Configuration stage of your new pipeline.
Select Jenkins from the Type menu as below.
Select a Jenkins master from the Master drop-down menu, and a job from the Job drop-down. These will automatically populate if Jenkins is set up correctly.
Add a property file, if desired. See the property files section of the Pipeline Expression Guide for more information about how to specify and use property files.
You can send a POST call to Spinnaker at a preconfigured endpoint to automate pipeline triggers. This can be used to trigger pipelines when a continuous integration job completes, either from the command line or from a third-party system. In the Pipeline's execution, the payload will be available, whether it's one you can write or one that's been provided to you.
Following steps show triggering pipeline in Spinnaker using webhook url.
Configured a new pipeline called webhook-test in the above screenshot.
In the configuration stage, scroll down to the Automated Triggers option and find the Add Trigger tab.
Click the Add Trigger tab to get various options to select from, to configure the trigger.
Select Webhook In the Type text box.
After selecting the Webhook below screen will appear.
You can provide the source according to their preference. Source determines the target URL required to trigger this pipeline, as well as how the payload can be transformed into artifacts. In our example we called the source as ‘demo’.
As soon as you declare the source as a demo, the link just below to the ‘Source’ tab changes from /gate/webhooks/webhook/<source> to /gate/webhooks/webhook/demo. Save the configuration.
Now go back to the PIPELINE screen and see the webhook-test pipeline with Trigger:enabled.
The screenshot below shows an example where the Source link is different.
The webhook configuration points out that you can hit.
The endpoint depends on how your Spinnaker endpoints are configured. if you’re running on a different endpoint, for example https://api.spinnaker-prod.net, that’ll be shown instead. This link you will get below ‘Source’ as mentioned earlier.
Keep track of that endpoint as $spinnaker-endpoint (depending on where Spinnaker is installed), save that pipeline, and then run a curl command from any terminal that you have available based on the environment to test the trigger.
When you run the curl command, you will see something similar to the screenshot above, and if the trigger is successful, you will see eventProcessed: true and enentId in our terminal. If you check the Spinnaker you will see the pipeline has started.
You can also pass a payload using webhook. You can also set a pipeline to trigger when it receives a certain payload. However, you can also secure this by assigning a key value pair in our Spinnaker, which is known as payload constraint hence to trigger the pipeline you must have the key in the incoming payload.
In ‘Automated Triggers’ where you have configured the webhook, just below ‘Source’ you will find the ‘Payload Constraints’ option. If you hover your cursor at the question mark symbol at the end of ‘Payload Constraints’ option, you will find the explanation for the use of payload constraint which we have mentioned below as well.
When provided, only a webhook with a payload containing at least the specified key/value pairs will be allowed to trigger this pipeline. For example, if you wanted to lock down the systems/users that can trigger this pipeline via this webhook, you could require the key "secret" and value "something-secret" as a constraint.
The constraint values are supplied as regex.
We have provided two keys in the boxes provided for keys and value in the boxes, again this is user specific and a user can provide the details based on their choice.
The keys and values are nothing but constraints.
Provided Key: linuxfoundationkey lfbing
Provided Value: linuxfoundationvalue l.*f
Below is a screenshot of the same, Please save your changes after adding the details.
curl from the terminal again, just like we did before to test the webhook and trigger the pipeline. Curl from the terminal is user-specific; we used Ubuntu as an example, but you can use a different environment.
However, keep in mind that in order to trigger the pipeline, you must pass the payload constraint this time.
Create a payload.json file with the following settings. This is again specific to our example.
This file has to be passed in the curl command. Previous curl command that we used.
The new curl command that we will use to pass the payload constraint.
****$spinnaker-endpoint: It will differ for different users depending on their Spinnaker configuration and where Spinnaker is installed. The Webhook trigger documentation explains how to get the endpoint.
Once you fire the above curl command you will get eventProcessed and eventId details to confirm the successful trigger. These details will not be returned if the payload has been configured incorrectly. Below is a screenshot of the same.
You can use Payload Constraints in the trigger to ensure that a webhook only fires when a specific payload arrives. The key must be found in the incoming payload, and the value must match using regex. For example, the constraints are foo = bar and bing = b.*p.
The following payload would be accepted.
But this payload would be rejected (pipeline would not trigger).
If your pipeline accepts parameters (for example, the desired stack to deploy to), you can make that clear by adding a pipeline parameter to the same configuration screen as the webhook trigger.
If you were to execute this pipeline manually, you would be prompted with the following message.
If instead you were to trigger this pipeline with a Webhook, you could supply each parameter a value inside a key/value map called parameters. Take the following payload for example.
If your pipeline requires artifacts (for example, a Kubernetes manifest file stored in GCS), you can make this explicit by defining an Expected Artifact and assigning it to the Webhook as shown below.
In order to run this pipeline, you need to supply the required artifact in your payload under a list of artifacts.
