Pipeline default value fix

nexus-Six · nexus-Six · commit 9763946bb754 · 2022-06-29T17:07:39.000+02:00
diff --git a/content/13-rhacs-pipeline/_index.md b/content/13-rhacs-pipeline/_index.md
@@ -127,7 +127,7 @@ Remember how we edited the pipeline directly in yaml before? OpenShift comes wit
 {{% /notice %}}
 
 - Hover your mouse over **build** task and click the **+** at the right side side of it, to add a task
-- This will open a task selector where you can choose to add your **rox-image-check**
+- This will open a task selector where you can choose to your **rox-image-check** and double-click to add it to the pipeline
 - To add the required parameters from the pipeline for the task, click the **rox-image-check** task.
 - A form with the parameters will open, fill it in:
 
@@ -159,7 +159,6 @@ The last step is to enforce the System Policy. If the policy is violated the pip
 
 - Edit your custom **System Policy** in **ACS Portal** and set **Response Method** to **Inform and enforce** and then switch on **Build** and **Deploy** below.
 - Run the pipeline again, first with **Version** `java-old-image` and then with **Version** `openjdk-17-ubi8` (default)
-- When running the Pipeline with new parameters you need to enter `master` as **GIT_REVISION** !
 - Expected results:
   - We are sure you know by now what to expect!
   - The pipeline should fail with the old image version and succeed with the latest image version!
diff --git a/content/14-advanced-pipeline/_index.md b/content/14-advanced-pipeline/_index.md
@@ -5,24 +5,29 @@ weight = 31
 
 ## Optimizing our DevSecOps Pipeline
 
-In the chapter before we created a Pipeline which builds, checks and deploys our image, if the image passes all ACS checks. But what should happen, if the image doesn't pass the ACS check? It doesn't seems to be a good idea to save an unsafe image in the internal OpenShift registry. 
-So lets modify our pipeline to an advanced one, which deletes an image, if it doesn't pass the ACS checks.
+In the chapter before we created a Pipeline which builds, checks and deploys our image, if the image passes all ACS checks. But what should happen, if the image doesn't pass the ACS check? It doesn't seems to be a good idea to keep an unsafe image in the internal OpenShift registry.
+So lets modify our pipeline to a more advanced one, which deletes an image, if it doesn't pass the ACS checks.
 
 ### Adding a Package Level Vulnerability
-Before we adjust our pipeline let's add another vulnerability to our Deployment. So far we had a system library security issue but let's image a developer tried to add (hopefully by mistake) a vulnerable Java library to his/her application. How about we pick one of the most infamous current ones such as the **Log4Shell** vulnerability?  But don't worry ACS already ships with a policy for that and has your back.
+
+Before we adjust our pipeline let's add another vulnerability to our Deployment. So far we had a system library security issue but let's imagine a developer tried to add (hopefully by mistake) a vulnerable Java library to his/her application. How about we pick one of the most infamous current ones such as the **Log4Shell** vulnerability? But don't worry ACS already ships with a policy for that and has your back.
 
 {{% notice tip %}}
-Quarkus doesn't use the log4J library for logging so is not affected by it. Although it is a bit contrived we will still force it to include the library just to trigger our policy.  If you want to find out more about this particular vulnerability have look [here](https://www.wired.com/story/log4j-log4shell/) 
+Quarkus doesn't use the log4J library for logging so is not affected by it. Although it is a bit contrived we will still force it to include the library just to trigger our policy. If you want to find out more about this particular vulnerability have look [here](https://www.wired.com/story/log4j-log4shell/)
 {{% /notice %}}
 
 To add this library to you Quarkus app
+
 - Go to your `quarkus-build-options` repo in `Gitea`
 - Edit the `pom.xml` file to include the new dependency
 - Find the line
+
 ```xml
     <!-- Add dependency here  -->
 ```
+
 and after that paste
+
 ```xml
     <!-- Add dependency here  -->
     <dependency>
@@ -36,37 +41,48 @@ and after that paste
       <version>2.9.1</version>
     </dependency>
 ```
+
 - Commit
 - Edit the `src/main/java/org/acme/GreetingResource.java` file to use the new dependency (otherwise Quarkus will just optimize it away)
 - Find the line
+
 ```java
    // Add import here
 ```
+
 and after that paste
+
 ```java
    // Add import here
   import org.apache.logging.log4j.Logger;
   import org.apache.logging.log4j.LogManager;
 ```
+
 - Find the line
+
 ```java
     // Add Logger instantiation here
 ```
+
 and after that paste
+
 ```java
    // Add Logger instantiation here
    private Logger logger = LogManager.getLogger(GreetingResource.class.getName());
 ```
-- Commit
 
-There you go. That developer has just introduced a ticking timebomb into the application. Let's see how far he will get with that.   
+- Commit
 
+There you go. That developer has just introduced a ticking timebomb into the application. Let's see how far he will get with that.
 
 ### ACS Prerequisites
