From 42dbb32b2ec9ff46a8eb3cd54a1ed67c256e46ac Mon Sep 17 00:00:00 2001
From: Amit Burde <burdeamit@gmail.com>
Date: Thu, 1 Feb 2024 16:58:14 +0000
Subject: [PATCH 1/8] Added Docker Examples Inside The Documentations

---
 _includes/setup_command_line.md         | 16 +++++++
 documentation/backward_compatibility.md | 57 ++++++++++++++++++++++++-
 getting_started.md                      | 20 +++++++++
 3 files changed, 92 insertions(+), 1 deletion(-)

diff --git a/_includes/setup_command_line.md b/_includes/setup_command_line.md
index de4d43c19..fd91c56cd 100644
--- a/_includes/setup_command_line.md
+++ b/_includes/setup_command_line.md
@@ -23,6 +23,22 @@ Run specmatic by
 $ npx specmatic
 ```
 {% endtab %}
+
+{% tab install docker %}
+
+Docker Pull Command for specmatic docker image
+
+``` bash
+> docker pull znsio/specmatic
+> docker tag znsio/specmatic:latest specmatic
+```
+
+Run specmatic by
+
+``` bash
+> docker run specmatic
+```
+{% endtab %}
 {% endtabs %}
 
 ---
diff --git a/documentation/backward_compatibility.md b/documentation/backward_compatibility.md
index 1580f39a8..3a9f14120 100644
--- a/documentation/backward_compatibility.md
+++ b/documentation/backward_compatibility.md
@@ -150,11 +150,22 @@ The newer contract is backward compatible with the older, as existing consumers
 
 Run the specmatic compare command to confirm this, and see the result:
 
+{% tabs compare %}
+{% tab compare java %}
 ```bash
 > java -jar specmatic.jar compare api_products_v1.yaml api_products_v1-2.yaml
 
 The newer contract is backward compatible
 ```
+{% endtab %}
+{% tab compare docker %}
+```bash
+> docker run -v "/local-directory/api_products_v1.yaml:/api_products_v1.yaml" -v "/local-directory/api_products_v2.yaml:/api_products_v2.yaml" specmatic compare "/api_products_v1.yaml" "/api_products_v2.yaml" 
+
+The newer contract is backward compatible
+```
+{% endtab %}
+{% endtabs %}
 
 Let's change the original contract of square to return "sku" as a numeric value instead of string in the response:
 
@@ -202,6 +213,8 @@ Note that the file name of the above file is api_products_v2.yaml.
 
 Now try it again:
 
+{% tabs compare2 %}
+{% tab compare2 java %}
 ```bash
 > java -jar specmatic.jar compare api_math_v1.yaml api_math_v2.yaml
 
@@ -214,6 +227,22 @@ API: GET /products/(id:number) -> 200
 
 The newer contract is not backward compatible.
 ```
+{% endtab %}
+{% tab compare2 docker %}
+```bash
+> docker run -v "/local-directory/api_products_v1.yaml:/api_products_v1.yaml" -v "/local-directory/api_products_v2.yaml:/api_products_v2.yaml" specmatic compare "/api_products_v1.yaml" "/api_products_v2.yaml" 
+
+In scenario "Get Products. Response: Returns Product With Id"
+API: GET /products/(id:number) -> 200
+
+  >> RESPONSE.BODY.sku
+
+     This is number in the new contract response but string in the old contract
+
+The newer contract is not backward compatible.
+```
+{% endtab %}
+{% endtabs %}
 
 Specmatic will show you an error message, saying that the change is not backward compatible. The reason for this is that existing consumers are expecting a string "sku", but will get an "integer" instead.
 
@@ -225,9 +254,22 @@ If api_products_v1.yaml is in a git repository, and the change is backward compa
 
 Then to confirm that it is a backward compatible change, before committing the change, run this command:
 
+{% tabs git-compare %}
+{% tab git-compare java %}
 ```bash
