Force colourful Ansible output in github example workflow (#183)

.github-deploy-prod.yml.sample

@@ -1,15 +1,15 @@
 # This example workflow can be used to perform manually-triggered Azimuth deployments targeting production environments.
 # The workflow requires a GitHub environment (https://docs.github.com/en/actions/using-jobs/using-environments-for-jobs) to
-# be created in the site-specific config repo with a name which exactly matches the azimuth-config environment to be used 
-# for production deployments. For security, this GitHub environment should also have a deployment protection rule which 
-# restricts the environment workflows to only run on the main/default branch. This ensures that production deployments 
+# be created in the site-specific config repo with a name which exactly matches the azimuth-config environment to be used
+# for production deployments. For security, this GitHub environment should also have a deployment protection rule which
+# restricts the environment workflows to only run on the main/default branch. This ensures that production deployments
 # cannot be executed from arbitrary branches which could contain incorrect or unreviewed configuration.
 #
-# A manually-triggered workflow is used here since GitHub does not allow deployment approval rules for environments in 
+# A manually-triggered workflow is used here since GitHub does not allow deployment approval rules for environments in
 # private GitHub repos without a GitHub Enterprise subscription. If the site-specific config repo is public, or if an enterprise
-# subscription is available, then triggering the workflow on push to main with additional approval rules in the environment is 
+# subscription is available, then triggering the workflow on push to main with additional approval rules in the environment is
 # the recommended approach.
-# 
+#
 # The site-specific config repo must also define a repository secret named GIT_CRYPT_KEY_B64 which contains the base64 encoded
 # git-crypt key which was used to encrypt the repository's secrets. This can be obtained by running `git-crypt export-key - | base64`
 # from within an unlocked checkout of the repository. For information on defining GitHub repo secrets, see:
@@ -18,7 +18,7 @@
 name: Azimuth deployment
 on:
   workflow_dispatch:
-    inputs: 
+    inputs:
       environment:
         description: "The Azimuth config environment to deploy"
         type: environment
@@ -40,6 +40,8 @@ jobs:
 
       - name: Deploy Azimuth
         shell: bash
+        env:
+          ANSIBLE_FORCE_COLOR: True
         # Here we just decrypt the repo checkout then follow the steps from the Azimuth deployment docs.
         # The GitHub repo should have an environment configured with a name which matches the Azimuth config environment.
         # This GitHub environment should also have a branch protection rule which only allows deployments on chosen production branch (e.g. main).

.github-deploy-staging.yml.sample

@@ -1,7 +1,7 @@
 # This example workflow can be adapted to perform automated Azimuth deployments targeting staging or test environments.
 # The `azimuth-config-env-name` variable in the `env` section below should be set to name of the Azimuth config environment
 # to be deployed.
-# 
+#
 # The site-specific config repo must also define a repository secret named GIT_CRYPT_KEY_B64 which contains the base64 encoded
 # git-crypt key which was used to encrypt the repository's secrets. This can be obtained by running `git-crypt export-key - | base64`
 # from within an unlocked checkout of the repository. For information on defining GitHub repo secrets, see:
@@ -30,6 +30,8 @@ jobs:
 
       - name: Deploy Azimuth
         shell: bash
+        env:
+          ANSIBLE_FORCE_COLOR: True
         # Here we just decrypt the repo checkout then follow the steps from the Azimuth deployment docs.
         run: |
           set -e