Update: 31-01-2025

devsecops-advanced-pipelines-customization.md

@@ -135,7 +135,7 @@ compliance-checks:
     "/opt/commons/compliance-checks/run.sh"
 ```
 
-In that example, the script that is run is `/opt/commons/compliance-checks/run.sh`, which is located in the [commons library](https://us-south.git.cloud.ibm.com/open-toolchain/compliance-commons). Use this commons library as a source to copy code that can be customized for specific edge cases. In the example, `compliance-checks/run.sh` is located in the [compliance-commons library](https://us-south.git.cloud.ibm.com/open-toolchain/compliance-commons/-/blob/master/compliance-checks/run.sh).
+In that example, the script that is run is `/opt/commons/compliance-checks/run.sh`, which is located in the [commons library](https://us-south.git.cloud.ibm.com/open-toolchain/compliance-commons). Use this commons library as a source to copy code that can be customized for specific edge cases. In the example, `compliance-checks/run.sh` is located in the [compliance-commons library](https://us-south.git.cloud.ibm.com/open-toolchain/compliance-commons/-/blob/master/doc/compliance-checks__run.md).
 
 ### Overriding default scripts
 {: #override-default-scripts}
@@ -155,7 +155,9 @@ compliance-checks:
     "/opt/commons/compliance-checks/run.sh"
 ```
 1. Paste the snippet into your `.pipeline-config.yaml` file.
-1. Add your custom code before or after the script is called.
+1. Add your custom code before or after the script is called. 
+   This snippet invokes the default [compliance-checks script](https://us-south.git.cloud.ibm.com/open-toolchain/compliance-commons/-/blob/master/doc/compliance-checks__run.md)
+   {: note}
 1. Edit, delete, or add properties as needed.
 
 The following example shows the updated script in your `.pipeline-config.yaml` file:

devsecops-artifact-signing.md

@@ -1,8 +1,8 @@
 ---
 
 copyright: 
-  years: 2023, 2023
-lastupdated: "2023-09-13"
+  years: 2023, 2025
+lastupdated: "2025-01-31"
 
 keywords: DevSecOps, IBM Cloud, public key, private key, GPG
 
@@ -37,11 +37,11 @@ Before you get started with non-image artifact signing, you must have the follow
       dind: true
       script: |
          #!/usr/bin/env bash
-         source /opt/commons/sign-artifact/sign-artifacts.sh
+         source ${COMMONS_PATH}/sign-artifact/sign-artifacts.sh
    ```
    {: codeblock}
 
-3. By default, the script can sign all artifacts that are listed in the `list_artifacts` collection. Be sure that your artifacts are properly stored and integrated. 
+3. By default, the [sign-artifacts script](https://us-south.git.cloud.ibm.com/open-toolchain/compliance-commons/-/blob/master/doc/sign-artifact__sign-artifacts.md) can sign all artifacts that are listed in the `list_artifacts` collection. Be sure that your artifacts are properly stored and integrated. 
 
    1. Ensure that you store built artifacts in the Cocoa pipeline runtime. This can be achieved in one of the two following ways.
 
@@ -129,4 +129,3 @@ If you need to store the signed artifact, you can use a storage solution of your
             "${params[@]}"
 ```
 {: codeblock}
-

devsecops-doi-publish-testrecords.md

@@ -16,6 +16,7 @@ subcollection: devsecops
 
 `doi-publish-testrecord` is a script containing helper functions for Devops Insights, using the `ibmcloud doi` CLI plugin to publish a test record to DevOps Insights.  
 
+This script is part of the [Commons Scripts Library](https://us-south.git.cloud.ibm.com/open-toolchain/compliance-commons#tool-inventory).
 
 ## Inputs
 {: #doi-publish-testrecord-inputs}
@@ -83,4 +84,3 @@ doi-publish-testrecord-with-appname \
   "<app_name>"
 ```
 {: codeblock}
-

devsecops-doi-publish.md

@@ -17,6 +17,8 @@ subcollection: devsecops
 
 `doi-publish` is a function designed to download an attachment and publish it as a test record to DevOps Insights.
 
+This function is provided by the [`doi-publish-test-record`](https://us-south.git.cloud.ibm.com/open-toolchain/compliance-commons/-/blob/master/doc/doi__doi-publish-testrecord.md) script that is part of the [Commons Scripts Library](https://us-south.git.cloud.ibm.com/open-toolchain/compliance-commons#tool-inventory).
+
 The function does the following tasks:
 
 - Uses the download-attachment function to retrieve the file specified by evidence-file and attachment-label, saving it to attachment-output-path.
@@ -65,8 +67,3 @@ doi-publish \
 {: #multi-attachment-doi-publish}
 
 The doi-publish function does not support multiple attachments. It is designed to handle only a single attachment per execution. If you need to publish multiple attachments, you will need to run the doi-publish function separately for each attachment.
-
-
-
-
-

devsecops-inferred-pipeline-configuration.md

@@ -2,7 +2,7 @@
 
 copyright:
   years: 2024, 2025
-lastupdated: "2025-01-27"
+lastupdated: "2025-01-31"
 
 keywords: DevSecOps, polyglot, inferred devsecops, spots
 
@@ -273,6 +273,10 @@ You can ignore specific spots during extraction by using regular expressions. Th
 If you are using IBM Cloud Code Engine for deployment, specify the Code Engine project and configure the build process with the following spots:
 * `code-engine-project`: Specifies the Code Engine project.
 * `code-engine-build-use-native-docker`: (Default: `false`) Indicates whether to use Docker CLI instead of `ibmcloud code-engine buildrun` command.
+* `root-as-build-context`: (Default: `false`) indicates that the build context for `Dockerfile` related building tool (like `docker` or `code-engine`) should use the root of the repository as build context and not the folder containing the Dockerfile.
+
+#### Docker build configuration
+* `root-as-build-context`: (Default: `false`) indicates that the build context for `Dockerfile` related building tool (like `docker` or `code-engine`) should use the root of the repository as build context and not the folder containing the Dockerfile.
 
 #### Golang Configuration
 {: #devsecops-pipeline-configuration-spot-go}