-java -jar specmatic.jar compatible git file ./run/specmatic/examples/api_products_v1.yaml
+> java -jar specmatic.jar compatible git file ./run/specmatic/examples/api_products_v1.yaml
+
+The newer contract is backward compatible
+```
+{% endtab %}
+{% tab git-compare docker %}
+```bash
+> docker run -v "/git-repo:/git-repo" specmatic compatible git file "/git-repo/api_products_v1.yaml"
+
+The newer contract is backward compatible
 ```
+{% endtab %}
+{% endtabs %}
 
 This command exits with exit code 1 if the change is backward incompatible. It can be configured as a git pre-commit hook.
 
@@ -237,9 +279,22 @@ In CI, you will need to compare the changes in a contract from one commit to the
 
 You can do this with the following command:
 
+{% tabs ci-compare %}
+{% tab ci-compare java %}
 ```bash
 > java -jar specmatic.jar compatible git commits api_products_v1.yaml HEAD HEAD^1
+
+The newer contract is backward compatible
+```
+{% endtab %}
+{% tab ci-compare docker %}
+```bash
+> docker run -v "/git-repo:/git-repo" specmatic compatible git commits "/git-repo/api_products_v1.yaml" HEAD HEAD^1
+
+The newer contract is backward compatible
 ```
+{% endtab %}
+{% endtabs %}
 
 You can even use commit hashes here if you wish to compare any other pair of commits.
 
diff --git a/getting_started.md b/getting_started.md
index a06d38fe0..8e077af72 100644
--- a/getting_started.md
+++ b/getting_started.md
@@ -103,6 +103,11 @@ specmatic test service.yaml --testBaseURL=https://my-json-server.typicode.com/zn
 npx specmatic test service.yaml --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
 ```
 {% endtab %}
+{% tab test docker %}
+```shell
+ > docker run -v "/local-directory/service.yaml:/container-directory" specmatic test "/container-directory/service.yaml" --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
+```
+{% endtab %}
 {% endtabs %}
 
 This should print out a result that looks something like this.
@@ -177,6 +182,11 @@ specmatic test service.yaml --testBaseURL=https://my-json-server.typicode.com/zn
 npx specmatic test service.yaml --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
 ```
 {% endtab %}
+{% tab test2 docker %}
+```shell
+ > docker run -v "/local-directory/service.yaml:/container-directory" specmatic test "/container-directory/service.yaml" --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
+```
+{% endtab %}
 {% endtabs %}
 This time around the test fails because the response from our sample app is not in line with the OpenAPI Specification.
 ```shell
@@ -224,6 +234,11 @@ specmatic stub service.yaml
 npx specmatic stub service.yaml
 ```
 {% endtab %}
+{% tab stub docker %}
+```shell
+> docker run -v "/local-directory/service.yaml:/service.yaml" specmatic stub "/service.yaml"
+```
+{% endtab %}
 {% endtabs %}
 
 This should start your stub server on port 9000 by default (you can switch the port number by adding ```--port <port of your choice>``` to the above command) as below.
@@ -280,6 +295,11 @@ specmatic stub service.yaml
 npx specmatic stub service.yaml
 ```
 {% endtab %}
+{% tab stub2 docker %}
+```shell
+> docker run -v "/local-directory/service.yaml:/service.yaml" specmatic stub "/service.yaml"
+```
+{% endtab %}
 {% endtabs %}
 
 This time you should see Specmatic load your canned response file also.

From bba655635b5195f25e1c18579aaf2a39404756a9 Mon Sep 17 00:00:00 2001
From: Amit Burde <burdeamit@gmail.com>
Date: Thu, 1 Feb 2024 18:39:29 +0000
Subject: [PATCH 2/8] Updated Specmatic Test Snippet For Docker

---
 getting_started.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/getting_started.md b/getting_started.md
index 8e077af72..eb896a430 100644
--- a/getting_started.md
+++ b/getting_started.md
@@ -105,7 +105,7 @@ npx specmatic test service.yaml --testBaseURL=https://my-json-server.typicode.co
 {% endtab %}
 {% tab test docker %}
 ```shell
- > docker run -v "/local-directory/service.yaml:/container-directory" specmatic test "/container-directory/service.yaml" --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
+ > docker run -v "/local-directory/service.yaml:/service.yaml" specmatic test "/service.yaml" --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
 ```
 {% endtab %}
 {% endtabs %}
