Making Code Changes and using webhooks

Background: Web Hooks

Most Git repository servers support the concept of web hooks — calling to an external source via HTTP(S) when a change in the code repository happens. OpenShift provides an API endpoint that supports receiving hooks from remote systems in order to trigger builds. By pointing the code repository’s hook at the OpenShift API, automated code/build/deploy pipelines can be achieved.

Getting the webhook URL

Go to BuildsBuildsConfiguration and there in the Triggers sectoin there is Github webhook URL copy the URL to be used for configuring the webhook at Github.

Setting up the webhook

Open the Github repository page and go to the Settings tab and then to Webhooks in the left menu. Click Add webhook and fill the form

  • Payload URL is the URL copied from OpenShift

  • Content type has to be application/json

  • Secret should be empty

  • Disable SSL verification as the cluster does not have valid SSL certificates

And click the Add webhook button.

Making a code change

Go back to the Code tab in the same repository and open the file. Click the pen icon in the top right corner to edit the file.

Go to the line 35 and change the displayName.

Scroll down to the bottom of the page and click Commit changes.

Validation on OpenShift

Once you have committed your changes, a Build should almost instantaneously be triggered in OpenShift. Look at the Builds page in the web console, or run the following command to verify:

$ oc get builds
NAME              TYPE      FROM          STATUS     STARTED             DURATION
nationalparks-1   Source    Git@6f581b3   Complete   About an hour ago   55s
nationalparks-2   Source    Git@6ee9a29   Running    21 seconds ago

Once the build and deploy has finished, verify your new Docker image was automatically deployed by viewing the application in your browser:

You should now see the new name you have set in the JSON string returned.

Exercise: Rollback

OpenShift allows you to move between different versions of an application without the need to rebuild each time. Every version (past builds) of the application exists as a Docker-formatted image in the OpenShift registry. Using the oc rollback and oc deploy commands you can move back- or forward between various versions of applications.

In order to perform a rollback, you need to know the name of the Deployment Config which has deployed the application:

$ oc get dc
mongodb         1          1         1         config,image(mongodb:3.2)
nationalparks   4          1         1         config,image(nationalparks:latest)
parksmap        2          1         1         config,image(parksmap:1.2.0)

Now run the following command to rollback the latest code change:

$ oc rollback nationalparks
#5 rolled back to nationalparks-3
Warning: the following images triggers were disabled: nationalparks:live
  You can re-enable them with: oc set triggers dc/nationalparks --auto

Once the deploy is complete, verify that the page header is reverted to the original header by viewing the application in your browser.

Automatic deployment of new images is disabled as part of the rollback to prevent unwanted deployments soon after the rollback is complete. To re-enable the automatic deployments run this: oc set triggers dc/nationalparks --auto

Exercise: Rollforward

ust like you performed a rollback, you can also perform a roll-forward using the same command. You’ll notice above that when you requested a roll*back*, it caused a new deployment (#3). In essence, we always move forwards in OpenShift, even if we are going "back".

So, if we want to return to the "new code" version, that is deployment #4.

$ oc rollback nationalparks-4
#6 rolled back to nationalparks-4
Warning: the following images triggers were disabled: nationalparks:latest
  You can re-enable them with: oc set triggers dc/nationalparks --auto

Cool! Once the roll"back" is complete, verify you again see "OpenShift National Parks".

results matching ""

    No results matching ""