update

content/modules/ROOT/nav.adoc

@@ -8,7 +8,7 @@
 
 * xref:05-code-change.adoc[5. Code Change]
 
-* xref:06-pipeline-exploration.adoc[6. Pipeline Exploration]
+* xref:06-tekton-pipeline-exploration.adoc[6. Tekton Pipeline Exploration]
 
 * xref:07-release-promotion.adoc[7. Release & Promotion]
 
@@ -18,15 +18,15 @@
 
 * xref:10-signed-commits.adoc[10. Sign Commits via git-sign]
 
-* xref:11-AI-demo-setup.adoc[11. AI with LLMs Demo Setup]
+* xref:11-jenkins-pipeline-exploration.adoc[11. Jenkins Pipeline Exploration]
 
-* xref:12-AI-chatbot-flow.adoc[12. AI with LLMs Chatbot Flow]
+* xref:12-AI-demo-setup.adoc[12. AI with LLMs Demo Setup]
 
-* xref:13-AI-model-exploration.adoc[13. AI Model Exploration]
+* xref:13-AI-chatbot-flow.adoc[13. AI with LLMs Chatbot Flow]
 
-* xref:14-AI-bring-your-own-model.adoc[14. Bring your own model]
+* xref:14-AI-model-exploration.adoc[14. AI Model Exploration]
 
-* xref:15-jenkins-ci.adoc[15. Jenkins CI]
+* xref:15-AI-bring-your-own-model.adoc[15. Bring your own model]
 
 * xref:16-troubleshooting.adoc[16. Troubleshooting]
 

content/modules/ROOT/pages/06-pipeline-exploration.adoc → content/modules/ROOT/pages/06-tekton-pipeline-exploration.adoc

@@ -1,4 +1,4 @@
-== Pipeline Exploration
+== Tekton Pipeline Exploration
 
 As a developer, I can see all the steps involved with the corporate standard pipeline and *GREEN is good*.  As a developer, that makes me happy, I do not have worry about all the details.
 
@@ -8,21 +8,21 @@ Narrator: Now, for our architects and platform engineers in the room, you want t
 
 Developer Hub pre-integrates several curated plug-ins that are great for overall developer experience.  A lot has happened with the execution of this pipeline.
 
-The first step in the pipeline is a simple `git clone`.   The next step is basically a `mvn package` and then running of Sonarqube `scan-source` for static analysis.  All pretty standard for CI pipelines.  Get the code, compile/build the code, run some scans. 
+The first step in the pipeline is a simple `git clone`.   The next step is basically a `mvn package` and then running of Sonarqube `scan-source` for static analysis.  All pretty standard for CI pipelines.  Get the code, compile/build the code, run some scans.
 
 === Build Sign Image
 
-It is the `build-sign-image` where things get super interesting. 
+It is the `build-sign-image` where things get super interesting.
 
 image::pipeline-exploration-2.png[]
 
-The template is leveraging Tekton Chains, a Kubernetes Custom Resource Definition (CRD) controller, that nicely augments the supply chain security within OpenShift Pipelines. This tool's capacity to automatically sign task runs, and its adoption of advanced attestation formats like in-toto and SLA provenance, bring a higher degree of trust and verification to our processes.   Tekton Chains works like an independent observer within the cluster, it signs, attests and stores additional artifacts as OCI images alongside with your container image.   
+The template is leveraging Tekton Chains, a Kubernetes Custom Resource Definition (CRD) controller, that nicely augments the supply chain security within OpenShift Pipelines. This tool's capacity to automatically sign task runs, and its adoption of advanced attestation formats like in-toto and SLA provenance, bring a higher degree of trust and verification to our processes.   Tekton Chains works like an independent observer within the cluster, it signs, attests and stores additional artifacts as OCI images alongside with your container image.
 
 If you look on the *Image Registry* tab you will see there is are *.att*, *.sig* and *.sbom* sitting side-by-side with the resulting container image produced by the pipeline.
 
 image::pipeline-exploration-3.png[]
 
-This plug-in using Quay, you might remember we selected Quay in the template wizard. Quay offers yet another aspect of supply chain security, it is constantly scanning your container images at rest. Your developers might not be actively coding and if nobody has pushed a change recently then the pipeline might not have run in a while.  
+This plug-in using Quay, you might remember we selected Quay in the template wizard. Quay offers yet another aspect of supply chain security, it is constantly scanning your container images at rest. Your developers might not be actively coding and if nobody has pushed a change recently then the pipeline might not have run in a while.
 
 === roxctl (ACS)
 