@@ -184,7 +184,7 @@ npx specmatic test service.yaml --testBaseURL=https://my-json-server.typicode.co
 {% endtab %}
 {% tab test2 docker %}
 ```shell
- > docker run -v "/local-directory/service.yaml:/container-directory" specmatic test "/container-directory/service.yaml" --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
+ > docker run -v "/local-directory/service.yaml:/service.yaml" specmatic test "/service.yaml" --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
 ```
 {% endtab %}
 {% endtabs %}

From f396ce90fa65109a7e9cefc964adf5cb354fa3b7 Mon Sep 17 00:00:00 2001
From: Hari Krishnan <harikrishnan83@gmail.com>
Date: Fri, 2 Feb 2024 05:26:08 +0000
Subject: [PATCH 3/8] removed docker image tag to have the full image name
 everywhere, removed leading > in docker commands

---
 _includes/setup_command_line.md         | 4 ++--
 documentation/backward_compatibility.md | 8 ++++----
 getting_started.md                      | 8 ++++----
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/_includes/setup_command_line.md b/_includes/setup_command_line.md
index fd91c56cd..c66711558 100644
--- a/_includes/setup_command_line.md
+++ b/_includes/setup_command_line.md
@@ -30,14 +30,14 @@ Docker Pull Command for specmatic docker image
 
 ``` bash
 > docker pull znsio/specmatic
-> docker tag znsio/specmatic:latest specmatic
 ```
 
 Run specmatic by
 
 ``` bash
-> docker run specmatic
+docker run znsio/specmatic
 ```
+
 {% endtab %}
 {% endtabs %}
 
diff --git a/documentation/backward_compatibility.md b/documentation/backward_compatibility.md
index 3a9f14120..73e63105c 100644
--- a/documentation/backward_compatibility.md
+++ b/documentation/backward_compatibility.md
@@ -160,7 +160,7 @@ The newer contract is backward compatible
 {% endtab %}
 {% tab compare docker %}
 ```bash
-> docker run -v "/local-directory/api_products_v1.yaml:/api_products_v1.yaml" -v "/local-directory/api_products_v2.yaml:/api_products_v2.yaml" specmatic compare "/api_products_v1.yaml" "/api_products_v2.yaml" 
+docker run -v "/local-directory/api_products_v1.yaml:/api_products_v1.yaml" -v "/local-directory/api_products_v2.yaml:/api_products_v2.yaml" znsio/specmatic compare "/api_products_v1.yaml" "/api_products_v2.yaml" 
 
 The newer contract is backward compatible
 ```
@@ -230,7 +230,7 @@ The newer contract is not backward compatible.
 {% endtab %}
 {% tab compare2 docker %}
 ```bash
-> docker run -v "/local-directory/api_products_v1.yaml:/api_products_v1.yaml" -v "/local-directory/api_products_v2.yaml:/api_products_v2.yaml" specmatic compare "/api_products_v1.yaml" "/api_products_v2.yaml" 
+docker run -v "/local-directory/api_products_v1.yaml:/api_products_v1.yaml" -v "/local-directory/api_products_v2.yaml:/api_products_v2.yaml" znsio/specmatic compare "/api_products_v1.yaml" "/api_products_v2.yaml" 
 
 In scenario "Get Products. Response: Returns Product With Id"
 API: GET /products/(id:number) -> 200
@@ -264,7 +264,7 @@ The newer contract is backward compatible
 {% endtab %}
 {% tab git-compare docker %}
 ```bash
-> docker run -v "/git-repo:/git-repo" specmatic compatible git file "/git-repo/api_products_v1.yaml"
+docker run -v "/git-repo:/git-repo" znsio/specmatic compatible git file "/git-repo/api_products_v1.yaml"
 
 The newer contract is backward compatible
 ```
@@ -289,7 +289,7 @@ The newer contract is backward compatible
 {% endtab %}
 {% tab ci-compare docker %}
 ```bash