+
 So there is a major security vulnerability in our code. ACS would detect the deployment because the System Policy `Log4Shell: log4j Remote Code Execution vulnerability` is enabled but won't stop it, because the Policy is not set to enforce.
+
 ## Modify Log4Shell Policy
 
-So first of all in the **ACS Portal** follow these steps: 
+So first of all in the **ACS Portal** follow these steps:
+
 - Navigate to **Platform Configuration > System Policies**
 - Search for `Log4Shell` and click on the Policy.
 - Click **Edit** at the upper right
@@ -75,20 +91,20 @@ Remember setting up image scanning with `roxctl` in our first pipeline? We use `
 
 - Remove the current categorie and add `Workshop`
 - Now hit next until you are at the enforcement tab
-- Enable both `Build` and `Deploy` enforcement by setting them to **On** 
+- Enable both `Build` and `Deploy` enforcement by setting them to **On**
 - Save the policy
 
-ACS is now able to detect and enforce the vulnerability. It is time now to implement your advanced Pipeline. 
+ACS is now able to detect and enforce the vulnerability. It is time now to implement your advanced Pipeline.
 
 ### Let's go: Create our advanced Pipeline
 
-In the **OpenShift Web Console**: 
+In the **OpenShift Web Console**:
 
 - Make sure you are in the `workshop-int` Project
 - Navigate to **Pipelines > Pipelines**
 - On the right click **Create > Pipeline**
 - Switch to **YAML view**
-- Replace the YAML with this making sure to update your two `Gitea` Repo URL's (Specifically replace the {YOUR_CLUSTER_HOSTNAME}): 
+- Replace the YAML with this making sure to update your two `Gitea` Repo URL's (Specifically replace the {YOUR_CLUSTER_HOSTNAME}):
 
 ```yaml
 apiVersion: tekton.dev/v1beta1
@@ -102,7 +118,7 @@ spec:
     - name: delete-image
       params:
         - name: SCRIPT
-          value: 'oc tag -d workshop-int/workshop:dev -n workshop-int'
+          value: "oc tag -d workshop-int/workshop:dev -n workshop-int"
         - name: VERSION
           value: latest
       taskRef:
@@ -169,7 +185,7 @@ spec:
         - name: revision
           value: $(params.GIT_REVISION)
         - name: deleteExisting
-          value: 'true'
+          value: "true"
       taskRef:
         kind: ClusterTask
         name: git-clone
@@ -181,7 +197,7 @@ spec:
         - name: IMAGE
           value: $(params.IMAGE_NAME)
         - name: TLSVERIFY
-          value: 'false'
+          value: "false"
         - name: PATH_CONTEXT
           value: $(params.PATH_CONTEXT)
         - name: VERSION
@@ -222,7 +238,7 @@ spec:
     - name: tag-checked-image
       params:
         - name: SCRIPT
-          value: 'oc tag workshop:dev workshop:latest'
+          value: "oc tag workshop:dev workshop:latest"
         - name: VERSION
           value: latest
       runAfter:
@@ -233,7 +249,7 @@ spec:
     - name: remove-dev-tag
       params:
         - name: SCRIPT
-          value: 'oc tag -d workshop:dev'
+          value: "oc tag -d workshop:dev"
         - name: VERSION
           value: latest
       runAfter:
@@ -244,6 +260,7 @@ spec:
   workspaces:
     - name: workspace
 ```
+
 - Click **Create**
 
 As you can see in the Pipeline visualization the flow is now a bit different. Lets see what has changed:
@@ -255,24 +272,29 @@ As you can see in the Pipeline visualization the flow is now a bit different. Le
 - The last three steps stays the same as before
 
 {{< figure src="../images/pipeline-adv.png?width=50pc&classes=border,shadow" title="Click image to enlarge" >}}
+
 ### Test the advanced Pipeline
 
-Go ahead and start your newly created advanced Pipeline. 
-Navigate to: 
+Go ahead and start your newly created advanced Pipeline.
+Navigate to:
+
 - **Pipelines -> Pipelines**
 - Click on **workshop-advanced**
 - In the top right corner click **Actions** -> **Start**
 - In the **Start Pipeline** window at the bottom set **workspace** to **PersistentVolumeClaim**
 - Set the **Select a PVC** drop-down to a PVC
 - Start the Pipeline
 
-See what happens and maybe play around with it and start again. Have fun! 
+See what happens and maybe play around with it and start again. Have fun!
 
 ### Fix the Vulnerability
+
 If by now the developer that introduced the log4jShell vulnerability has not realized that he/she "broke the build" you can tell him/her to update their dependency to a safe version.
 
 Go to your `quarkus-build-options` repo in `Gitea` again
+
 - Edit the `pom.xml` file update dependency to a safe version like this
+
 ```xml
     <!-- Add dependency here  -->
     <dependency>