@@ -31,11 +31,11 @@ Back to the pipeline itself and let's look at the 3 Advanced Cluster Security ta
 image::pipeline-exploration-4.png[]
 
 
-The bottom-most task is performing CVE scanning via `roxctl image scan`.  
+The bottom-most task is performing CVE scanning via `roxctl image scan`.
 
-The middle task is performing a policy check via `roxctl image check`.  These policies might be things like 'No log4j allowed' or perhaps no curl, wget nor a package manager in a production image.  
+The middle task is performing a policy check via `roxctl image check`.  These policies might be things like 'No log4j allowed' or perhaps no curl, wget nor a package manager in a production image.
 
-The top-most task is perform yaml scanning via `roxctl deployment check` and it might identify that your Deployment.yaml has not properly configured its resource request and limit. 
+The top-most task is perform yaml scanning via `roxctl deployment check` and it might identify that your Deployment.yaml has not properly configured its resource request and limit.
 
 A series of dashboards visualize the reporting from these 3 *roxctl* tasks, click on the *View Output* icon under *ACTIONS*
 
@@ -45,11 +45,11 @@ image::pipeline-exploration-4-2.png[]
 
 image::pipeline-exploration-4-3.png[]
 
-These ACS polices can be seen on the following screen, just look for *Build* policies under lifecycle.  
+These ACS polices can be seen on the following screen, just look for *Build* policies under lifecycle.
 
 image::pipeline-exploration-5.png[]
 
-These 3 aspects of *roxctl* are a great example of the "shift-left" idea by bringing these critical checks into the pipeline itself to be executed on each `git push`. 
+These 3 aspects of *roxctl* are a great example of the "shift-left" idea by bringing these critical checks into the pipeline itself to be executed on each `git push`.
 
 === scan-export-sbom
 
@@ -59,13 +59,13 @@ Pushes the SBOM to a CycloneDX repository.  Currently, the SBOM is stored in Qua
 
 image::pipeline-exploration-12.png[]
 
-The SBOM is an artifact that deserves special mention.  Think of the Software Bill of Materials as the ingredient list.  I am sure you have gone to the grocery store and picked up an item and reviewed its packaging.  On the back of the product there will be a list of ingredients.  You can find out that something you might wish to eat includes gluten, perhaps too much sugar, or shellfish (my sister is allergic to shellfish) or perhaps nuts.  Well, if you are allergic to nuts you might also be allergic to struts :-) You might remember that infamous Struts 2 vulnerability that allowed 143 million American's private data to end up on the dark web https://www.securityweek.com/apache-struts-flaw-reportedly-exploited-equifax-hack[Struts 2 hack].  
+The SBOM is an artifact that deserves special mention.  Think of the Software Bill of Materials as the ingredient list.  I am sure you have gone to the grocery store and picked up an item and reviewed its packaging.  On the back of the product there will be a list of ingredients.  You can find out that something you might wish to eat includes gluten, perhaps too much sugar, or shellfish (my sister is allergic to shellfish) or perhaps nuts.  Well, if you are allergic to nuts you might also be allergic to struts :-) You might remember that infamous Struts 2 vulnerability that allowed 143 million American's private data to end up on the dark web https://www.securityweek.com/apache-struts-flaw-reportedly-exploited-equifax-hack[Struts 2 hack].
 
-The SBOM is either a JSON or XML file and is stored in the container registry as the ingredient list associated with the container image.  
+The SBOM is either a JSON or XML file and is stored in the container registry as the ingredient list associated with the container image.
 
 === Dev Deployment
 
-Click on *Topology* 
+Click on *Topology*
 
 As a developer, I want to see my handy work, did my applicatio really deploy to the dev environment?
 

content/modules/ROOT/pages/15-jenkins-ci.adoc → content/modules/ROOT/pages/11-jenkins-pipeline-exploration.adoc

@@ -1,4 +1,4 @@
-== Jenkins CI
+== Jenkins Pipeline Exploration
 
 Jenkins is used to build and test your product continuously, so developers can continuously integrate changes into the build. Jenkins is the most popular open source CI/CD tool on the market today and is used in support of DevOps, alongside other cloud native tools.