-> docker run -v "/git-repo:/git-repo" specmatic compatible git commits "/git-repo/api_products_v1.yaml" HEAD HEAD^1
+docker run -v "/git-repo:/git-repo" znsio/specmatic compatible git commits "/git-repo/api_products_v1.yaml" HEAD HEAD^1
 
 The newer contract is backward compatible
 ```
diff --git a/getting_started.md b/getting_started.md
index eb896a430..8fff3f798 100644
--- a/getting_started.md
+++ b/getting_started.md
@@ -105,7 +105,7 @@ npx specmatic test service.yaml --testBaseURL=https://my-json-server.typicode.co
 {% endtab %}
 {% tab test docker %}
 ```shell
- > docker run -v "/local-directory/service.yaml:/service.yaml" specmatic test "/service.yaml" --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
+ docker run -v "/local-directory/service.yaml:/service.yaml" znsio/specmatic test "/service.yaml" --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
 ```
 {% endtab %}
 {% endtabs %}
@@ -184,7 +184,7 @@ npx specmatic test service.yaml --testBaseURL=https://my-json-server.typicode.co
 {% endtab %}
 {% tab test2 docker %}
 ```shell
- > docker run -v "/local-directory/service.yaml:/service.yaml" specmatic test "/service.yaml" --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
+ docker run -v "/local-directory/service.yaml:/service.yaml" znsio/specmatic test "/service.yaml" --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
 ```
 {% endtab %}
 {% endtabs %}
@@ -236,7 +236,7 @@ npx specmatic stub service.yaml
 {% endtab %}
 {% tab stub docker %}
 ```shell
-> docker run -v "/local-directory/service.yaml:/service.yaml" specmatic stub "/service.yaml"
+docker run -v "/local-directory/service.yaml:/service.yaml" znsio/specmatic stub "/service.yaml"
 ```
 {% endtab %}
 {% endtabs %}
@@ -297,7 +297,7 @@ npx specmatic stub service.yaml
 {% endtab %}
 {% tab stub2 docker %}
 ```shell
-> docker run -v "/local-directory/service.yaml:/service.yaml" specmatic stub "/service.yaml"
+docker run -v "/local-directory/service.yaml:/service.yaml" specmatic stub "/service.yaml"
 ```
 {% endtab %}
 {% endtabs %}

From 075b2476e40e13bec3d625c927770929906cea97 Mon Sep 17 00:00:00 2001
From: Hari Krishnan <harikrishnan83@gmail.com>
Date: Fri, 2 Feb 2024 05:48:19 +0000
Subject: [PATCH 4/8] fixing indentation in YAML snippet, added missing tabbed
 section for test command, fixing docker run specmatic stub command by adding
 port mapping

---
 getting_started.md | 42 ++++++++++++++++++++++++++++++++++++------
 1 file changed, 36 insertions(+), 6 deletions(-)

diff --git a/getting_started.md b/getting_started.md
index 8fff3f798..0b2c28285 100644
--- a/getting_started.md
+++ b/getting_started.md
@@ -137,23 +137,48 @@ Tests run: 1, Successes: 1, Failures: 0, Errors: 0
 
 How did Specmatic know to make the exact request to ```GET /znsio/specmatic-documentation/pets/1``` with petId as "1"? And not just any other number?
 
-If you notice the OpenAPI, we have an example section for PetId which sets up our petId as per the test data.
+In the OpenAPI spec you may have noticed that there is an examples section for petid.
 
 ```yaml
   - name: "petid"
     in: "path"
     required: true
     schema:
-    type: "number"
+      type: "number"
     examples:
-    200_OKAY:
+      200_OKAY:
         value: 1
 ```
 
-Try removing this example value and try running the specmatic test command again.
+Remove the examples section such that the `petid` param look as shown below.
+
+```yaml
+  - name: "petid"
+    in: "path"
+    required: true
+    schema:
+      type: "number"
+```
+
+And try running the specmatic test command again.
+
+{% tabs test3 %}
+{% tab test3 java %}
 ```shell
 specmatic test service.yaml --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
 ```
+{% endtab %}
+{% tab test3 npm %}
+```shell
+npx specmatic test service.yaml --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
+```
+{% endtab %}
+{% tab test3 docker %}
+```shell
+ docker run -v "/local-directory/service.yaml:/service.yaml" znsio/specmatic test "/service.yaml" --testBaseURL=https://my-json-server.typicode.com/znsio/specmatic-documentation
+```
+{% endtab %}
+{% endtabs %}
 
 Specmatic will generate a random petId based on the datatype of the petId path parameter which results in a 404 since test data does not exist.
 ```shell