@@ -286,4 +308,3 @@ Go to your `quarkus-build-options` repo in `Gitea` again
       <version>2.17.1</version>
     </dependency>
 ```
-
diff --git a/content/4-outer-loop/_index.md b/content/4-outer-loop/_index.md
@@ -10,9 +10,9 @@ Now that you have seen how a developer can quickly start to code using modern cl
 To create and run the build pipeline you'll use OpenShift Pipelines based on project Tekton. The first step is to install it:
 
 - Install the `Red hat OpenShift Pipelines` Operator from OperatorHub with default settings
-{{% notice warning %}}
-Since the Piplines assets are installed asynchronously it is possible that the `Pipline Templates` are not yet setup when proceeding immedately to the next step. So now is good time to grab a coffee.
-{{% /notice %}}
+  {{% notice warning %}}
+  Since the Piplines assets are installed asynchronously it is possible that the `Pipline Templates` are not yet setup when proceeding immedately to the next step. So now is good time to grab a coffee.
+  {{% /notice %}}
 
 ## Create App Deployment and Build Pipeline
 
@@ -22,20 +22,21 @@ After installing the Operator create a new deployment of your game-changing appl
 - Switch to the **OpenShift Developer Console**
 - Click the **+Add** menu entry to the left and choose **Import from Git**
 - As **Git Repo URL** enter the clone URL for the `quarkus-build-options` repo in your your `Gitea` instance (There might be a warning about the repo url that you can ignore)
+- Click **Show advanced Git options** and for **Git reference** enter `master`
 - As **Import Strategy** select **Builder Image**
-- As **Builder Image** select **Java** and **openjdk-11-el7** /  **Red Hat OpenJDK 11 (RHEL 7)** 
+- As **Builder Image** select **Java** and **openjdk-11-el7** / **Red Hat OpenJDK 11 (RHEL 7)**
 - As **Application Name** enter **workshop-app**
-- As **Name** enter **workshop** 
+- As **Name** enter **workshop**
 - Check **Add pipeline**
 
 {{% notice warning %}}
-If you don't have the checkbox **Add pipeline** and get the message `There are no pipeline templates available for Java and Deployment combination` in the next step then just give it few more minutes and reload the page. 
+If you don't have the checkbox **Add pipeline** and get the message `There are no pipeline templates available for Java and Deployment combination` in the next step then just give it few more minutes and reload the page.
 {{% /notice %}}
 
 - Click **Create**
 - In the main menu left, click on **Pipelines** and observe how the Tekton Pipeline is created and run.
 
-## Create an ImageStream Tag with an Old Image Version 
+## Create an ImageStream Tag with an Old Image Version
 
 Now your build pipeline has been set up and is ready. There is one more step in preparation of the security part of this workshop. We need a way to build and deploy from an older image with some security issues in it. For this we will add another ImageStream `Tag` in the default `Java` ImageStream that points to an older version with a known issue in it.
 
@@ -45,27 +46,28 @@ Now your build pipeline has been set up and is ready. There is one more step in
   - Be careful to keep the needed indentation!
 
 ```yaml
-    - name: java-old-image
-      annotations:
-        description: Build and run Java applications using Maven and OpenJDK 8.
-        iconClass: icon-rh-openjdk
-        openshift.io/display-name: Red Hat OpenJDK 8 (UBI 8)
-        sampleContextDir: undertow-servlet
-        sampleRepo: 'https://github.com/jboss-openshift/openshift-quickstarts'
-        supports: 'java:8,java'
-        tags: 'builder,java,openjdk'
-        version: '8'
-      from:
-        kind: DockerImage
-        name: 'registry.redhat.io/openjdk/openjdk-11-rhel7:1.10-1'
-      generation: 4
-      importPolicy: {}
-      referencePolicy:
-        type: Local
+- name: java-old-image
+  annotations:
+    description: Build and run Java applications using Maven and OpenJDK 8.
+    iconClass: icon-rh-openjdk
+    openshift.io/display-name: Red Hat OpenJDK 8 (UBI 8)
+    sampleContextDir: undertow-servlet
+    sampleRepo: "https://github.com/jboss-openshift/openshift-quickstarts"
+    supports: "java:8,java"
+    tags: "builder,java,openjdk"
+    version: "8"
+  from:
+    kind: DockerImage
+    name: "registry.redhat.io/openjdk/openjdk-11-rhel7:1.10-1"
+  generation: 4
+  importPolicy: {}
+  referencePolicy:
+    type: Local
 ```
 
 This will add a tag `java-old-image` that points to an older version of the RHEL Java image. The image and security vulnerabilities can be inspected in the Red Hat Software Catalog here:
 https://catalog.redhat.com/software/containers/openjdk/openjdk-11-rhel7/5bf57185dd19c775cddc4ce5?tag=1.10-1&push_date=1629294893000&container-tabs=security
+
 - Have a look at version `1.10-1`
 
 We will use this tag to test our security setup in a later chapter.
