fix some typos and add docker imagetools inspect commands for supply chain

Signed-off-by: Laurent Broudoux <laurent.broudoux@gmail.com>

Author: lbroudoux

content/blog/testcontainers-modules-0.3.md

@@ -8,37 +8,38 @@ description: "Announcing Testcontainers Modules 0.3"
 draft: false
 ---
 
-To start the 2025 Year fresh, we're delighted to announce the release of the new series of our [Testcontainers](https://www.testcontainers.com) Modules 🧊!
-[Microcks modules](https://testcontainers.com/modules/microcks) are language-specific libraries that enable embedding Microcks into your unit tests with lightweight,
-throwaway instances thanks to containers.
+To start the 2025 Year fresh, we're delighted to announce the release of the new series of our [Testcontainers](https://www.testcontainers.com) 
+Modules 🧊! [Microcks modules](https://testcontainers.com/modules/microcks) are language-specific libraries that enable embedding Microcks into 
+your unit tests with lightweight, throwaway instances thanks to containers.
 
 The `0.3` series is a major step forward that completes the set of features and elevates Microcks as **a fully featured mocking library for development purposes**. 
-It can be used with different testing styles (classicist, mockist, state-based, and interaction-based) and provides features for all major languages and all kinds of API!
+It can be used with different testing styles (classicist, mockist, state-based, and interaction-based) and provides features for all major 
+languages and all kinds of API!
 
 {{< image src="images/blog/testcontainers-modules-0.3-feature.png" alt="image" zoomable="true" >}}
 <div align="center" style="padding-bottom: 40px"><legend><small><i>Photo by Alexandre Boucey on Unsplash</i></small></legend></div>
 
 The `0.3` versions are coincident releases made last week on the three main languages we currently support: [Java ☕️](https://github.com/microcks/microcks-testcontainers-java), 
 [NodeJS/Typescript](https://github.com/microcks/microcks-testcontainers-node) and [Golang](https://github.com/microcks/microcks-testcontainers-go). 
-With those new releases, we now have complete feature parity among the three different technology stacks! We plan to add the same features to the upcoming 
-[.NET module](https://github.com/microcks/microcks-testcontainers-dotnet) that we added to our portfolio in December 2024.
+With those new releases, we now have complete feature parity among the three different technology stacks! We plan to add the same features to 
+the upcoming [.NET module](https://github.com/microcks/microcks-testcontainers-dotnet) that we added to our portfolio in December 2024.
 
 Let's introduce the new features of those releases that complete the picture!
 
 ## What's inside?
 
 #### 1️⃣ Interaction checks
 
-If you spend some time reading about unit Test Driven Development, you may know that it exists two main school of thoughts: the *Classicist* and the *Mockist*.
+If you spend some time reading about Test Driven Development, you may know that it exists two main school of thought: the *Classicist* and the *Mockist*.
 (more on this in [this excellent article](https://medium.com/@adrianbooth/test-driven-development-wars-detroit-vs-london-classicist-vs-mockist-9956c78ae95f))
 
 Until now, Microcks Testcontainers integration was *Classicist* in the sense that it was focused on providing canned responses when the mocks
 endpoints were called. With this `0.3` release, we now also have a *Mockist* approach in the case you want to check the interactions of your
 component under test with a dependant API.
 
-You can now call `verify()` or `getServiceInvocationsCount()` on a Microcks container to check an API dependency has actually been called - or not.
-This is a super powerful way to ensure that your application logic (when to interact with an API) and access policies (caching, no caching, etc.) are correctly
-implemented and use the mock endpoints only when required!
+You can now call `verify()` or `getServiceInvocationsCount()` on a Microcks container to check whether an API dependency has actually been 
+called - or not. This is a super powerful way to ensure that your application logic (when to interact with an API) and access policies (caching, 
+no caching, etc.) are correctly implemented and use the mock endpoints only when required!
 
 {{< image src="images/blog/testcontainers-modules-0.3-interaction.png" alt="image" zoomable="true" >}}
 
@@ -48,17 +49,17 @@ A big shout out to [pierrechirstinimsa](https://github.com/pierrechristinimsa) 
 #### 2️⃣ Access to `messages` in synchronous API contract-testing
 
 The second thing we added in this release is the ability to retrieve exchanged messages when doing contract-testing. Different 
-[contract-testing runners](https://microcks.io/documentation/references/test-endpoints/#test-runner) already exists in Microcks but they're mainly focused on
-**syntactical conformance** checking. However, we know that there are [multiple levels of contract testing](https://medium.com/@lbroudoux/different-levels-of-api-contract-testing-with-microcks-ccc0847f8c97).
+[contract-testing runners](https://microcks.io/documentation/references/test-endpoints/#test-runner) already exists in Microcks but they're 
+mainly focused on **syntactical conformance** checking. However, we know that there are [multiple levels of contract testing](https://medium.com/@lbroudoux/different-levels-of-api-contract-testing-with-microcks-ccc0847f8c97).
 
-The new `getMessagesForTestCase()` function on Microcks container allows you to retrieve the requests and responses that were used during an operation tests case.
-You can then use them to perform extra checks more related to **business conformance**; validating, for example, that data retrieval or transformation logic is 
-correctly implemented.
+The new `getMessagesForTestCase()` function on Microcks container allows you to retrieve the requests and responses that were used during an 
+operation tests case. You can then use them to perform extra checks more related to **business conformance**; validating, for example, that 
+data retrieval or transformation logic is  correctly implemented.
 
 {{< image src="images/blog/testcontainers-modules-0.3-messages.png" alt="image" zoomable="true" >}}
 
 These extra checks can be done *manually* directly in the programming language of your tests but you can also delegate them
-to frameworks like [Cucumber](https://cucumber.io/) for running acceptance tests, written in plain language by business experts!
+to frameworks like [Cucumber](https://cucumber.io/) which are written in plain language by business experts; for running acceptance tests!
 
 
 #### 3️⃣ Access to `events` in asynchronous EDA contract-testing
@@ -84,18 +85,17 @@ events were not sent at the right time, introducing de-synchronization and colli
 ## Enthusiastic?
 
 We hope this walkthrough has made you enthusiastic about this new set of features in Microcks Testcontainers `0.3`! The best thing is that you don't have
-to wait another Microcks release to test them out as thy're are leveraging APIs and features that are present for a long time in Microcks core!
+to wait another Microcks release to test them out as they're are leveraging APIs and features that are present for a long time in Microcks core!
 
 If you want to learn them and see them in action, we have completed our demonstration application and tutorials on Testcontainers Modules as well!
 You just have to check the following links:
 
-* **For Java ☕️:** [How to check the mock endpoints are actually used?](https://github.com/microcks/microcks-testcontainers-java-spring-demo/blob/main/step-4-write-rest-tests.md#-bonus-step---check-the-mock-endpoints-are-actually-used), [How to verify the business conformance of a synchronous API](https://github.com/microcks/microcks-testcontainers-java-spring-demo/blob/main/step-4-write-rest-tests.md#-bonus-step---verify-the-business-conformance-of-order-service-api-in-pure-java), and [How to verify the event content for an asynchronous API](https://github.com/microcks/microcks-testcontainers-java-spring-demo/blob/main/step-5-write-async-tests.md#-bonus-step---verify-the-event-content)
+* **For Java ☕️:** [How to check the mock endpoints are actually used](https://github.com/microcks/microcks-testcontainers-java-spring-demo/blob/main/step-4-write-rest-tests.md#-bonus-step---check-the-mock-endpoints-are-actually-used), [How to verify the business conformance of a synchronous API](https://github.com/microcks/microcks-testcontainers-java-spring-demo/blob/main/step-4-write-rest-tests.md#-bonus-step---verify-the-business-conformance-of-order-service-api-in-pure-java), and [How to verify the event content for an asynchronous API](https://github.com/microcks/microcks-testcontainers-java-spring-demo/blob/main/step-5-write-async-tests.md#-bonus-step---verify-the-event-content)
 
 * **For NodeJS/TypeScript:** [How to check the mock endpoints are actually used](https://github.com/microcks/microcks-testcontainers-node-nest-demo/blob/main/step-4-write-rest-tests.md#-bonus-step---check-the-mock-endpoints-are-actually-used), [How to verify the business conformance of a synchronous API](https://github.com/microcks/microcks-testcontainers-node-nest-demo/blob/main/step-4-write-rest-tests.md#-bonus-step---verify-the-business-conformance-of-order-service-api-in-pure-java), and [How to verify the event content for an asynchronous API](https://github.com/microcks/microcks-testcontainers-node-nest-demo/blob/main/step-5-write-async-tests.md#-bonus-step---verify-the-event-content)
 
 * **For Golang:** [How to check the mock endpoints are actually used](https://github.com/microcks/microcks-testcontainers-go-demo/blob/main/step-4-write-rest-tests.md#-bonus-step---check-the-mock-endpoints-are-actually-used), [How to verify the business conformance of a synchronous API](https://github.com/microcks/microcks-testcontainers-go-demo/blob/main/step-4-write-rest-tests.md#-bonus-step---verify-the-business-conformance-of-order-service-api-in-pure-java), and [How to verify the event content for an asynchronous API](https://github.com/microcks/microcks-testcontainers-go-demo/blob/main/step-5-write-async-tests.md#-bonus-step---verify-the-event-content)
 
-As usual, we’re eager for community feedback: come and discuss on our [Discord chat](https://microcks.io/discord-invite/) 🐙
+As usual, we’re eager for community feedback: come and discuss on our [Discord chat](https://microcks.io/discord-invite/) 👻
 
 Thanks for reading and supporting us!
-

content/documentation/references/container-images.md

@@ -3,7 +3,7 @@ draft: false
 title: "Container Images"
 date: 2024-05-13
 publishdate: 2024-05-13
-lastmod: 2024-12-06
+lastmod: 2025-01-13
 weight: 1
 ---
 
@@ -166,10 +166,17 @@ You can then extract the `logIndex` and connect to [Rekor](https://search.sigsto
 All our images are built with a [SLSA Provenance](https://slsa.dev/spec/v1.0/provenance#v02) attestation (currently in `v0.2`). This attestation is attached as a layer of a 
 metadata manifest of the main image index.
 
-As Microcks images are provided for `linux/amd64` and `linux/arm64` architectures, the 2 first manifests of an image index are reserved for these architectures. Then, starting 
-at index 2 come the metadata manifests from where you can extract attestations that are formatted as [in-toto predicates](https://github.com/in-toto/attestation/tree/v1.0/spec/predicates).
+You can quickly inspect the `Provenance` attestations value using the `imagestools inspect` tool from `docker`like this:
 
-For example: you can extract the Provenance of the `microcks:nightly` image using those commands - using [ORAS](https://oras.land/) utility:
+```sh
+docker buildx imagetools inspect quay.io/microcks/microcks:nightly --format "{{ json .Provenance }}"
+```
+
+If you need to get access to the raw [in-toto predicates](https://github.com/in-toto/attestation/tree/v1.0/spec/predicates), you can use a tool like [ORAS](https://oras.land/) utility.
+
+As Microcks images are provided for `linux/amd64` and `linux/arm64` architectures, the 2 first manifests of an image index are reserved for these architectures. Then, starting
+at index 2 come the metadata manifests from where you can extract in-toto attestations. For example: you can extract the Provenance of the `microcks:nightly` image using those
+commands:
 
 ```sh
 PROVENANCE_DIGEST=`docker manifest inspect --verbose quay.io/microcks/microcks:nightly | jq -r '.[2].OCIManifest.layers | map(select(.annotations."in-toto.io/predicate-type" == "https://slsa.dev/provenance/v0.2") | .digest)[0]'`
@@ -257,10 +264,17 @@ You can find in the attestation the GitHub source and revision, the base image u
 
 All our images are built with a [SPDX SBOM](https://spdx.dev/) attestation (currently in `v2.3`). This attestation is attached as a layer of a metadata manifest of the main image index.
 
-As Microcks images are provided for `linux/amd64` and `linux/arm64` architectures, the 2 first manifests of an image index are reserved for these architectures. Then, starting 
-at index 2 come the metadata manifests from where you can extract attestations that are formatted as [in-toto predicates](https://github.com/in-toto/attestation/tree/v1.0/spec/predicates).
+You can quickly inspect the `Provenance` attestations value using the `imagestools inspect` tool from `docker`like this:
+
+```sh
+docker buildx imagetools inspect quay.io/microcks/microcks-postman-runtime:nightly --format "{{ json .SBOM }}"
+```
+
+If you need to get access to the raw [in-toto predicates](https://github.com/in-toto/attestation/tree/v1.0/spec/predicates), you can use a tool like [ORAS](https://oras.land/) utility.
 
-For example: you can extract the SBOM of the `microcks-postman-runtime:nightly` image using those commands - using [ORAS](https://oras.land/) utility:
+As Microcks images are provided for `linux/amd64` and `linux/arm64` architectures, the 2 first manifests of an image index are reserved for these architectures. Then, starting
+at index 2 come the metadata manifests from where you can extract in-toto attestations. For example: you can extract the SBOM of the `microcks-postman-runtime:nightly` image 
+using those commands:
 
 ```sh
 SBOM_DIGEST=`docker manifest inspect --verbose quay.io/microcks/microcks-postman-runtime:nightly | jq -r '.[2].OCIManifest.layers | map(select(.annotations."in-toto.io/predicate-type" == "https://spdx.dev/Document") | .digest)[0]'`

hugo_stats.json

@@ -2,7 +2,6 @@
   "htmlElements": {
     "tags": [
       "a",
-      "base",
       "blockquote",
       "body",
       "br",
@@ -29,6 +28,7 @@
       "iframe",
       "img",
       "input",
+      "legend",
       "li",
       "link",
       "main",
@@ -368,6 +368,7 @@
       "1-import-content-via-upload",
       "1-import-tasks-in-your-cluster",
       "1-install-the-cli",
+      "1-interaction-checks",
       "1-java-support",
       "1-obtain-an-api-key",
       "1-preparation",
@@ -384,6 +385,7 @@
       "1-setup-schema-registry",
       "1-use-cases",
       "1-using-testcontainers",
+      "2-access-to-messages-in-synchronous-api-contract-testing",
       "2-authenticate-to-keycloak",
       "2-basic-operation-in-openapi",
       "2-create-a-snapshot",
@@ -414,6 +416,7 @@
       "2-use-rabbitmq-in-asyncapi",
       "2-use-tasks-in-a-pipeline",
       "2-using-docker-desktop-extension",
+      "3-access-to-events-in-asynchronous-eda-contract-testing",
       "3-adding-a-secret-to-an-import-job",
       "3-basic-operation-of-grpc-service",
       "3-basic-operation-of-soap-service",
@@ -883,6 +886,7 @@
       "whats-coming-next",
       "whats-coming-next-",
       "whats-in-the-box",
+      "whats-inside",
       "whats-next",
       "who-can-use-microcks-for",
       "why-do-we-need-you",