@@ -236,7 +261,7 @@ npx specmatic stub service.yaml
 {% endtab %}
 {% tab stub docker %}
 ```shell
-docker run -v "/local-directory/service.yaml:/service.yaml" znsio/specmatic stub "/service.yaml"
+docker run -v "/local-directory/service.yaml:/service.yaml" -p 9000:9000 znsio/specmatic stub "/service.yaml"
 ```
 {% endtab %}
 {% endtabs %}
@@ -248,10 +273,15 @@ Loading service.yaml
 Stub server is running on http://0.0.0.0:9000. Ctrl + C to stop.
 ```
 
-Once the stub server is running you can verify the API by accessing it through Postman, Chrome, Curl etc. to see the response.
+Once the stub server is running you can verify the API by accessing it through Postman, Chrome, Curl etc.
 
 ```shell
 curl http://localhost:9000/pets/123
+```
+
+You should now be able to see the response that matches the schema defined in your OpenAPI spec.
+
+```shell
 {
     "id": 864,
     "name": "VRIQA",

From ef429edaf7c6c14d717eaab0ba835421fe9af868 Mon Sep 17 00:00:00 2001
From: Hari Krishnan <harikrishnan83@gmail.com>
Date: Fri, 2 Feb 2024 06:05:00 +0000
Subject: [PATCH 5/8] updated the docker commands related to service
 virtualisation and related documentation

---
 getting_started.md | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/getting_started.md b/getting_started.md
index 0b2c28285..26d763b48 100644
--- a/getting_started.md
+++ b/getting_started.md
@@ -291,8 +291,8 @@ You should now be able to see the response that matches the schema defined in yo
 ```
 
 The response contains auto-generated values that adhere to the data type defined in the contract. In above output petid "864" is generated by specmatic and will vary with every execution. If you would like to control the value that is being returned you can set up stub / canned responses.
-* Create a folder named service_data in the same folder as your service.yaml file (_data suffix is a naming convention that tell Specmatic to look for canned responses in that directory)
-* Create a json file with the name scooby.json and add below contents to it
+* Create a folder named `service_data` in the same folder as your `service.yaml` file (`_data` suffix is a naming convention that tell Specmatic to look for canned responses in that directory)
+* Create a json file with the name `scooby.json` and add below contents to it
 
 ```json
 {
@@ -327,7 +327,10 @@ npx specmatic stub service.yaml
 {% endtab %}
 {% tab stub2 docker %}
 ```shell
-docker run -v "/local-directory/service.yaml:/service.yaml" specmatic stub "/service.yaml"
+# Please note docker command here has to volume map the directory containing service.yaml 
+# to a directory within the container so that both service.yaml and folder service_data along 
+# with scooby.json are available to Specmatic docker container
+docker run -v "/local-directory/:/specs" -p 9000:9000 znsio/specmatic stub "/specs/service.yaml"
 ```
 {% endtab %}
 {% endtabs %}
@@ -344,6 +347,10 @@ Stub server is running on http://0.0.0.0:9000. Ctrl + C to stop.
 And let us now run the curl command.
 ```shell
 curl http://localhost:9000/pets/1
+```
+
+Specmatic will now return your canned response for petId 1. For any other petId it will continue to return generated values.
+```shell
 {
     "id": 1,
     "name": "Scooby",
@@ -352,11 +359,9 @@ curl http://localhost:9000/pets/1
 }
 ```
 
-Specmatic will now return your canned response for petId 1. For any other petId it will continue to return generated values.
-
 So what is so smart about Specmatic Smart Mocks.
 
-Let us try a few experiments. Remove the "status" field in scooby.json and run the stub command again. You should an output like below.
+Let us try a few experiments. Remove the `status` field within http-response body in `scooby.json` and run the stub command again. You should an output like below.
 ```shell
 Loading service.yaml
   Loading stub expectations from /<dir with service.yaml>/service_data

From 24f9c367abe70b00e8b29bfd0412b427eb255840 Mon Sep 17 00:00:00 2001
From: Hari Krishnan <harikrishnan83@gmail.com>
Date: Fri, 2 Feb 2024 06:22:53 +0000
Subject: [PATCH 6/8] updating the compatible command documentation for docker,
 fixing issues in java documentation

---
 documentation/backward_compatibility.md | 44 ++++++++++---------------
 1 file changed, 18 insertions(+), 26 deletions(-)

diff --git a/documentation/backward_compatibility.md b/documentation/backward_compatibility.md
index 73e63105c..b566e91d5 100644
--- a/documentation/backward_compatibility.md
+++ b/documentation/backward_compatibility.md
@@ -76,7 +76,7 @@ This contract contains an API for fetching the details of a product.
 Let's add a new api to create a product record:
 
 ```yaml
-# filename api_products_v1-2.yaml
+# filename api_products_v2.yaml
 openapi: 3.0.0
 info:
   title: Sample Product API
@@ -153,21 +153,22 @@ Run the specmatic compare command to confirm this, and see the result:
 {% tabs compare %}
 {% tab compare java %}
 ```bash
-> java -jar specmatic.jar compare api_products_v1.yaml api_products_v1-2.yaml
-
-The newer contract is backward compatible
+java -jar specmatic.jar compare api_products_v1.yaml api_products_v2.yaml
 ```
 {% endtab %}
 {% tab compare docker %}
 ```bash
-docker run -v "/local-directory/api_products_v1.yaml:/api_products_v1.yaml" -v "/local-directory/api_products_v2.yaml:/api_products_v2.yaml" znsio/specmatic compare "/api_products_v1.yaml" "/api_products_v2.yaml" 
-
-The newer contract is backward compatible
+docker run -v "/local-directory:/specs" znsio/specmatic compare "/specs/api_products_v1.yaml" "/specs/api_products_v2.yaml" 
 ```
 {% endtab %}
 {% endtabs %}
 
-Let's change the original contract of square to return "sku" as a numeric value instead of string in the response:
+You should now see an output as shown below.
+```bash
+The newer contract is backward compatible
+```
+
+Let's change the original contract of square to return `sku` as a num `integer` instead of `string` in the response:
 
 ```yaml
 # filename api_products_v2.yaml
@@ -205,33 +206,28 @@ paths:
                 properties:
                   name:
                     type: string
-                  sku:
+                  sku: #this has changed from string to integer
                     type: integer
 ```
 
-Note that the file name of the above file is api_products_v2.yaml.
-
 Now try it again:
 
 {% tabs compare2 %}
 {% tab compare2 java %}
 ```bash
-> java -jar specmatic.jar compare api_math_v1.yaml api_math_v2.yaml
-
-In scenario "Get Products. Response: Returns Product With Id"
-API: GET /products/(id:number) -> 200
-
-  >> RESPONSE.BODY.sku
-
-     This is number in the new contract response but string in the old contract
-
-The newer contract is not backward compatible.
+java -jar specmatic.jar compare api_products_v1.yaml api_products_v2.yaml
 ```
 {% endtab %}
 {% tab compare2 docker %}
 ```bash
-docker run -v "/local-directory/api_products_v1.yaml:/api_products_v1.yaml" -v "/local-directory/api_products_v2.yaml:/api_products_v2.yaml" znsio/specmatic compare "/api_products_v1.yaml" "/api_products_v2.yaml" 
+docker run -v "/local-directory:/specs" znsio/specmatic compare "/specs/api_products_v1.yaml" "/specs/api_products_v2.yaml" 
+```
+{% endtab %}
+{% endtabs %}
 
+Specmatic will show you an error message, saying that the change is not backward compatible. The reason for this is that existing consumers are expecting a string "sku", but will get an "integer" instead.
+
+```bash
 In scenario "Get Products. Response: Returns Product With Id"
 API: GET /products/(id:number) -> 200
 
@@ -241,10 +237,6 @@ API: GET /products/(id:number) -> 200
 
 The newer contract is not backward compatible.
 ```
-{% endtab %}
-{% endtabs %}
-
-Specmatic will show you an error message, saying that the change is not backward compatible. The reason for this is that existing consumers are expecting a string "sku", but will get an "integer" instead.
 
 If the change is not backward compatible, the compare command exits with exit code 1. You can use this in a script.
 

From 861f55fe9c9c633b0bda55427e143de9cfe11d44 Mon Sep 17 00:00:00 2001
From: Hari Krishnan <harikrishnan83@gmail.com>
Date: Fri, 2 Feb 2024 06:28:14 +0000
Subject: [PATCH 7/8] updating the compatible git file command docker
 documentation

---
 documentation/backward_compatibility.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/documentation/backward_compatibility.md b/documentation/backward_compatibility.md
index b566e91d5..f777f7aa9 100644
--- a/documentation/backward_compatibility.md
+++ b/documentation/backward_compatibility.md
@@ -242,29 +242,29 @@ If the change is not backward compatible, the compare command exits with exit co
 
 ## Validating Changes In Git On Your Laptop
 
-If api_products_v1.yaml is in a git repository, and the change is backward compatible, make the change directly to the v1 file instead of creating a new one.
+If `api_products_v1.yaml` is part of a git repository, changes can be made directly to this file instead of creating a new one.
 
 Then to confirm that it is a backward compatible change, before committing the change, run this command:
 
 {% tabs git-compare %}
 {% tab git-compare java %}
 ```bash
-> java -jar specmatic.jar compatible git file ./run/specmatic/examples/api_products_v1.yaml
-
-The newer contract is backward compatible
+java -jar specmatic.jar compatible git file ./run/specmatic/examples/api_products_v1.yaml
 ```
 {% endtab %}
 {% tab git-compare docker %}
 ```bash
 docker run -v "/git-repo:/git-repo" znsio/specmatic compatible git file "/git-repo/api_products_v1.yaml"
-
-The newer contract is backward compatible
 ```
 {% endtab %}
 {% endtabs %}
 
 This command exits with exit code 1 if the change is backward incompatible. It can be configured as a git pre-commit hook.
 
+```bash
+The newer contract is backward compatible
+```
+
 ## Validating Changes In CI
 
 In CI, you will need to compare the changes in a contract from one commit to the next.

From b51bcfd412184be5e62152ac81f7d14acb461d88 Mon Sep 17 00:00:00 2001
From: Hari Krishnan <harikrishnan83@gmail.com>
Date: Fri, 2 Feb 2024 06:33:43 +0000
Subject: [PATCH 8/8] updating compatible git commits documentation

---
 documentation/backward_compatibility.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/documentation/backward_compatibility.md b/documentation/backward_compatibility.md
index f777f7aa9..d169734f3 100644
--- a/documentation/backward_compatibility.md
+++ b/documentation/backward_compatibility.md
@@ -274,22 +274,22 @@ You can do this with the following command:
 {% tabs ci-compare %}
 {% tab ci-compare java %}
 ```bash
-> java -jar specmatic.jar compatible git commits api_products_v1.yaml HEAD HEAD^1
-
-The newer contract is backward compatible
+java -jar specmatic.jar compatible git commits api_products_v1.yaml HEAD HEAD^1
 ```
 {% endtab %}
 {% tab ci-compare docker %}
 ```bash
 docker run -v "/git-repo:/git-repo" znsio/specmatic compatible git commits "/git-repo/api_products_v1.yaml" HEAD HEAD^1
-
-The newer contract is backward compatible
 ```
 {% endtab %}
 {% endtabs %}
 
 You can even use commit hashes here if you wish to compare any other pair of commits.
 
+```bash
+The newer contract is backward compatible
+```
+
 This command exits with exit code 1 if the change is backward incompatible.
 
 ## Handling Contracts In Progress