$ 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
Making Code Changes and using webhooks
CI/CD -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
Configuration 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
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
wsgi.py 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:
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.
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 NAME REVISION DESIRED CURRENT TRIGGERED BY 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:
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".