From 98b6f38d57ab091eb6aadece10669fa9d48d96ea Mon Sep 17 00:00:00 2001
From: Ali Tariq <alitariq4589@gmail.com>
Date: Thu, 9 May 2024 12:22:29 +0500
Subject: [PATCH 1/4] Added K230 docs and isa strings

---
 mkdocs_src/docs/runner_specs.md     | 31 +++++++++++++++--------------
 mkdocs_src/docs/tooling_J-K230-1.md | 28 ++++++++++++++++++++++++++
 mkdocs_src/mkdocs.yml               |  1 +
 3 files changed, 45 insertions(+), 15 deletions(-)
 create mode 100644 mkdocs_src/docs/tooling_J-K230-1.md

diff --git a/mkdocs_src/docs/runner_specs.md b/mkdocs_src/docs/runner_specs.md
index 512ab98..39e3937 100644
--- a/mkdocs_src/docs/runner_specs.md
+++ b/mkdocs_src/docs/runner_specs.md
@@ -2,21 +2,22 @@
 
 This document contains the specifications of the compute instances available for users to run builds in Cloud-V. The term "Compute Instance", can also be safely interchanged with the terms "Build Executor" and "Runner".
 
-| Name String | Architecture | Cores | Memory | Compute Instance Type |
-| ---- | ------- | -------------- | ------------ | ------------------ |
+| Name String | Architecture | Cores | Memory | Compute Instance Type | ISA String |
+| ---- | ------- | -------------- | ------------ | ------------------ | ---- |
 | J-x86-1 (or) J-QMU-1 | x86_64 | 4 | 8GiB | Hardware with application-level emulator |
-| J-TESTVM-1 | x86_64 | 4 | 8GiB | Hardware |
-| J-RASP4-1 | aarch64 | 4 | 4GiB | Hardware |
-| J-QMS-1 | riscv64 | 2 | 2GiB | QEMU System emulator |
-| J-VF1-1 | riscv64 | 2 | 8GiB | Hardware |
-| J-VF1-2 | riscv64 | 2 | 8GiB | Hardware |
-| J-VF1-3 | riscv64 | 2 | 8GiB | Hardware |
-| J-VF2-1 | riscv64 | 4 | 8GiB | Hardware |
-| J-VF2-2 | riscv64 | 4 | 8GiB | Hardware |
-| J-VF2-3 | riscv64 | 4 | 8GiB | Hardware |
-| J-VF2-4 | riscv64 | 4 | 8GiB | Hardware |
-| J-VF2-5 | riscv64 | 4 | 8GiB | Hardware |
-| J-VF2-6 | riscv64 | 4 | 8GiB | Hardware |
-| J-HF-1 | riscv64 | 4 | 8GiB | Hardware |
+| J-TESTVM-1 | x86_64 | 4 | 8GiB | Hardware | N/A |
+| J-RASP4-1 | aarch64 | 4 | 4GiB | Hardware | ARMv8-A |
+| J-QMS-1 | riscv64 | 2 | 2GiB | QEMU System emulator | rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc |
+| J-VF1-1 | riscv64 | 2 | 8GiB | Hardware | rv64imafdc |
+| J-VF1-2 | riscv64 | 2 | 8GiB | Hardware | rv64imafdc |
+| J-VF1-3 | riscv64 | 2 | 8GiB | Hardware | rv64imafdc |
+| J-VF2-1 | riscv64 | 4 | 8GiB | Hardware | rv64imafdc |
+| J-VF2-2 | riscv64 | 4 | 8GiB | Hardware | rv64imafdc |
+| J-VF2-3 | riscv64 | 4 | 8GiB | Hardware | rv64imafdc |
+| J-VF2-4 | riscv64 | 4 | 8GiB | Hardware | rv64imafdc |
+| J-VF2-5 | riscv64 | 4 | 8GiB | Hardware | rv64imafdc |
+| J-VF2-6 | riscv64 | 4 | 8GiB | Hardware | rv64imafdc |
+| J-HF-1 | riscv64 | 4 | 8GiB | Hardware | rv64imafdc |
+| J-K230-1 | riscv64 | 1 | 512MiB | Hardware | rv64imafdcvxthead |
 
 ***Note:** The `J-QMU-1` and `J-x86-1` are one and the same runner. The purpose of creating two separate executors for same hardware is that `J-x86-1` is supposed to be specifically for x86 architecture whereas `J-QMU-1` is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for `J-x86-1` can also be used for `J-QMU-1`*
diff --git a/mkdocs_src/docs/tooling_J-K230-1.md b/mkdocs_src/docs/tooling_J-K230-1.md
new file mode 100644
index 0000000..d6b801d
--- /dev/null
+++ b/mkdocs_src/docs/tooling_J-K230-1.md
@@ -0,0 +1,28 @@
+# Tools on `J-K230-1` node
+
+This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture.  
+
+**Operating System:** Debian 12 (Bookworm)
+
+| Tool | Version | Installed from |
+| ---- | ------- | -------------- |
+| Git | 2.40.1 | apt |
+| OpenJDK | 21.0.2 | apt |
+| GCC | 13.2.0 | apt |
+| Python3 | 3.11.6 | apt |
+| OpenSSL | 3.0.10 | apt |
+| Ruby | 3.1.2p20 | apt |
+| Go | 1.21.1 | apt |
+| rustc | 1.75.0 | apt |
+| Flex | 2.6.4 | apt |
+| Ninja | 1.11.1 | apt |
+| Bison | 3.8.2 | apt |
+| autoconf | 2.71 | apt |
+| gperf | 3.1 | apt |
+| cmake | 3.27.4 | apt |
+| make | 4.3 | apt |
+| automake | 1.16.5 | apt |
+| gfortran | 13.2.0 | apt |
+| openssh-server | 9.3p1 | apt |
+| vim | 9.0 | apt |
+| vim | 3.3a | apt |
diff --git a/mkdocs_src/mkdocs.yml b/mkdocs_src/mkdocs.yml
index 8a7e481..add8087 100755
--- a/mkdocs_src/mkdocs.yml
+++ b/mkdocs_src/mkdocs.yml
@@ -11,6 +11,7 @@ nav:
       - J-VF1-x: tooling_J-VF1-x.md
       - J-VF2-x: tooling_J-VF2-x.md
       - J-HF-1: tooling_J-HF-1.md
+      - J-K230-1: tooling_J-K230-1.md
 
 # - For Administrators:
 #     - Jenkins Docs:

From 6240b94cfd8ccbf2029d287e853969c2d2b29748 Mon Sep 17 00:00:00 2001
From: Ali Tariq <alitariq4589@gmail.com>
Date: Thu, 9 May 2024 12:25:09 +0500
Subject: [PATCH 2/4] Built docs

---
 build_mkdocs.sh                            |   3 +-
 docs/404.html                              |   2 +
 docs/Creating_CI_CD_pipeline/index.html    |   2 +
 docs/Creating_jenkinsfile/index.html       |   2 +
 docs/Multinode_Pipelines/index.html        |   2 +
 docs/Software_Developer_Guide/index.html   |   2 +
 docs/Tooling/index.html                    |   2 +
 docs/index.html                            |   4 +-
 docs/jenkins_gitlab_integration/index.html |   2 +
 docs/runner_specs/index.html               |  25 ++
 docs/search.html                           |   2 +
 docs/search/search_index.json              |   2 +-
 docs/sitemap.xml.gz                        | Bin 127 -> 127 bytes
 docs/tooling_J-HF-1/index.html             |   5 +
 docs/tooling_J-K230-1/index.html           | 259 +++++++++++++++++++++
 docs/tooling_J-QMS-1/index.html            |   2 +
 docs/tooling_J-QMU-1J-VM-1/index.html      |   2 +
 docs/tooling_J-VF1-x/index.html            |   2 +
 docs/tooling_J-VF2-x/index.html            |   2 +
 19 files changed, 319 insertions(+), 3 deletions(-)
 create mode 100644 docs/tooling_J-K230-1/index.html

diff --git a/build_mkdocs.sh b/build_mkdocs.sh
index e9b48d8..3beb54d 100755
--- a/build_mkdocs.sh
+++ b/build_mkdocs.sh
@@ -1,4 +1,5 @@
-cd mkdocs_src
+#!/bin/bash
+cd mkdocs_src || exit
 mkdocs gh-deploy -d ../docs
 cd ..
 git add .
diff --git a/docs/404.html b/docs/404.html
index 014780d..b9e3ec5 100644
--- a/docs/404.html
+++ b/docs/404.html
@@ -62,6 +62,8 @@
                   </li>
                   <li class="toctree-l1"><a class="reference internal" href="/tooling_J-HF-1/">J-HF-1</a>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="/tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>
diff --git a/docs/Creating_CI_CD_pipeline/index.html b/docs/Creating_CI_CD_pipeline/index.html
index 3d2a21e..b6aaa13 100644
--- a/docs/Creating_CI_CD_pipeline/index.html
+++ b/docs/Creating_CI_CD_pipeline/index.html
@@ -69,6 +69,8 @@
                   </li>
                   <li class="toctree-l1"><a class="reference internal" href="../tooling_J-HF-1/">J-HF-1</a>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>
diff --git a/docs/Creating_jenkinsfile/index.html b/docs/Creating_jenkinsfile/index.html
index 148f367..5c18e00 100644
--- a/docs/Creating_jenkinsfile/index.html
+++ b/docs/Creating_jenkinsfile/index.html
@@ -93,6 +93,8 @@
                   </li>
                   <li class="toctree-l1"><a class="reference internal" href="../tooling_J-HF-1/">J-HF-1</a>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>
diff --git a/docs/Multinode_Pipelines/index.html b/docs/Multinode_Pipelines/index.html
index 032f580..64c7c78 100644
--- a/docs/Multinode_Pipelines/index.html
+++ b/docs/Multinode_Pipelines/index.html
@@ -69,6 +69,8 @@
                   </li>
                   <li class="toctree-l1"><a class="reference internal" href="../tooling_J-HF-1/">J-HF-1</a>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>
diff --git a/docs/Software_Developer_Guide/index.html b/docs/Software_Developer_Guide/index.html
index a0425d7..cedbfcf 100644
--- a/docs/Software_Developer_Guide/index.html
+++ b/docs/Software_Developer_Guide/index.html
@@ -89,6 +89,8 @@
                   </li>
                   <li class="toctree-l1"><a class="reference internal" href="../tooling_J-HF-1/">J-HF-1</a>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>
diff --git a/docs/Tooling/index.html b/docs/Tooling/index.html
index e931d84..bc8d783 100644
--- a/docs/Tooling/index.html
+++ b/docs/Tooling/index.html
@@ -73,6 +73,8 @@
                   </li>
                   <li class="toctree-l1"><a class="reference internal" href="../tooling_J-HF-1/">J-HF-1</a>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>
diff --git a/docs/index.html b/docs/index.html
index 8d0e623..cd8f74a 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -71,6 +71,8 @@
                   </li>
                   <li class="toctree-l1"><a class="reference internal" href="tooling_J-HF-1/">J-HF-1</a>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>
@@ -147,5 +149,5 @@ <h1 id="cloud-v-documentation">Cloud-V Documentation</h1>
 
 <!--
 MkDocs version : 1.5.3
-Build Date UTC : 2024-04-17 07:18:46.831530+00:00
+Build Date UTC : 2024-05-09 07:24:56.687063+00:00
 -->
diff --git a/docs/jenkins_gitlab_integration/index.html b/docs/jenkins_gitlab_integration/index.html
index 55ea32f..6444bca 100644
--- a/docs/jenkins_gitlab_integration/index.html
+++ b/docs/jenkins_gitlab_integration/index.html
@@ -69,6 +69,8 @@
                   </li>
                   <li class="toctree-l1"><a class="reference internal" href="../tooling_J-HF-1/">J-HF-1</a>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>
diff --git a/docs/runner_specs/index.html b/docs/runner_specs/index.html
index d854130..2149a48 100644
--- a/docs/runner_specs/index.html
+++ b/docs/runner_specs/index.html
@@ -71,6 +71,8 @@
                   </li>
                   <li class="toctree-l1"><a class="reference internal" href="../tooling_J-HF-1/">J-HF-1</a>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>
@@ -105,6 +107,7 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <th>Cores</th>
 <th>Memory</th>
 <th>Compute Instance Type</th>
+<th>ISA String</th>
 </tr>
 </thead>
 <tbody>
@@ -114,6 +117,7 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware with application-level emulator</td>
+<td></td>
 </tr>
 <tr>
 <td>J-TESTVM-1</td>
@@ -121,6 +125,7 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
+<td>N/A</td>
 </tr>
 <tr>
 <td>J-RASP4-1</td>
@@ -128,6 +133,7 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <td>4</td>
 <td>4GiB</td>
 <td>Hardware</td>
+<td>ARMv8-A</td>
 </tr>
 <tr>
 <td>J-QMS-1</td>
@@ -135,6 +141,7 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <td>2</td>
 <td>2GiB</td>
 <td>QEMU System emulator</td>
+<td>rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc</td>
 </tr>
 <tr>
 <td>J-VF1-1</td>
@@ -142,6 +149,7 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <td>2</td>
 <td>8GiB</td>
 <td>Hardware</td>
+<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF1-2</td>
@@ -149,6 +157,7 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <td>2</td>
 <td>8GiB</td>
 <td>Hardware</td>
+<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF1-3</td>
@@ -156,6 +165,7 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <td>2</td>
 <td>8GiB</td>
 <td>Hardware</td>
+<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF2-1</td>
@@ -163,6 +173,7 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
+<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF2-2</td>
@@ -170,6 +181,7 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
+<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF2-3</td>
@@ -177,6 +189,7 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
+<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF2-4</td>
@@ -184,6 +197,7 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
+<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF2-5</td>
@@ -191,6 +205,7 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
+<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF2-6</td>
@@ -198,6 +213,7 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
+<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-HF-1</td>
@@ -205,6 +221,15 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
+<td>rv64imafdc</td>
+</tr>
+<tr>
+<td>J-K230-1</td>
+<td>riscv64</td>
+<td>1</td>
+<td>512MiB</td>
+<td>Hardware</td>
+<td>rv64imafdcvxthead</td>
 </tr>
 </tbody>
 </table>
diff --git a/docs/search.html b/docs/search.html
index fae2139..7efdfa3 100644
--- a/docs/search.html
+++ b/docs/search.html
@@ -62,6 +62,8 @@
                   </li>
                   <li class="toctree-l1"><a class="reference internal" href="./tooling_J-HF-1/">J-HF-1</a>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="./tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>
diff --git a/docs/search/search_index.json b/docs/search/search_index.json
index 2b874bc..2e32ead 100644
--- a/docs/search/search_index.json
+++ b/docs/search/search_index.json
@@ -1 +1 @@
-{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"Cloud-V Documentation This documentation lists the tooling and necessary information to use Cloud-V for RISC-V application development on RISC-V compute instances provided by Cloud-V Overview Slides: link Youtube Channel: youtube.com/@Cloud-V","title":"Home"},{"location":"#cloud-v-documentation","text":"This documentation lists the tooling and necessary information to use Cloud-V for RISC-V application development on RISC-V compute instances provided by Cloud-V Overview Slides: link Youtube Channel: youtube.com/@Cloud-V","title":"Cloud-V Documentation"},{"location":"Creating_CI_CD_pipeline/","text":"Creating a CI/CD pipeline in Jenkins Pre Requisistes For sake of this documentation, jenkins built-in sample script is used to create and execute a cd/cd pipeline in jenkins. In the built-in script maven is used as M3, so one must install Maven plugin inside jenkins and name it M3 . Usually maven is already present inside jenkins and can be configured from Global Configuration Tools . Following steps demonstrate configuring Maven plugin. Go to Jenkins Dashboard and click on Manage Jenkins In Manage Jenkins , under System Configuration section, click on Global Tool Configuration . In Global Tool Configuration , scroll down to Maven section and click on the respective option under the Maven Section (should be Maven installations\u2026 or Add Maven ). Under Maven installations , enter M3 in \u201cname\u201d text box, check Install Automatically and select Version greater than 3, then click Apply and Save . This should install Maven version 3 and configure as M3 . Steps for Jenkins pipeline creation After installing Jenkins and having all the suggested plugins installed, go to Jenkins dashboard and click on Create Job . On the next page, give your pipeline a name, select Pipeline and click OK . A Configuration page for the pipeline will appear. Select Build Triggers options and General options according to need and scroll down to the Pipeline section. Definition section contains configuration for stages and steps of the pipeline. Under Definition section, you can either choose Pipeline script and try writing your own script or try some sample pipeline (like Hello World , Github+Maven etc) or you could select Pipeline script from SCM and give a github repository containing configurations of Pipeline. Press Save and Apply . This should take you to the Pipeline and you can build the pipeline and if no unresolved dependencies are present, the pipeline should build without any error.","title":"Creating a CI/CD pipeline in Jenkins"},{"location":"Creating_CI_CD_pipeline/#creating-a-cicd-pipeline-in-jenkins","text":"","title":"Creating a CI/CD pipeline in Jenkins"},{"location":"Creating_CI_CD_pipeline/#pre-requisistes","text":"For sake of this documentation, jenkins built-in sample script is used to create and execute a cd/cd pipeline in jenkins. In the built-in script maven is used as M3, so one must install Maven plugin inside jenkins and name it M3 . Usually maven is already present inside jenkins and can be configured from Global Configuration Tools . Following steps demonstrate configuring Maven plugin. Go to Jenkins Dashboard and click on Manage Jenkins In Manage Jenkins , under System Configuration section, click on Global Tool Configuration . In Global Tool Configuration , scroll down to Maven section and click on the respective option under the Maven Section (should be Maven installations\u2026 or Add Maven ). Under Maven installations , enter M3 in \u201cname\u201d text box, check Install Automatically and select Version greater than 3, then click Apply and Save . This should install Maven version 3 and configure as M3 .","title":"Pre Requisistes"},{"location":"Creating_CI_CD_pipeline/#steps-for-jenkins-pipeline-creation","text":"After installing Jenkins and having all the suggested plugins installed, go to Jenkins dashboard and click on Create Job . On the next page, give your pipeline a name, select Pipeline and click OK . A Configuration page for the pipeline will appear. Select Build Triggers options and General options according to need and scroll down to the Pipeline section. Definition section contains configuration for stages and steps of the pipeline. Under Definition section, you can either choose Pipeline script and try writing your own script or try some sample pipeline (like Hello World , Github+Maven etc) or you could select Pipeline script from SCM and give a github repository containing configurations of Pipeline. Press Save and Apply . This should take you to the Pipeline and you can build the pipeline and if no unresolved dependencies are present, the pipeline should build without any error.","title":"Steps for Jenkins pipeline creation"},{"location":"Creating_jenkinsfile/","text":"Creating a Cloud-V CI Pipeline file What is a Cloud-V CI Pipeline file A cloud-v-pipeline file is a Continuous Integration (CI) jenkins pipeline script which is written in Groovy. It describes various stages (and possibly steps) which are executed in the defined pattern. These stages can be written in bash or they can be written in Groovy itself. Mainly there can be two types of Cloud-V pipeline files are of two types: Scripted: Only contains stages Declarative: Contains stages as well as steps (more feature-rich and recommended) This documentation will cover how to create a cloud-v-pipeline file with bash script inside it and run it on various compute instances (which are known as Nodes in jenkins). Jenkins Node In jenkins, node represents a compute instance. In simple words, it is the platform on which our job build is going to run. Jenkins Master There is a jenkins Master node which is actually the compute instance on which Jenkins is installed. It is the node which schedules builds on runners. For security reason, no job is allowed to run on this node. Jenkins Slave Jenkins slave nodes are the compute instances on which our job builds run safely. They may be attached with jenkins master via hardware or they may be connected through remote SSH connection. cloud-v-pipeline file written with bash Simple Hello World cloud-v-pipeline file In Cloud-V, all the platforms are running Linux operating system, so the cloud-v-pipeline should be written in bash. Following script is an example of how can we run a bash script in scripted cloud-v-pipeline . node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } The keyword sh is used to specify a shell script As there is nothing mentioned with node , so the script will run job build on any available compute instance. cloud-v-pipeline for a Specific Node In previous script, the cloud-v-pipeline would run on any compute instances which are available. But in case if someone wants to run a job build on specific node, then a compute instance name must be specified with keyword node . The following script is an example of running above Hello World program on node named hifive_unleashed . node('hifive_unleashed'){ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } cloud-v-pipeline for Cross-Platform Compilation and Execution Cloud-V supports cross-compilation and execution on emulated RISC-V compute instances. Following tools help in cross compilation and cross-platfrom execution: RISC-V GNU Toolchain QEMU user mode (for running standalone binaries) QEMU System (for running application in Linux) An example pipeline script is given below in scripted pipeline. node('x86_runner2'){ checkout scm //Getting content of this repo stage('*** Compilation Phase ***') { // for display purposes //Compiling helloworld.c using bash commands sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out //Cross compiling for RISC-V ''' } stage (' *** Running Binaries ***'){ sh '''#!/bin/bash ./helloworld.out qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out //Running executable on RISC-V emulated platform ''' } } The equivalent declarative pipeline is as follows: pipeline { agent {label \"x86_runner2\"} stages { stage('Clone Repository') { steps('delegate'){ checkout scm //Clones the repository on the local machine } } stage ('Compilation Phase'){ steps{ sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out ''' sh '''#!/bin/bash riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out ''' } } stage ('Running Binaries'){ steps { sh ''' #!/bin/bash ./helloworld.out ''' sh'''#!/bin/bash qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out ''' } } } } Reference Links https://www.jenkins.io/doc/book/pipeline/syntax/","title":"Creating a CI pipeline file"},{"location":"Creating_jenkinsfile/#creating-a-cloud-v-ci-pipeline-file","text":"","title":"Creating a Cloud-V CI Pipeline file"},{"location":"Creating_jenkinsfile/#what-is-a-cloud-v-ci-pipeline-file","text":"A cloud-v-pipeline file is a Continuous Integration (CI) jenkins pipeline script which is written in Groovy. It describes various stages (and possibly steps) which are executed in the defined pattern. These stages can be written in bash or they can be written in Groovy itself. Mainly there can be two types of Cloud-V pipeline files are of two types: Scripted: Only contains stages Declarative: Contains stages as well as steps (more feature-rich and recommended) This documentation will cover how to create a cloud-v-pipeline file with bash script inside it and run it on various compute instances (which are known as Nodes in jenkins).","title":"What is a Cloud-V CI Pipeline file"},{"location":"Creating_jenkinsfile/#jenkins-node","text":"In jenkins, node represents a compute instance. In simple words, it is the platform on which our job build is going to run.","title":"Jenkins Node"},{"location":"Creating_jenkinsfile/#jenkins-master","text":"There is a jenkins Master node which is actually the compute instance on which Jenkins is installed. It is the node which schedules builds on runners. For security reason, no job is allowed to run on this node.","title":"Jenkins Master"},{"location":"Creating_jenkinsfile/#jenkins-slave","text":"Jenkins slave nodes are the compute instances on which our job builds run safely. They may be attached with jenkins master via hardware or they may be connected through remote SSH connection.","title":"Jenkins Slave"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-file-written-with-bash","text":"","title":"cloud-v-pipeline file written with bash"},{"location":"Creating_jenkinsfile/#simple-hello-world-cloud-v-pipeline-file","text":"In Cloud-V, all the platforms are running Linux operating system, so the cloud-v-pipeline should be written in bash. Following script is an example of how can we run a bash script in scripted cloud-v-pipeline . node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } The keyword sh is used to specify a shell script As there is nothing mentioned with node , so the script will run job build on any available compute instance.","title":"Simple Hello World cloud-v-pipeline file"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-for-a-specific-node","text":"In previous script, the cloud-v-pipeline would run on any compute instances which are available. But in case if someone wants to run a job build on specific node, then a compute instance name must be specified with keyword node . The following script is an example of running above Hello World program on node named hifive_unleashed . node('hifive_unleashed'){ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } }","title":"cloud-v-pipeline for a Specific Node"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-for-cross-platform-compilation-and-execution","text":"Cloud-V supports cross-compilation and execution on emulated RISC-V compute instances. Following tools help in cross compilation and cross-platfrom execution: RISC-V GNU Toolchain QEMU user mode (for running standalone binaries) QEMU System (for running application in Linux) An example pipeline script is given below in scripted pipeline. node('x86_runner2'){ checkout scm //Getting content of this repo stage('*** Compilation Phase ***') { // for display purposes //Compiling helloworld.c using bash commands sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out //Cross compiling for RISC-V ''' } stage (' *** Running Binaries ***'){ sh '''#!/bin/bash ./helloworld.out qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out //Running executable on RISC-V emulated platform ''' } } The equivalent declarative pipeline is as follows: pipeline { agent {label \"x86_runner2\"} stages { stage('Clone Repository') { steps('delegate'){ checkout scm //Clones the repository on the local machine } } stage ('Compilation Phase'){ steps{ sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out ''' sh '''#!/bin/bash riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out ''' } } stage ('Running Binaries'){ steps { sh ''' #!/bin/bash ./helloworld.out ''' sh'''#!/bin/bash qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out ''' } } } }","title":"cloud-v-pipeline for Cross-Platform Compilation and Execution"},{"location":"Creating_jenkinsfile/#reference-links","text":"https://www.jenkins.io/doc/book/pipeline/syntax/","title":"Reference Links"},{"location":"Multinode_Pipelines/","text":"Multinode Pipelines One can create multinode pipelines in jenkins freestyle pipeline job as well as in jenkins native pipeline job. In such a pipeline, different stages of the pipeline can run on separate nodes. The jenkins native pipeline job can have two types. Scripted Pipeline Declarative pipeline For the sake of this documentation, two nodes are used: container-node and container-node2 Label In jenkins, label specifies where the job or a stage of the job can run. In jenkins, a label can be explicitly added in the node's configuration so that each time that label is mentioned in a jenkins job, that specific node is used for building the job, or the name of the node can also be used as label in case if no label is added in the node. Creating multinode pipelines in Jenkins native pipeline job Scripted Pipeline For creating a multinode pipeline with jenkins native scripted pipeline job, jenkinsfile can be tweaked. The keyword node can be used to specify the node in which the stages are going to run and this keyword can also be used in between stages. Following screenshot indicates a code in which first stage runs on node named container-node . While the second node runs on node named container-node2 . node ('container-node') { stage ('*** Creating a directory in container-node ***'){ sh '''#!/bin/bash mkdir newdir_container-node-$RANDOM ''' } stage ('*** Creating a directory in container-node2'){ node ('container-node2'){ sh'''#!/bin/bash mkdir newdir_container-node2-$RANDOM ''' } } } Declarative pipeline For a declarative pipeline the keyword label can be used in the agent block. This can either be done at the start of the pipeline after the keyword pipeline or it can be used inside the stages. The following code builds two stages each of which is built in separate node. The keyword none with agent means that the agent is not specified globally for each stage and it should be specified inside each stage. pipeline { agent none // Means no agent specified. This means each node will specify its own agent stages { stage('container-node') { agent{ label \"container-node\" //Selecting container-node for this stage } steps { sh '''#!/bin/bash echo 'Hello container-node' mkdir \"newdir-container-node-$RANDOM\" ''' } } stage('container-node2'){ agent{ label \"container-node2\" //Selecting container-node2 for this stage } steps{ sh'''#!/bin/bash echo ''Hello container-node2 mkdir \"newdir-container-node2-$RANDOM\" ''' } } } } Creating multinode pipelines using Jenkins freestyle jobs Jenkins freestyle jobs can be combined together by mentioning post-build jobs in the freestyle job settings. Freestyle jobs are customizable and offer more options than jenkins native pipeline jobs. Each job represents a stage and each stage has separate settings. One can use jenkins freestyle jobs to run on a separate node by selecting the option Restrict where this project can be run in the General section of the job's configuration. In the Label Expression , the node's name can be mentioned in which to run the job. The following image shows the option from job's configuration. This can be done in all the job's configuration for the specified node.","title":"Multinode Pipelines"},{"location":"Multinode_Pipelines/#multinode-pipelines","text":"One can create multinode pipelines in jenkins freestyle pipeline job as well as in jenkins native pipeline job. In such a pipeline, different stages of the pipeline can run on separate nodes. The jenkins native pipeline job can have two types. Scripted Pipeline Declarative pipeline For the sake of this documentation, two nodes are used: container-node and container-node2","title":"Multinode Pipelines"},{"location":"Multinode_Pipelines/#label","text":"In jenkins, label specifies where the job or a stage of the job can run. In jenkins, a label can be explicitly added in the node's configuration so that each time that label is mentioned in a jenkins job, that specific node is used for building the job, or the name of the node can also be used as label in case if no label is added in the node.","title":"Label"},{"location":"Multinode_Pipelines/#creating-multinode-pipelines-in-jenkins-native-pipeline-job","text":"","title":"Creating multinode pipelines in Jenkins native pipeline job"},{"location":"Multinode_Pipelines/#scripted-pipeline","text":"For creating a multinode pipeline with jenkins native scripted pipeline job, jenkinsfile can be tweaked. The keyword node can be used to specify the node in which the stages are going to run and this keyword can also be used in between stages. Following screenshot indicates a code in which first stage runs on node named container-node . While the second node runs on node named container-node2 . node ('container-node') { stage ('*** Creating a directory in container-node ***'){ sh '''#!/bin/bash mkdir newdir_container-node-$RANDOM ''' } stage ('*** Creating a directory in container-node2'){ node ('container-node2'){ sh'''#!/bin/bash mkdir newdir_container-node2-$RANDOM ''' } } }","title":"Scripted Pipeline"},{"location":"Multinode_Pipelines/#declarative-pipeline","text":"For a declarative pipeline the keyword label can be used in the agent block. This can either be done at the start of the pipeline after the keyword pipeline or it can be used inside the stages. The following code builds two stages each of which is built in separate node. The keyword none with agent means that the agent is not specified globally for each stage and it should be specified inside each stage. pipeline { agent none // Means no agent specified. This means each node will specify its own agent stages { stage('container-node') { agent{ label \"container-node\" //Selecting container-node for this stage } steps { sh '''#!/bin/bash echo 'Hello container-node' mkdir \"newdir-container-node-$RANDOM\" ''' } } stage('container-node2'){ agent{ label \"container-node2\" //Selecting container-node2 for this stage } steps{ sh'''#!/bin/bash echo ''Hello container-node2 mkdir \"newdir-container-node2-$RANDOM\" ''' } } } }","title":"Declarative pipeline"},{"location":"Multinode_Pipelines/#creating-multinode-pipelines-using-jenkins-freestyle-jobs","text":"Jenkins freestyle jobs can be combined together by mentioning post-build jobs in the freestyle job settings. Freestyle jobs are customizable and offer more options than jenkins native pipeline jobs. Each job represents a stage and each stage has separate settings. One can use jenkins freestyle jobs to run on a separate node by selecting the option Restrict where this project can be run in the General section of the job's configuration. In the Label Expression , the node's name can be mentioned in which to run the job. The following image shows the option from job's configuration. This can be done in all the job's configuration for the specified node.","title":"Creating multinode pipelines using Jenkins freestyle jobs"},{"location":"Software_Developer_Guide/","text":"Software Developer Guide for RISC-V CI A software developer is the end-user who will develop or build his/her projects on RISC-V CI infrastructure. This guide will cover all the things a software developer needs to create a project based on Cloud-V Continuous Integration (CI). Pre-requisites GitHub account. GitHub project repository with owner rights. Getting an account for Cloud-V Fill out this google form with all the required information for getting an account on Cloud-V. After this we will get back to you with login credentials. Setting up cloud-v-pipeline inside github project repository Cloud-V will need a cloud-v-pipeline written with jenkinsfile pipeline syntax to start execution of tests/checks (see link ). This pipeline will contain all the stages (and may be steps) of a CI/CD pipeline. This pipeline can be scripted pipeline which will only have stages or it can also be declarative pipeline which may also have steps inside stages. A simple scripted Helloworld pipeline in linux is as follows: node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } Upon execution of such a pipeline, the console output can be viewed as follows. Note: This cloud-v-pipeline should remain same in all the branches and pull requests. Setting credentials for webhook Cloud-V supports webhooks which can trigger the job from external sources such as GitHub. They work in a way such that, if a specified branch is committed or if a pull request is created, the specified job build starts running depending upon the trigger event which is set in build's configuration in Cloud-V. This process requires access token of the repository CREATED BY OWNER OF REPOSITORY on which the webhook is to be set. These credentials can be safely added to Cloud-V without anyone (even administrator) seeing the passwords as follows. Obtaining github access token for repository Navigate to the dashboard of your github account and click on the your github profile picture on the top-right corner on dashboard. Then click on the \"Settings\" from the list. From the left option bar in Settings scroll down and click on \"Developer settings\". Once there, click on \"Personal access tokens\", then click on \"Fine-grained tokens\" from the dropdown list and after that click on \"Generate new token\". This will open the page for setting up new access token. Follow following steps for creating a token: Give your token a meaningful name under \"Token name\" Set expiration date in \"Expiration\" depending upon how long you would like your repository to be integrated with Cloud-V (think of a meaningful upper bound) The \"Resource owner\" should be the owner of the repository who can access all kinds of settings of the repository Under \"Repository access\", check \"Only select repositories\" and then select the repository for which you would like to create the token Under \"Permissions\" section, expand \"Repository Permissions\" and give the following two permissions: \"Read and write\" access to \"Commit statuses\" (Because after the CI has run, Cloud-V will be able to set the status of the commit accordingly) \"Read-only\" access to \"Webhooks\" Configuring repository webhook In GitHub, Go to repository settings which you want to integrate for Cloud-V. Go to Webhooks Click on Add webhook Add Payload URL as https://dash.cloud-v.co/ghprbhook/ Select content type as application/json Check Enable SSL verification In the section Which events would you like to trigger this webhook? check Let me select individual events and check Pul requests as individual events and dont check any other permission. Webhook settings will look something like this: Configurations inside Cloud-V Note: Currently users are not able to see or modify pipeline build configuration inside Jenkins, that is currently managed by administrator. Users are requested to inform administrator about how they want their pipeline configured. We will provide you with Cloud-V credentials on the provided email. Login with provided credentials. Click on the Credentials in the left menu. This will take you to the credentials page. Scroll down to the Stores scoped to Jenkins and click on the System as shown in the image. Click on Global credentials (unrestricted) . Click on Add Credentials . This will take you to the New Credentials page. Select Kind as Username with password . Select Scope as Global (Jenkins, nodes, items, all child items etc) . Enter your GitHub username in Username Enter Password as GitHub personal authentication token (PAT) which can be acquired from Github account settings. ID is optional but you can enter a unique ID . Description can be left empty. But it is recommended to give a suitable but careful description by which administrator will be able to identify and use these credentials to set up github webhook Select Create This process will look something like this Now credentials will be available in the credentials list and will be shown to you as well as administrator as shown in the image below. This will create an option in configurations for using these credentials in github webhook without changing or viewing them. Note the credentials ID (as shown in the image below) and email it to the same administrator email on which you received the login credentials for Cloud-V. It is important that administrator knows the credentials ID because they will use it in the job build configurations. Note: Please make sure to inform the administrator via email that you have added the credentials in Cloud-V Dashboard. Also, send administrator the ID of credentials via email. Requirements for administrator After the above setup is complete from software developer's side, developer will need to provide the administrator with following information. Dependencies for running the project which can be packages which are needed to install in the RISC-V CI environment by administrator. Events for triggering the job build. URL of GitHub repository. Path and name of cloud-v-pipeline file on the provided GitHub repository. Any additional information which should be given for successful execution of job builds.","title":"Getting Started"},{"location":"Software_Developer_Guide/#software-developer-guide-for-risc-v-ci","text":"A software developer is the end-user who will develop or build his/her projects on RISC-V CI infrastructure. This guide will cover all the things a software developer needs to create a project based on Cloud-V Continuous Integration (CI).","title":"Software Developer Guide for RISC-V CI"},{"location":"Software_Developer_Guide/#pre-requisites","text":"GitHub account. GitHub project repository with owner rights.","title":"Pre-requisites"},{"location":"Software_Developer_Guide/#getting-an-account-for-cloud-v","text":"Fill out this google form with all the required information for getting an account on Cloud-V. After this we will get back to you with login credentials.","title":"Getting an account for Cloud-V"},{"location":"Software_Developer_Guide/#setting-up-cloud-v-pipeline-inside-github-project-repository","text":"Cloud-V will need a cloud-v-pipeline written with jenkinsfile pipeline syntax to start execution of tests/checks (see link ). This pipeline will contain all the stages (and may be steps) of a CI/CD pipeline. This pipeline can be scripted pipeline which will only have stages or it can also be declarative pipeline which may also have steps inside stages. A simple scripted Helloworld pipeline in linux is as follows: node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } Upon execution of such a pipeline, the console output can be viewed as follows. Note: This cloud-v-pipeline should remain same in all the branches and pull requests.","title":"Setting up cloud-v-pipeline inside github project repository"},{"location":"Software_Developer_Guide/#setting-credentials-for-webhook","text":"Cloud-V supports webhooks which can trigger the job from external sources such as GitHub. They work in a way such that, if a specified branch is committed or if a pull request is created, the specified job build starts running depending upon the trigger event which is set in build's configuration in Cloud-V. This process requires access token of the repository CREATED BY OWNER OF REPOSITORY on which the webhook is to be set. These credentials can be safely added to Cloud-V without anyone (even administrator) seeing the passwords as follows.","title":"Setting credentials for webhook"},{"location":"Software_Developer_Guide/#obtaining-github-access-token-for-repository","text":"Navigate to the dashboard of your github account and click on the your github profile picture on the top-right corner on dashboard. Then click on the \"Settings\" from the list. From the left option bar in Settings scroll down and click on \"Developer settings\". Once there, click on \"Personal access tokens\", then click on \"Fine-grained tokens\" from the dropdown list and after that click on \"Generate new token\". This will open the page for setting up new access token. Follow following steps for creating a token: Give your token a meaningful name under \"Token name\" Set expiration date in \"Expiration\" depending upon how long you would like your repository to be integrated with Cloud-V (think of a meaningful upper bound) The \"Resource owner\" should be the owner of the repository who can access all kinds of settings of the repository Under \"Repository access\", check \"Only select repositories\" and then select the repository for which you would like to create the token Under \"Permissions\" section, expand \"Repository Permissions\" and give the following two permissions: \"Read and write\" access to \"Commit statuses\" (Because after the CI has run, Cloud-V will be able to set the status of the commit accordingly) \"Read-only\" access to \"Webhooks\"","title":"Obtaining github access token for repository"},{"location":"Software_Developer_Guide/#configuring-repository-webhook","text":"In GitHub, Go to repository settings which you want to integrate for Cloud-V. Go to Webhooks Click on Add webhook Add Payload URL as https://dash.cloud-v.co/ghprbhook/ Select content type as application/json Check Enable SSL verification In the section Which events would you like to trigger this webhook? check Let me select individual events and check Pul requests as individual events and dont check any other permission. Webhook settings will look something like this:","title":"Configuring repository webhook"},{"location":"Software_Developer_Guide/#configurations-inside-cloud-v","text":"Note: Currently users are not able to see or modify pipeline build configuration inside Jenkins, that is currently managed by administrator. Users are requested to inform administrator about how they want their pipeline configured. We will provide you with Cloud-V credentials on the provided email. Login with provided credentials. Click on the Credentials in the left menu. This will take you to the credentials page. Scroll down to the Stores scoped to Jenkins and click on the System as shown in the image. Click on Global credentials (unrestricted) . Click on Add Credentials . This will take you to the New Credentials page. Select Kind as Username with password . Select Scope as Global (Jenkins, nodes, items, all child items etc) . Enter your GitHub username in Username Enter Password as GitHub personal authentication token (PAT) which can be acquired from Github account settings. ID is optional but you can enter a unique ID . Description can be left empty. But it is recommended to give a suitable but careful description by which administrator will be able to identify and use these credentials to set up github webhook Select Create This process will look something like this Now credentials will be available in the credentials list and will be shown to you as well as administrator as shown in the image below. This will create an option in configurations for using these credentials in github webhook without changing or viewing them. Note the credentials ID (as shown in the image below) and email it to the same administrator email on which you received the login credentials for Cloud-V. It is important that administrator knows the credentials ID because they will use it in the job build configurations. Note: Please make sure to inform the administrator via email that you have added the credentials in Cloud-V Dashboard. Also, send administrator the ID of credentials via email.","title":"Configurations inside Cloud-V"},{"location":"Software_Developer_Guide/#requirements-for-administrator","text":"After the above setup is complete from software developer's side, developer will need to provide the administrator with following information. Dependencies for running the project which can be packages which are needed to install in the RISC-V CI environment by administrator. Events for triggering the job build. URL of GitHub repository. Path and name of cloud-v-pipeline file on the provided GitHub repository. Any additional information which should be given for successful execution of job builds.","title":"Requirements for administrator"},{"location":"Tooling/","text":"Tools on Cloud-V Using Environment Modules Users can use environment modules to load different versions of same program. For using environment modules the pattern is as follows: module load <PACKAGENAME/VERSION> Important Note: Be sure to use #!/bin/bash -l instead of #!/bin/bash in CI pipeline file since that is required for environment modules to load For example if you want to load python version 3.9.2 compiled for x86, you will need to use following command: module load python/3.9.2 For packages compiled for RISC-V architecture host, you will need to append _riscv to package name. For example, for python 3.8.15 compiled for RISC-V, following command will be used. module load python_riscv/3.8.15","title":"Using Environment Modules"},{"location":"Tooling/#tools-on-cloud-v","text":"","title":"Tools on Cloud-V"},{"location":"Tooling/#using-environment-modules","text":"Users can use environment modules to load different versions of same program. For using environment modules the pattern is as follows: module load <PACKAGENAME/VERSION> Important Note: Be sure to use #!/bin/bash -l instead of #!/bin/bash in CI pipeline file since that is required for environment modules to load For example if you want to load python version 3.9.2 compiled for x86, you will need to use following command: module load python/3.9.2 For packages compiled for RISC-V architecture host, you will need to append _riscv to package name. For example, for python 3.8.15 compiled for RISC-V, following command will be used. module load python_riscv/3.8.15","title":"Using Environment Modules"},{"location":"jenkins_gitlab_integration/","text":"Integrating GitLab with Jenkins This documentation will cover how to create an integration between jenkins and GitLab. This will allow users to trigger jenkins job when a merge request or a push is detected in GitLab. Pre-requisites GitLab plugin Git plugin GitLab repository with owner's credentials Configuring Jenkins System First jenkins needs to be configured. Go to Dashboard > Manage Jenkins > Configure System Scroll down to Gitlab section Check Enable authentication for '/project' end-point Enter a Connection name . Enter Gitlab host URL as https://gitlab.com/ . In case there is a different domain name, then enter there instead of above url. In Credentials , click on Add then click on Jenkins . In Kind , select GitLab API token . In API token , enter the gitlab personal access token (this will be obtained below while configuring GitLab). Click on Advanced . Click on Test Connection . If everything goes right, it should print success . Configuring GitLab Click on profile avatar in the top right. Click on Edit profile . Click on Access Tokens . Create a new personal access token and copy it (this is the GitLab API token used in above section Configuring Jenkins System ). Go to repository settings. On left-side pane, select Webhooks . Enter GitLab webhook URL (this is explained below in next section). Enter Secret Token (this is explained in the below section). Check desirable trigger options. Click Add webhook . Configuring Jenkins Job Create a jenkins job. On job configuration page, scroll down to Source Code Management . Select Git . In Credentials , add the owner credentials of GitLab repository. This will be Username and Password . Select the appropriate branch (generally it is main ). Scroll down to Build Triggers . Check Build when a change is pushed to GitLab . There will also be a GitLab webhook URL . This is needed in GitLab. This URL will be called as Webhook URL . Click on Advanced in the same option, then scroll down and generate a secret token. This token is also needed. This token will be called as Secret Token . Scroll down to Post-build Actions and select Publish build status to GitLab . Click on Apply and Save . Now whenever there will be a push (or whatever build trigger option is set in jenkins and gitlab webhook), specified jenkins job will be triggered.","title":"Integrating GitLab with Jenkins"},{"location":"jenkins_gitlab_integration/#integrating-gitlab-with-jenkins","text":"This documentation will cover how to create an integration between jenkins and GitLab. This will allow users to trigger jenkins job when a merge request or a push is detected in GitLab.","title":"Integrating GitLab with Jenkins"},{"location":"jenkins_gitlab_integration/#pre-requisites","text":"GitLab plugin Git plugin GitLab repository with owner's credentials","title":"Pre-requisites"},{"location":"jenkins_gitlab_integration/#configuring-jenkins-system","text":"First jenkins needs to be configured. Go to Dashboard > Manage Jenkins > Configure System Scroll down to Gitlab section Check Enable authentication for '/project' end-point Enter a Connection name . Enter Gitlab host URL as https://gitlab.com/ . In case there is a different domain name, then enter there instead of above url. In Credentials , click on Add then click on Jenkins . In Kind , select GitLab API token . In API token , enter the gitlab personal access token (this will be obtained below while configuring GitLab). Click on Advanced . Click on Test Connection . If everything goes right, it should print success .","title":"Configuring Jenkins System"},{"location":"jenkins_gitlab_integration/#configuring-gitlab","text":"Click on profile avatar in the top right. Click on Edit profile . Click on Access Tokens . Create a new personal access token and copy it (this is the GitLab API token used in above section Configuring Jenkins System ). Go to repository settings. On left-side pane, select Webhooks . Enter GitLab webhook URL (this is explained below in next section). Enter Secret Token (this is explained in the below section). Check desirable trigger options. Click Add webhook .","title":"Configuring GitLab"},{"location":"jenkins_gitlab_integration/#configuring-jenkins-job","text":"Create a jenkins job. On job configuration page, scroll down to Source Code Management . Select Git . In Credentials , add the owner credentials of GitLab repository. This will be Username and Password . Select the appropriate branch (generally it is main ). Scroll down to Build Triggers . Check Build when a change is pushed to GitLab . There will also be a GitLab webhook URL . This is needed in GitLab. This URL will be called as Webhook URL . Click on Advanced in the same option, then scroll down and generate a secret token. This token is also needed. This token will be called as Secret Token . Scroll down to Post-build Actions and select Publish build status to GitLab . Click on Apply and Save . Now whenever there will be a push (or whatever build trigger option is set in jenkins and gitlab webhook), specified jenkins job will be triggered.","title":"Configuring Jenkins Job"},{"location":"runner_specs/","text":"Specifications of compute instances in Cloud-V This document contains the specifications of the compute instances available for users to run builds in Cloud-V. The term \"Compute Instance\", can also be safely interchanged with the terms \"Build Executor\" and \"Runner\". Name String Architecture Cores Memory Compute Instance Type J-x86-1 (or) J-QMU-1 x86_64 4 8GiB Hardware with application-level emulator J-TESTVM-1 x86_64 4 8GiB Hardware J-RASP4-1 aarch64 4 4GiB Hardware J-QMS-1 riscv64 2 2GiB QEMU System emulator J-VF1-1 riscv64 2 8GiB Hardware J-VF1-2 riscv64 2 8GiB Hardware J-VF1-3 riscv64 2 8GiB Hardware J-VF2-1 riscv64 4 8GiB Hardware J-VF2-2 riscv64 4 8GiB Hardware J-VF2-3 riscv64 4 8GiB Hardware J-VF2-4 riscv64 4 8GiB Hardware J-VF2-5 riscv64 4 8GiB Hardware J-VF2-6 riscv64 4 8GiB Hardware J-HF-1 riscv64 4 8GiB Hardware Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"Compute Instance Specifications"},{"location":"runner_specs/#specifications-of-compute-instances-in-cloud-v","text":"This document contains the specifications of the compute instances available for users to run builds in Cloud-V. The term \"Compute Instance\", can also be safely interchanged with the terms \"Build Executor\" and \"Runner\". Name String Architecture Cores Memory Compute Instance Type J-x86-1 (or) J-QMU-1 x86_64 4 8GiB Hardware with application-level emulator J-TESTVM-1 x86_64 4 8GiB Hardware J-RASP4-1 aarch64 4 4GiB Hardware J-QMS-1 riscv64 2 2GiB QEMU System emulator J-VF1-1 riscv64 2 8GiB Hardware J-VF1-2 riscv64 2 8GiB Hardware J-VF1-3 riscv64 2 8GiB Hardware J-VF2-1 riscv64 4 8GiB Hardware J-VF2-2 riscv64 4 8GiB Hardware J-VF2-3 riscv64 4 8GiB Hardware J-VF2-4 riscv64 4 8GiB Hardware J-VF2-5 riscv64 4 8GiB Hardware J-VF2-6 riscv64 4 8GiB Hardware J-HF-1 riscv64 4 8GiB Hardware Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"Specifications of compute instances in Cloud-V"},{"location":"tooling_J-HF-1/","text":"Tools on J-HF-1 node This compute instance is Sifive's HiFive Unleased board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 20.04.6 (Focal Fossa) Tool Version Installed from Git 2.25.1 apt OpenJDK 11.0.20.1 apt GCC 10.5.0 apt Python3 3.8.10 apt OpenSSL 1.1.1f apt Ruby 2.7.0p0 apt Go 1.14.3 apt rustc 1.41.0 apt Flex 2.6.4 apt Ninja 1.10.0 apt Bison 3.5.1 apt autoconf 2.69 apt gperf 3.1 apt cmake 3.16.3 apt make 4.2.1 apt automake 1.16.1 apt gfortran 9.4.0 apt openssh-server 8.2p1 apt","title":"J-HF-1"},{"location":"tooling_J-HF-1/#tools-on-j-hf-1-node","text":"This compute instance is Sifive's HiFive Unleased board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 20.04.6 (Focal Fossa) Tool Version Installed from Git 2.25.1 apt OpenJDK 11.0.20.1 apt GCC 10.5.0 apt Python3 3.8.10 apt OpenSSL 1.1.1f apt Ruby 2.7.0p0 apt Go 1.14.3 apt rustc 1.41.0 apt Flex 2.6.4 apt Ninja 1.10.0 apt Bison 3.5.1 apt autoconf 2.69 apt gperf 3.1 apt cmake 3.16.3 apt make 4.2.1 apt automake 1.16.1 apt gfortran 9.4.0 apt openssh-server 8.2p1 apt","title":"Tools on J-HF-1 node"},{"location":"tooling_J-QMS-1/","text":"Tools on J-QMS-1 node This is QEMU system compute instance with 64-bit RISC-V Linux and it has all the packages ONLY for RISC-V architecture Operating System: Ubuntu 22.04.4 LTS (Jammy Jellyfish) QEMU Linux Version: 7.2.90 (v9.0.0-rc0-68-g853546f812) Tool Version Installed from pip 22.0.2 apt Git 2.34.1 apt OpenJDK 19.0.1 apt GCC 11.4.0 apt Python3 3.10.12 apt OpenSSL 3.0.2 apt Ruby 3.0.2p107 apt Go 1.18.8 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.10.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt make 4.3 apt cmake 3.22.1 apt","title":"J-QMS-1"},{"location":"tooling_J-QMS-1/#tools-on-j-qms-1-node","text":"This is QEMU system compute instance with 64-bit RISC-V Linux and it has all the packages ONLY for RISC-V architecture Operating System: Ubuntu 22.04.4 LTS (Jammy Jellyfish) QEMU Linux Version: 7.2.90 (v9.0.0-rc0-68-g853546f812) Tool Version Installed from pip 22.0.2 apt Git 2.34.1 apt OpenJDK 19.0.1 apt GCC 11.4.0 apt Python3 3.10.12 apt OpenSSL 3.0.2 apt Ruby 3.0.2p107 apt Go 1.18.8 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.10.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt make 4.3 apt cmake 3.22.1 apt","title":"Tools on J-QMS-1 node"},{"location":"tooling_J-QMU-1J-VM-1/","text":"Tools on J-x86-1 or J-QMU-1 node Tools which are mentioned for x86 architecture are able to run on J-x86-1 . Tools which are mentioned for RISC-V architecture are able to run on J-QMU-1 . The packages which are supported for QEMU User mode can be used by normal commands once they are loaded. Here PACKAGE_NAME is the package which you want to run on QEMU user mode. Operating System: Debian 11 (bullseye) QEMU User Mode Version: Different Versions (see the table below) Tooling available for J-x86-1 The tools available for J-x86-1 is for use on x86 architecture and these tools do not support execution on RISC-V architecture Tool Versions Installed from Host Architecture Environment Modules Support Git 2.3.0.2 source x86 N/A OpenJDK 19.0.1 apt x86 N/A GCC 10.4.0, 12.2.0 apt x86 Yes Python3 3.8.15, 3.9.2 source x86 Yes Go 1.18.8 apt x86 N/A rustc 1.65.0 source x86 N/A Flex 2.6.4 apt x86 N/A Ninja 1.10.1-1 apt x86 N/A Bison 3.7.5 apt x86 N/A autoconf 2.69 apt x86 N/A gperf 2.2.4 apt x86 N/A spike 1.1.1-dev source x86 Yes Verilator 4.038 apt x86 N/A Sail (riscv_sim_RV64, riscv_sim_RV32) 0.5 source x86 Yes cmake 3.18.4 apt x86 N/A make 4.3 apt x86 N/A ARM EABI GNU toolchain 13.2.Rel1 source x86 Yes qemu-system-arm 8.2.2 source x86 Yes SCons 4.7.0 source x86 Yes Tooling available for J-QMU-1 The tools available for J-QMU-1 is for use on RISC-V architecture and these tools do not support execution on x86 architecture Tool Versions Installed from Host Architecture Environment Modules Support Python3 3.8.15 source RISC-V Yes zlib 1.2.13 source RISC-V N/A OpenSSL 1.1.1r source RISC-V Yes Ruby (without IRB) 3.2.0dev source RISC-V Yes rustc 1.65.0 source RISC-V N/A Flex 2.6.4 source RISC-V yes Ninja 1.12.0.git source RISC-V Yes Bison 3.8.2, 2.3 source RISC-V Yes clang 16.0.0 source RISC-V (cross compiler) Yes riscv-pk 1.0.0-91-g573c858 source RISC-V Yes QEMU User mode and RISC-V GNU Cross compilers From now on RISC-V cross-compilers can only be loaded with their respective QEMU User mode on Cloud-V. This is configured so that there is no confusion between toolchain version and qemu user mode being used because both of these will be \"generally\" taken from the latest releases of nightly builds. Loading a certain RISC-V toolchain using environment modules will automatically load the respective qemu usermode version unless otherwise specified. The loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-glibc/<release-date> And the loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-elf/<release-date> Following table provides relevant information about version of the toolchain and the respective QEMU User mode version (where the release date is mentioned in pattern MMDDYYYY ). Release date GNU Toolchain version (elf and glibc) QEMU Version 03012024 13.2.0 8.2.1 02022024 13.2.0 8.2.1 02022024 13.2.0 8.1.1 Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"J-x86-1 or J-QMU-1"},{"location":"tooling_J-QMU-1J-VM-1/#tools-on-j-x86-1-or-j-qmu-1-node","text":"Tools which are mentioned for x86 architecture are able to run on J-x86-1 . Tools which are mentioned for RISC-V architecture are able to run on J-QMU-1 . The packages which are supported for QEMU User mode can be used by normal commands once they are loaded. Here PACKAGE_NAME is the package which you want to run on QEMU user mode. Operating System: Debian 11 (bullseye) QEMU User Mode Version: Different Versions (see the table below)","title":"Tools on J-x86-1 or J-QMU-1 node"},{"location":"tooling_J-QMU-1J-VM-1/#tooling-available-for-j-x86-1","text":"The tools available for J-x86-1 is for use on x86 architecture and these tools do not support execution on RISC-V architecture Tool Versions Installed from Host Architecture Environment Modules Support Git 2.3.0.2 source x86 N/A OpenJDK 19.0.1 apt x86 N/A GCC 10.4.0, 12.2.0 apt x86 Yes Python3 3.8.15, 3.9.2 source x86 Yes Go 1.18.8 apt x86 N/A rustc 1.65.0 source x86 N/A Flex 2.6.4 apt x86 N/A Ninja 1.10.1-1 apt x86 N/A Bison 3.7.5 apt x86 N/A autoconf 2.69 apt x86 N/A gperf 2.2.4 apt x86 N/A spike 1.1.1-dev source x86 Yes Verilator 4.038 apt x86 N/A Sail (riscv_sim_RV64, riscv_sim_RV32) 0.5 source x86 Yes cmake 3.18.4 apt x86 N/A make 4.3 apt x86 N/A ARM EABI GNU toolchain 13.2.Rel1 source x86 Yes qemu-system-arm 8.2.2 source x86 Yes SCons 4.7.0 source x86 Yes","title":"Tooling available for J-x86-1"},{"location":"tooling_J-QMU-1J-VM-1/#tooling-available-for-j-qmu-1","text":"The tools available for J-QMU-1 is for use on RISC-V architecture and these tools do not support execution on x86 architecture Tool Versions Installed from Host Architecture Environment Modules Support Python3 3.8.15 source RISC-V Yes zlib 1.2.13 source RISC-V N/A OpenSSL 1.1.1r source RISC-V Yes Ruby (without IRB) 3.2.0dev source RISC-V Yes rustc 1.65.0 source RISC-V N/A Flex 2.6.4 source RISC-V yes Ninja 1.12.0.git source RISC-V Yes Bison 3.8.2, 2.3 source RISC-V Yes clang 16.0.0 source RISC-V (cross compiler) Yes riscv-pk 1.0.0-91-g573c858 source RISC-V Yes","title":"Tooling available for J-QMU-1"},{"location":"tooling_J-QMU-1J-VM-1/#qemu-user-mode-and-risc-v-gnu-cross-compilers","text":"From now on RISC-V cross-compilers can only be loaded with their respective QEMU User mode on Cloud-V. This is configured so that there is no confusion between toolchain version and qemu user mode being used because both of these will be \"generally\" taken from the latest releases of nightly builds. Loading a certain RISC-V toolchain using environment modules will automatically load the respective qemu usermode version unless otherwise specified. The loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-glibc/<release-date> And the loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-elf/<release-date> Following table provides relevant information about version of the toolchain and the respective QEMU User mode version (where the release date is mentioned in pattern MMDDYYYY ). Release date GNU Toolchain version (elf and glibc) QEMU Version 03012024 13.2.0 8.2.1 02022024 13.2.0 8.2.1 02022024 13.2.0 8.1.1 Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"QEMU User mode and RISC-V GNU Cross compilers"},{"location":"tooling_J-VF1-x/","text":"Tools on J-VF1-x node This compute instance is Starfive's VisionFive 1 board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 23.04 (Lunar Lobster) Tool Version Installed from Git 2.39.2 apt OpenJDK 21-ea apt GCC 13.1.0 apt Python3 3.11.4 apt OpenSSL 3.0.8 apt Ruby 3.1.2p20 apt Go 1.20.3 apt rustc 1.67.1 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.25.1 apt make 4.3 apt automake 1.16.5 apt gfortran 13.1.0 apt openssh-server 9.0p1 apt","title":"J-VF1-x"},{"location":"tooling_J-VF1-x/#tools-on-j-vf1-x-node","text":"This compute instance is Starfive's VisionFive 1 board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 23.04 (Lunar Lobster) Tool Version Installed from Git 2.39.2 apt OpenJDK 21-ea apt GCC 13.1.0 apt Python3 3.11.4 apt OpenSSL 3.0.8 apt Ruby 3.1.2p20 apt Go 1.20.3 apt rustc 1.67.1 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.25.1 apt make 4.3 apt automake 1.16.5 apt gfortran 13.1.0 apt openssh-server 9.0p1 apt","title":"Tools on J-VF1-x node"},{"location":"tooling_J-VF2-x/","text":"Tools on J-VF2-x node This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.43.0 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.7 apt OpenSSL 3.1.5 apt Ruby 3.1.2p20 apt Go 1.22.0 apt rustc 1.70.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.28.3 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.6p1 apt vim 9.1 apt","title":"J-VF2-x"},{"location":"tooling_J-VF2-x/#tools-on-j-vf2-x-node","text":"This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.43.0 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.7 apt OpenSSL 3.1.5 apt Ruby 3.1.2p20 apt Go 1.22.0 apt rustc 1.70.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.28.3 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.6p1 apt vim 9.1 apt","title":"Tools on J-VF2-x node"}]}
\ No newline at end of file
+{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"Cloud-V Documentation This documentation lists the tooling and necessary information to use Cloud-V for RISC-V application development on RISC-V compute instances provided by Cloud-V Overview Slides: link Youtube Channel: youtube.com/@Cloud-V","title":"Home"},{"location":"#cloud-v-documentation","text":"This documentation lists the tooling and necessary information to use Cloud-V for RISC-V application development on RISC-V compute instances provided by Cloud-V Overview Slides: link Youtube Channel: youtube.com/@Cloud-V","title":"Cloud-V Documentation"},{"location":"Creating_CI_CD_pipeline/","text":"Creating a CI/CD pipeline in Jenkins Pre Requisistes For sake of this documentation, jenkins built-in sample script is used to create and execute a cd/cd pipeline in jenkins. In the built-in script maven is used as M3, so one must install Maven plugin inside jenkins and name it M3 . Usually maven is already present inside jenkins and can be configured from Global Configuration Tools . Following steps demonstrate configuring Maven plugin. Go to Jenkins Dashboard and click on Manage Jenkins In Manage Jenkins , under System Configuration section, click on Global Tool Configuration . In Global Tool Configuration , scroll down to Maven section and click on the respective option under the Maven Section (should be Maven installations\u2026 or Add Maven ). Under Maven installations , enter M3 in \u201cname\u201d text box, check Install Automatically and select Version greater than 3, then click Apply and Save . This should install Maven version 3 and configure as M3 . Steps for Jenkins pipeline creation After installing Jenkins and having all the suggested plugins installed, go to Jenkins dashboard and click on Create Job . On the next page, give your pipeline a name, select Pipeline and click OK . A Configuration page for the pipeline will appear. Select Build Triggers options and General options according to need and scroll down to the Pipeline section. Definition section contains configuration for stages and steps of the pipeline. Under Definition section, you can either choose Pipeline script and try writing your own script or try some sample pipeline (like Hello World , Github+Maven etc) or you could select Pipeline script from SCM and give a github repository containing configurations of Pipeline. Press Save and Apply . This should take you to the Pipeline and you can build the pipeline and if no unresolved dependencies are present, the pipeline should build without any error.","title":"Creating a CI/CD pipeline in Jenkins"},{"location":"Creating_CI_CD_pipeline/#creating-a-cicd-pipeline-in-jenkins","text":"","title":"Creating a CI/CD pipeline in Jenkins"},{"location":"Creating_CI_CD_pipeline/#pre-requisistes","text":"For sake of this documentation, jenkins built-in sample script is used to create and execute a cd/cd pipeline in jenkins. In the built-in script maven is used as M3, so one must install Maven plugin inside jenkins and name it M3 . Usually maven is already present inside jenkins and can be configured from Global Configuration Tools . Following steps demonstrate configuring Maven plugin. Go to Jenkins Dashboard and click on Manage Jenkins In Manage Jenkins , under System Configuration section, click on Global Tool Configuration . In Global Tool Configuration , scroll down to Maven section and click on the respective option under the Maven Section (should be Maven installations\u2026 or Add Maven ). Under Maven installations , enter M3 in \u201cname\u201d text box, check Install Automatically and select Version greater than 3, then click Apply and Save . This should install Maven version 3 and configure as M3 .","title":"Pre Requisistes"},{"location":"Creating_CI_CD_pipeline/#steps-for-jenkins-pipeline-creation","text":"After installing Jenkins and having all the suggested plugins installed, go to Jenkins dashboard and click on Create Job . On the next page, give your pipeline a name, select Pipeline and click OK . A Configuration page for the pipeline will appear. Select Build Triggers options and General options according to need and scroll down to the Pipeline section. Definition section contains configuration for stages and steps of the pipeline. Under Definition section, you can either choose Pipeline script and try writing your own script or try some sample pipeline (like Hello World , Github+Maven etc) or you could select Pipeline script from SCM and give a github repository containing configurations of Pipeline. Press Save and Apply . This should take you to the Pipeline and you can build the pipeline and if no unresolved dependencies are present, the pipeline should build without any error.","title":"Steps for Jenkins pipeline creation"},{"location":"Creating_jenkinsfile/","text":"Creating a Cloud-V CI Pipeline file What is a Cloud-V CI Pipeline file A cloud-v-pipeline file is a Continuous Integration (CI) jenkins pipeline script which is written in Groovy. It describes various stages (and possibly steps) which are executed in the defined pattern. These stages can be written in bash or they can be written in Groovy itself. Mainly there can be two types of Cloud-V pipeline files are of two types: Scripted: Only contains stages Declarative: Contains stages as well as steps (more feature-rich and recommended) This documentation will cover how to create a cloud-v-pipeline file with bash script inside it and run it on various compute instances (which are known as Nodes in jenkins). Jenkins Node In jenkins, node represents a compute instance. In simple words, it is the platform on which our job build is going to run. Jenkins Master There is a jenkins Master node which is actually the compute instance on which Jenkins is installed. It is the node which schedules builds on runners. For security reason, no job is allowed to run on this node. Jenkins Slave Jenkins slave nodes are the compute instances on which our job builds run safely. They may be attached with jenkins master via hardware or they may be connected through remote SSH connection. cloud-v-pipeline file written with bash Simple Hello World cloud-v-pipeline file In Cloud-V, all the platforms are running Linux operating system, so the cloud-v-pipeline should be written in bash. Following script is an example of how can we run a bash script in scripted cloud-v-pipeline . node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } The keyword sh is used to specify a shell script As there is nothing mentioned with node , so the script will run job build on any available compute instance. cloud-v-pipeline for a Specific Node In previous script, the cloud-v-pipeline would run on any compute instances which are available. But in case if someone wants to run a job build on specific node, then a compute instance name must be specified with keyword node . The following script is an example of running above Hello World program on node named hifive_unleashed . node('hifive_unleashed'){ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } cloud-v-pipeline for Cross-Platform Compilation and Execution Cloud-V supports cross-compilation and execution on emulated RISC-V compute instances. Following tools help in cross compilation and cross-platfrom execution: RISC-V GNU Toolchain QEMU user mode (for running standalone binaries) QEMU System (for running application in Linux) An example pipeline script is given below in scripted pipeline. node('x86_runner2'){ checkout scm //Getting content of this repo stage('*** Compilation Phase ***') { // for display purposes //Compiling helloworld.c using bash commands sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out //Cross compiling for RISC-V ''' } stage (' *** Running Binaries ***'){ sh '''#!/bin/bash ./helloworld.out qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out //Running executable on RISC-V emulated platform ''' } } The equivalent declarative pipeline is as follows: pipeline { agent {label \"x86_runner2\"} stages { stage('Clone Repository') { steps('delegate'){ checkout scm //Clones the repository on the local machine } } stage ('Compilation Phase'){ steps{ sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out ''' sh '''#!/bin/bash riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out ''' } } stage ('Running Binaries'){ steps { sh ''' #!/bin/bash ./helloworld.out ''' sh'''#!/bin/bash qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out ''' } } } } Reference Links https://www.jenkins.io/doc/book/pipeline/syntax/","title":"Creating a CI pipeline file"},{"location":"Creating_jenkinsfile/#creating-a-cloud-v-ci-pipeline-file","text":"","title":"Creating a Cloud-V CI Pipeline file"},{"location":"Creating_jenkinsfile/#what-is-a-cloud-v-ci-pipeline-file","text":"A cloud-v-pipeline file is a Continuous Integration (CI) jenkins pipeline script which is written in Groovy. It describes various stages (and possibly steps) which are executed in the defined pattern. These stages can be written in bash or they can be written in Groovy itself. Mainly there can be two types of Cloud-V pipeline files are of two types: Scripted: Only contains stages Declarative: Contains stages as well as steps (more feature-rich and recommended) This documentation will cover how to create a cloud-v-pipeline file with bash script inside it and run it on various compute instances (which are known as Nodes in jenkins).","title":"What is a Cloud-V CI Pipeline file"},{"location":"Creating_jenkinsfile/#jenkins-node","text":"In jenkins, node represents a compute instance. In simple words, it is the platform on which our job build is going to run.","title":"Jenkins Node"},{"location":"Creating_jenkinsfile/#jenkins-master","text":"There is a jenkins Master node which is actually the compute instance on which Jenkins is installed. It is the node which schedules builds on runners. For security reason, no job is allowed to run on this node.","title":"Jenkins Master"},{"location":"Creating_jenkinsfile/#jenkins-slave","text":"Jenkins slave nodes are the compute instances on which our job builds run safely. They may be attached with jenkins master via hardware or they may be connected through remote SSH connection.","title":"Jenkins Slave"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-file-written-with-bash","text":"","title":"cloud-v-pipeline file written with bash"},{"location":"Creating_jenkinsfile/#simple-hello-world-cloud-v-pipeline-file","text":"In Cloud-V, all the platforms are running Linux operating system, so the cloud-v-pipeline should be written in bash. Following script is an example of how can we run a bash script in scripted cloud-v-pipeline . node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } The keyword sh is used to specify a shell script As there is nothing mentioned with node , so the script will run job build on any available compute instance.","title":"Simple Hello World cloud-v-pipeline file"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-for-a-specific-node","text":"In previous script, the cloud-v-pipeline would run on any compute instances which are available. But in case if someone wants to run a job build on specific node, then a compute instance name must be specified with keyword node . The following script is an example of running above Hello World program on node named hifive_unleashed . node('hifive_unleashed'){ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } }","title":"cloud-v-pipeline for a Specific Node"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-for-cross-platform-compilation-and-execution","text":"Cloud-V supports cross-compilation and execution on emulated RISC-V compute instances. Following tools help in cross compilation and cross-platfrom execution: RISC-V GNU Toolchain QEMU user mode (for running standalone binaries) QEMU System (for running application in Linux) An example pipeline script is given below in scripted pipeline. node('x86_runner2'){ checkout scm //Getting content of this repo stage('*** Compilation Phase ***') { // for display purposes //Compiling helloworld.c using bash commands sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out //Cross compiling for RISC-V ''' } stage (' *** Running Binaries ***'){ sh '''#!/bin/bash ./helloworld.out qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out //Running executable on RISC-V emulated platform ''' } } The equivalent declarative pipeline is as follows: pipeline { agent {label \"x86_runner2\"} stages { stage('Clone Repository') { steps('delegate'){ checkout scm //Clones the repository on the local machine } } stage ('Compilation Phase'){ steps{ sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out ''' sh '''#!/bin/bash riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out ''' } } stage ('Running Binaries'){ steps { sh ''' #!/bin/bash ./helloworld.out ''' sh'''#!/bin/bash qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out ''' } } } }","title":"cloud-v-pipeline for Cross-Platform Compilation and Execution"},{"location":"Creating_jenkinsfile/#reference-links","text":"https://www.jenkins.io/doc/book/pipeline/syntax/","title":"Reference Links"},{"location":"Multinode_Pipelines/","text":"Multinode Pipelines One can create multinode pipelines in jenkins freestyle pipeline job as well as in jenkins native pipeline job. In such a pipeline, different stages of the pipeline can run on separate nodes. The jenkins native pipeline job can have two types. Scripted Pipeline Declarative pipeline For the sake of this documentation, two nodes are used: container-node and container-node2 Label In jenkins, label specifies where the job or a stage of the job can run. In jenkins, a label can be explicitly added in the node's configuration so that each time that label is mentioned in a jenkins job, that specific node is used for building the job, or the name of the node can also be used as label in case if no label is added in the node. Creating multinode pipelines in Jenkins native pipeline job Scripted Pipeline For creating a multinode pipeline with jenkins native scripted pipeline job, jenkinsfile can be tweaked. The keyword node can be used to specify the node in which the stages are going to run and this keyword can also be used in between stages. Following screenshot indicates a code in which first stage runs on node named container-node . While the second node runs on node named container-node2 . node ('container-node') { stage ('*** Creating a directory in container-node ***'){ sh '''#!/bin/bash mkdir newdir_container-node-$RANDOM ''' } stage ('*** Creating a directory in container-node2'){ node ('container-node2'){ sh'''#!/bin/bash mkdir newdir_container-node2-$RANDOM ''' } } } Declarative pipeline For a declarative pipeline the keyword label can be used in the agent block. This can either be done at the start of the pipeline after the keyword pipeline or it can be used inside the stages. The following code builds two stages each of which is built in separate node. The keyword none with agent means that the agent is not specified globally for each stage and it should be specified inside each stage. pipeline { agent none // Means no agent specified. This means each node will specify its own agent stages { stage('container-node') { agent{ label \"container-node\" //Selecting container-node for this stage } steps { sh '''#!/bin/bash echo 'Hello container-node' mkdir \"newdir-container-node-$RANDOM\" ''' } } stage('container-node2'){ agent{ label \"container-node2\" //Selecting container-node2 for this stage } steps{ sh'''#!/bin/bash echo ''Hello container-node2 mkdir \"newdir-container-node2-$RANDOM\" ''' } } } } Creating multinode pipelines using Jenkins freestyle jobs Jenkins freestyle jobs can be combined together by mentioning post-build jobs in the freestyle job settings. Freestyle jobs are customizable and offer more options than jenkins native pipeline jobs. Each job represents a stage and each stage has separate settings. One can use jenkins freestyle jobs to run on a separate node by selecting the option Restrict where this project can be run in the General section of the job's configuration. In the Label Expression , the node's name can be mentioned in which to run the job. The following image shows the option from job's configuration. This can be done in all the job's configuration for the specified node.","title":"Multinode Pipelines"},{"location":"Multinode_Pipelines/#multinode-pipelines","text":"One can create multinode pipelines in jenkins freestyle pipeline job as well as in jenkins native pipeline job. In such a pipeline, different stages of the pipeline can run on separate nodes. The jenkins native pipeline job can have two types. Scripted Pipeline Declarative pipeline For the sake of this documentation, two nodes are used: container-node and container-node2","title":"Multinode Pipelines"},{"location":"Multinode_Pipelines/#label","text":"In jenkins, label specifies where the job or a stage of the job can run. In jenkins, a label can be explicitly added in the node's configuration so that each time that label is mentioned in a jenkins job, that specific node is used for building the job, or the name of the node can also be used as label in case if no label is added in the node.","title":"Label"},{"location":"Multinode_Pipelines/#creating-multinode-pipelines-in-jenkins-native-pipeline-job","text":"","title":"Creating multinode pipelines in Jenkins native pipeline job"},{"location":"Multinode_Pipelines/#scripted-pipeline","text":"For creating a multinode pipeline with jenkins native scripted pipeline job, jenkinsfile can be tweaked. The keyword node can be used to specify the node in which the stages are going to run and this keyword can also be used in between stages. Following screenshot indicates a code in which first stage runs on node named container-node . While the second node runs on node named container-node2 . node ('container-node') { stage ('*** Creating a directory in container-node ***'){ sh '''#!/bin/bash mkdir newdir_container-node-$RANDOM ''' } stage ('*** Creating a directory in container-node2'){ node ('container-node2'){ sh'''#!/bin/bash mkdir newdir_container-node2-$RANDOM ''' } } }","title":"Scripted Pipeline"},{"location":"Multinode_Pipelines/#declarative-pipeline","text":"For a declarative pipeline the keyword label can be used in the agent block. This can either be done at the start of the pipeline after the keyword pipeline or it can be used inside the stages. The following code builds two stages each of which is built in separate node. The keyword none with agent means that the agent is not specified globally for each stage and it should be specified inside each stage. pipeline { agent none // Means no agent specified. This means each node will specify its own agent stages { stage('container-node') { agent{ label \"container-node\" //Selecting container-node for this stage } steps { sh '''#!/bin/bash echo 'Hello container-node' mkdir \"newdir-container-node-$RANDOM\" ''' } } stage('container-node2'){ agent{ label \"container-node2\" //Selecting container-node2 for this stage } steps{ sh'''#!/bin/bash echo ''Hello container-node2 mkdir \"newdir-container-node2-$RANDOM\" ''' } } } }","title":"Declarative pipeline"},{"location":"Multinode_Pipelines/#creating-multinode-pipelines-using-jenkins-freestyle-jobs","text":"Jenkins freestyle jobs can be combined together by mentioning post-build jobs in the freestyle job settings. Freestyle jobs are customizable and offer more options than jenkins native pipeline jobs. Each job represents a stage and each stage has separate settings. One can use jenkins freestyle jobs to run on a separate node by selecting the option Restrict where this project can be run in the General section of the job's configuration. In the Label Expression , the node's name can be mentioned in which to run the job. The following image shows the option from job's configuration. This can be done in all the job's configuration for the specified node.","title":"Creating multinode pipelines using Jenkins freestyle jobs"},{"location":"Software_Developer_Guide/","text":"Software Developer Guide for RISC-V CI A software developer is the end-user who will develop or build his/her projects on RISC-V CI infrastructure. This guide will cover all the things a software developer needs to create a project based on Cloud-V Continuous Integration (CI). Pre-requisites GitHub account. GitHub project repository with owner rights. Getting an account for Cloud-V Fill out this google form with all the required information for getting an account on Cloud-V. After this we will get back to you with login credentials. Setting up cloud-v-pipeline inside github project repository Cloud-V will need a cloud-v-pipeline written with jenkinsfile pipeline syntax to start execution of tests/checks (see link ). This pipeline will contain all the stages (and may be steps) of a CI/CD pipeline. This pipeline can be scripted pipeline which will only have stages or it can also be declarative pipeline which may also have steps inside stages. A simple scripted Helloworld pipeline in linux is as follows: node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } Upon execution of such a pipeline, the console output can be viewed as follows. Note: This cloud-v-pipeline should remain same in all the branches and pull requests. Setting credentials for webhook Cloud-V supports webhooks which can trigger the job from external sources such as GitHub. They work in a way such that, if a specified branch is committed or if a pull request is created, the specified job build starts running depending upon the trigger event which is set in build's configuration in Cloud-V. This process requires access token of the repository CREATED BY OWNER OF REPOSITORY on which the webhook is to be set. These credentials can be safely added to Cloud-V without anyone (even administrator) seeing the passwords as follows. Obtaining github access token for repository Navigate to the dashboard of your github account and click on the your github profile picture on the top-right corner on dashboard. Then click on the \"Settings\" from the list. From the left option bar in Settings scroll down and click on \"Developer settings\". Once there, click on \"Personal access tokens\", then click on \"Fine-grained tokens\" from the dropdown list and after that click on \"Generate new token\". This will open the page for setting up new access token. Follow following steps for creating a token: Give your token a meaningful name under \"Token name\" Set expiration date in \"Expiration\" depending upon how long you would like your repository to be integrated with Cloud-V (think of a meaningful upper bound) The \"Resource owner\" should be the owner of the repository who can access all kinds of settings of the repository Under \"Repository access\", check \"Only select repositories\" and then select the repository for which you would like to create the token Under \"Permissions\" section, expand \"Repository Permissions\" and give the following two permissions: \"Read and write\" access to \"Commit statuses\" (Because after the CI has run, Cloud-V will be able to set the status of the commit accordingly) \"Read-only\" access to \"Webhooks\" Configuring repository webhook In GitHub, Go to repository settings which you want to integrate for Cloud-V. Go to Webhooks Click on Add webhook Add Payload URL as https://dash.cloud-v.co/ghprbhook/ Select content type as application/json Check Enable SSL verification In the section Which events would you like to trigger this webhook? check Let me select individual events and check Pul requests as individual events and dont check any other permission. Webhook settings will look something like this: Configurations inside Cloud-V Note: Currently users are not able to see or modify pipeline build configuration inside Jenkins, that is currently managed by administrator. Users are requested to inform administrator about how they want their pipeline configured. We will provide you with Cloud-V credentials on the provided email. Login with provided credentials. Click on the Credentials in the left menu. This will take you to the credentials page. Scroll down to the Stores scoped to Jenkins and click on the System as shown in the image. Click on Global credentials (unrestricted) . Click on Add Credentials . This will take you to the New Credentials page. Select Kind as Username with password . Select Scope as Global (Jenkins, nodes, items, all child items etc) . Enter your GitHub username in Username Enter Password as GitHub personal authentication token (PAT) which can be acquired from Github account settings. ID is optional but you can enter a unique ID . Description can be left empty. But it is recommended to give a suitable but careful description by which administrator will be able to identify and use these credentials to set up github webhook Select Create This process will look something like this Now credentials will be available in the credentials list and will be shown to you as well as administrator as shown in the image below. This will create an option in configurations for using these credentials in github webhook without changing or viewing them. Note the credentials ID (as shown in the image below) and email it to the same administrator email on which you received the login credentials for Cloud-V. It is important that administrator knows the credentials ID because they will use it in the job build configurations. Note: Please make sure to inform the administrator via email that you have added the credentials in Cloud-V Dashboard. Also, send administrator the ID of credentials via email. Requirements for administrator After the above setup is complete from software developer's side, developer will need to provide the administrator with following information. Dependencies for running the project which can be packages which are needed to install in the RISC-V CI environment by administrator. Events for triggering the job build. URL of GitHub repository. Path and name of cloud-v-pipeline file on the provided GitHub repository. Any additional information which should be given for successful execution of job builds.","title":"Getting Started"},{"location":"Software_Developer_Guide/#software-developer-guide-for-risc-v-ci","text":"A software developer is the end-user who will develop or build his/her projects on RISC-V CI infrastructure. This guide will cover all the things a software developer needs to create a project based on Cloud-V Continuous Integration (CI).","title":"Software Developer Guide for RISC-V CI"},{"location":"Software_Developer_Guide/#pre-requisites","text":"GitHub account. GitHub project repository with owner rights.","title":"Pre-requisites"},{"location":"Software_Developer_Guide/#getting-an-account-for-cloud-v","text":"Fill out this google form with all the required information for getting an account on Cloud-V. After this we will get back to you with login credentials.","title":"Getting an account for Cloud-V"},{"location":"Software_Developer_Guide/#setting-up-cloud-v-pipeline-inside-github-project-repository","text":"Cloud-V will need a cloud-v-pipeline written with jenkinsfile pipeline syntax to start execution of tests/checks (see link ). This pipeline will contain all the stages (and may be steps) of a CI/CD pipeline. This pipeline can be scripted pipeline which will only have stages or it can also be declarative pipeline which may also have steps inside stages. A simple scripted Helloworld pipeline in linux is as follows: node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } Upon execution of such a pipeline, the console output can be viewed as follows. Note: This cloud-v-pipeline should remain same in all the branches and pull requests.","title":"Setting up cloud-v-pipeline inside github project repository"},{"location":"Software_Developer_Guide/#setting-credentials-for-webhook","text":"Cloud-V supports webhooks which can trigger the job from external sources such as GitHub. They work in a way such that, if a specified branch is committed or if a pull request is created, the specified job build starts running depending upon the trigger event which is set in build's configuration in Cloud-V. This process requires access token of the repository CREATED BY OWNER OF REPOSITORY on which the webhook is to be set. These credentials can be safely added to Cloud-V without anyone (even administrator) seeing the passwords as follows.","title":"Setting credentials for webhook"},{"location":"Software_Developer_Guide/#obtaining-github-access-token-for-repository","text":"Navigate to the dashboard of your github account and click on the your github profile picture on the top-right corner on dashboard. Then click on the \"Settings\" from the list. From the left option bar in Settings scroll down and click on \"Developer settings\". Once there, click on \"Personal access tokens\", then click on \"Fine-grained tokens\" from the dropdown list and after that click on \"Generate new token\". This will open the page for setting up new access token. Follow following steps for creating a token: Give your token a meaningful name under \"Token name\" Set expiration date in \"Expiration\" depending upon how long you would like your repository to be integrated with Cloud-V (think of a meaningful upper bound) The \"Resource owner\" should be the owner of the repository who can access all kinds of settings of the repository Under \"Repository access\", check \"Only select repositories\" and then select the repository for which you would like to create the token Under \"Permissions\" section, expand \"Repository Permissions\" and give the following two permissions: \"Read and write\" access to \"Commit statuses\" (Because after the CI has run, Cloud-V will be able to set the status of the commit accordingly) \"Read-only\" access to \"Webhooks\"","title":"Obtaining github access token for repository"},{"location":"Software_Developer_Guide/#configuring-repository-webhook","text":"In GitHub, Go to repository settings which you want to integrate for Cloud-V. Go to Webhooks Click on Add webhook Add Payload URL as https://dash.cloud-v.co/ghprbhook/ Select content type as application/json Check Enable SSL verification In the section Which events would you like to trigger this webhook? check Let me select individual events and check Pul requests as individual events and dont check any other permission. Webhook settings will look something like this:","title":"Configuring repository webhook"},{"location":"Software_Developer_Guide/#configurations-inside-cloud-v","text":"Note: Currently users are not able to see or modify pipeline build configuration inside Jenkins, that is currently managed by administrator. Users are requested to inform administrator about how they want their pipeline configured. We will provide you with Cloud-V credentials on the provided email. Login with provided credentials. Click on the Credentials in the left menu. This will take you to the credentials page. Scroll down to the Stores scoped to Jenkins and click on the System as shown in the image. Click on Global credentials (unrestricted) . Click on Add Credentials . This will take you to the New Credentials page. Select Kind as Username with password . Select Scope as Global (Jenkins, nodes, items, all child items etc) . Enter your GitHub username in Username Enter Password as GitHub personal authentication token (PAT) which can be acquired from Github account settings. ID is optional but you can enter a unique ID . Description can be left empty. But it is recommended to give a suitable but careful description by which administrator will be able to identify and use these credentials to set up github webhook Select Create This process will look something like this Now credentials will be available in the credentials list and will be shown to you as well as administrator as shown in the image below. This will create an option in configurations for using these credentials in github webhook without changing or viewing them. Note the credentials ID (as shown in the image below) and email it to the same administrator email on which you received the login credentials for Cloud-V. It is important that administrator knows the credentials ID because they will use it in the job build configurations. Note: Please make sure to inform the administrator via email that you have added the credentials in Cloud-V Dashboard. Also, send administrator the ID of credentials via email.","title":"Configurations inside Cloud-V"},{"location":"Software_Developer_Guide/#requirements-for-administrator","text":"After the above setup is complete from software developer's side, developer will need to provide the administrator with following information. Dependencies for running the project which can be packages which are needed to install in the RISC-V CI environment by administrator. Events for triggering the job build. URL of GitHub repository. Path and name of cloud-v-pipeline file on the provided GitHub repository. Any additional information which should be given for successful execution of job builds.","title":"Requirements for administrator"},{"location":"Tooling/","text":"Tools on Cloud-V Using Environment Modules Users can use environment modules to load different versions of same program. For using environment modules the pattern is as follows: module load <PACKAGENAME/VERSION> Important Note: Be sure to use #!/bin/bash -l instead of #!/bin/bash in CI pipeline file since that is required for environment modules to load For example if you want to load python version 3.9.2 compiled for x86, you will need to use following command: module load python/3.9.2 For packages compiled for RISC-V architecture host, you will need to append _riscv to package name. For example, for python 3.8.15 compiled for RISC-V, following command will be used. module load python_riscv/3.8.15","title":"Using Environment Modules"},{"location":"Tooling/#tools-on-cloud-v","text":"","title":"Tools on Cloud-V"},{"location":"Tooling/#using-environment-modules","text":"Users can use environment modules to load different versions of same program. For using environment modules the pattern is as follows: module load <PACKAGENAME/VERSION> Important Note: Be sure to use #!/bin/bash -l instead of #!/bin/bash in CI pipeline file since that is required for environment modules to load For example if you want to load python version 3.9.2 compiled for x86, you will need to use following command: module load python/3.9.2 For packages compiled for RISC-V architecture host, you will need to append _riscv to package name. For example, for python 3.8.15 compiled for RISC-V, following command will be used. module load python_riscv/3.8.15","title":"Using Environment Modules"},{"location":"jenkins_gitlab_integration/","text":"Integrating GitLab with Jenkins This documentation will cover how to create an integration between jenkins and GitLab. This will allow users to trigger jenkins job when a merge request or a push is detected in GitLab. Pre-requisites GitLab plugin Git plugin GitLab repository with owner's credentials Configuring Jenkins System First jenkins needs to be configured. Go to Dashboard > Manage Jenkins > Configure System Scroll down to Gitlab section Check Enable authentication for '/project' end-point Enter a Connection name . Enter Gitlab host URL as https://gitlab.com/ . In case there is a different domain name, then enter there instead of above url. In Credentials , click on Add then click on Jenkins . In Kind , select GitLab API token . In API token , enter the gitlab personal access token (this will be obtained below while configuring GitLab). Click on Advanced . Click on Test Connection . If everything goes right, it should print success . Configuring GitLab Click on profile avatar in the top right. Click on Edit profile . Click on Access Tokens . Create a new personal access token and copy it (this is the GitLab API token used in above section Configuring Jenkins System ). Go to repository settings. On left-side pane, select Webhooks . Enter GitLab webhook URL (this is explained below in next section). Enter Secret Token (this is explained in the below section). Check desirable trigger options. Click Add webhook . Configuring Jenkins Job Create a jenkins job. On job configuration page, scroll down to Source Code Management . Select Git . In Credentials , add the owner credentials of GitLab repository. This will be Username and Password . Select the appropriate branch (generally it is main ). Scroll down to Build Triggers . Check Build when a change is pushed to GitLab . There will also be a GitLab webhook URL . This is needed in GitLab. This URL will be called as Webhook URL . Click on Advanced in the same option, then scroll down and generate a secret token. This token is also needed. This token will be called as Secret Token . Scroll down to Post-build Actions and select Publish build status to GitLab . Click on Apply and Save . Now whenever there will be a push (or whatever build trigger option is set in jenkins and gitlab webhook), specified jenkins job will be triggered.","title":"Integrating GitLab with Jenkins"},{"location":"jenkins_gitlab_integration/#integrating-gitlab-with-jenkins","text":"This documentation will cover how to create an integration between jenkins and GitLab. This will allow users to trigger jenkins job when a merge request or a push is detected in GitLab.","title":"Integrating GitLab with Jenkins"},{"location":"jenkins_gitlab_integration/#pre-requisites","text":"GitLab plugin Git plugin GitLab repository with owner's credentials","title":"Pre-requisites"},{"location":"jenkins_gitlab_integration/#configuring-jenkins-system","text":"First jenkins needs to be configured. Go to Dashboard > Manage Jenkins > Configure System Scroll down to Gitlab section Check Enable authentication for '/project' end-point Enter a Connection name . Enter Gitlab host URL as https://gitlab.com/ . In case there is a different domain name, then enter there instead of above url. In Credentials , click on Add then click on Jenkins . In Kind , select GitLab API token . In API token , enter the gitlab personal access token (this will be obtained below while configuring GitLab). Click on Advanced . Click on Test Connection . If everything goes right, it should print success .","title":"Configuring Jenkins System"},{"location":"jenkins_gitlab_integration/#configuring-gitlab","text":"Click on profile avatar in the top right. Click on Edit profile . Click on Access Tokens . Create a new personal access token and copy it (this is the GitLab API token used in above section Configuring Jenkins System ). Go to repository settings. On left-side pane, select Webhooks . Enter GitLab webhook URL (this is explained below in next section). Enter Secret Token (this is explained in the below section). Check desirable trigger options. Click Add webhook .","title":"Configuring GitLab"},{"location":"jenkins_gitlab_integration/#configuring-jenkins-job","text":"Create a jenkins job. On job configuration page, scroll down to Source Code Management . Select Git . In Credentials , add the owner credentials of GitLab repository. This will be Username and Password . Select the appropriate branch (generally it is main ). Scroll down to Build Triggers . Check Build when a change is pushed to GitLab . There will also be a GitLab webhook URL . This is needed in GitLab. This URL will be called as Webhook URL . Click on Advanced in the same option, then scroll down and generate a secret token. This token is also needed. This token will be called as Secret Token . Scroll down to Post-build Actions and select Publish build status to GitLab . Click on Apply and Save . Now whenever there will be a push (or whatever build trigger option is set in jenkins and gitlab webhook), specified jenkins job will be triggered.","title":"Configuring Jenkins Job"},{"location":"runner_specs/","text":"Specifications of compute instances in Cloud-V This document contains the specifications of the compute instances available for users to run builds in Cloud-V. The term \"Compute Instance\", can also be safely interchanged with the terms \"Build Executor\" and \"Runner\". Name String Architecture Cores Memory Compute Instance Type ISA String J-x86-1 (or) J-QMU-1 x86_64 4 8GiB Hardware with application-level emulator J-TESTVM-1 x86_64 4 8GiB Hardware N/A J-RASP4-1 aarch64 4 4GiB Hardware ARMv8-A J-QMS-1 riscv64 2 2GiB QEMU System emulator rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc J-VF1-1 riscv64 2 8GiB Hardware rv64imafdc J-VF1-2 riscv64 2 8GiB Hardware rv64imafdc J-VF1-3 riscv64 2 8GiB Hardware rv64imafdc J-VF2-1 riscv64 4 8GiB Hardware rv64imafdc J-VF2-2 riscv64 4 8GiB Hardware rv64imafdc J-VF2-3 riscv64 4 8GiB Hardware rv64imafdc J-VF2-4 riscv64 4 8GiB Hardware rv64imafdc J-VF2-5 riscv64 4 8GiB Hardware rv64imafdc J-VF2-6 riscv64 4 8GiB Hardware rv64imafdc J-HF-1 riscv64 4 8GiB Hardware rv64imafdc J-K230-1 riscv64 1 512MiB Hardware rv64imafdcvxthead Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"Compute Instance Specifications"},{"location":"runner_specs/#specifications-of-compute-instances-in-cloud-v","text":"This document contains the specifications of the compute instances available for users to run builds in Cloud-V. The term \"Compute Instance\", can also be safely interchanged with the terms \"Build Executor\" and \"Runner\". Name String Architecture Cores Memory Compute Instance Type ISA String J-x86-1 (or) J-QMU-1 x86_64 4 8GiB Hardware with application-level emulator J-TESTVM-1 x86_64 4 8GiB Hardware N/A J-RASP4-1 aarch64 4 4GiB Hardware ARMv8-A J-QMS-1 riscv64 2 2GiB QEMU System emulator rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc J-VF1-1 riscv64 2 8GiB Hardware rv64imafdc J-VF1-2 riscv64 2 8GiB Hardware rv64imafdc J-VF1-3 riscv64 2 8GiB Hardware rv64imafdc J-VF2-1 riscv64 4 8GiB Hardware rv64imafdc J-VF2-2 riscv64 4 8GiB Hardware rv64imafdc J-VF2-3 riscv64 4 8GiB Hardware rv64imafdc J-VF2-4 riscv64 4 8GiB Hardware rv64imafdc J-VF2-5 riscv64 4 8GiB Hardware rv64imafdc J-VF2-6 riscv64 4 8GiB Hardware rv64imafdc J-HF-1 riscv64 4 8GiB Hardware rv64imafdc J-K230-1 riscv64 1 512MiB Hardware rv64imafdcvxthead Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"Specifications of compute instances in Cloud-V"},{"location":"tooling_J-HF-1/","text":"Tools on J-HF-1 node This compute instance is Sifive's HiFive Unleased board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 20.04.6 (Focal Fossa) Tool Version Installed from Git 2.25.1 apt OpenJDK 11.0.20.1 apt GCC 10.5.0 apt Python3 3.8.10 apt OpenSSL 1.1.1f apt Ruby 2.7.0p0 apt Go 1.14.3 apt rustc 1.41.0 apt Flex 2.6.4 apt Ninja 1.10.0 apt Bison 3.5.1 apt autoconf 2.69 apt gperf 3.1 apt cmake 3.16.3 apt make 4.2.1 apt automake 1.16.1 apt gfortran 9.4.0 apt openssh-server 8.2p1 apt","title":"J-HF-1"},{"location":"tooling_J-HF-1/#tools-on-j-hf-1-node","text":"This compute instance is Sifive's HiFive Unleased board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 20.04.6 (Focal Fossa) Tool Version Installed from Git 2.25.1 apt OpenJDK 11.0.20.1 apt GCC 10.5.0 apt Python3 3.8.10 apt OpenSSL 1.1.1f apt Ruby 2.7.0p0 apt Go 1.14.3 apt rustc 1.41.0 apt Flex 2.6.4 apt Ninja 1.10.0 apt Bison 3.5.1 apt autoconf 2.69 apt gperf 3.1 apt cmake 3.16.3 apt make 4.2.1 apt automake 1.16.1 apt gfortran 9.4.0 apt openssh-server 8.2p1 apt","title":"Tools on J-HF-1 node"},{"location":"tooling_J-K230-1/","text":"Tools on J-K230-1 node This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.40.1 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.6 apt OpenSSL 3.0.10 apt Ruby 3.1.2p20 apt Go 1.21.1 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.27.4 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.3p1 apt vim 9.0 apt vim 3.3a apt","title":"J-K230-1"},{"location":"tooling_J-K230-1/#tools-on-j-k230-1-node","text":"This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.40.1 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.6 apt OpenSSL 3.0.10 apt Ruby 3.1.2p20 apt Go 1.21.1 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.27.4 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.3p1 apt vim 9.0 apt vim 3.3a apt","title":"Tools on J-K230-1 node"},{"location":"tooling_J-QMS-1/","text":"Tools on J-QMS-1 node This is QEMU system compute instance with 64-bit RISC-V Linux and it has all the packages ONLY for RISC-V architecture Operating System: Ubuntu 22.04.4 LTS (Jammy Jellyfish) QEMU Linux Version: 7.2.90 (v9.0.0-rc0-68-g853546f812) Tool Version Installed from pip 22.0.2 apt Git 2.34.1 apt OpenJDK 19.0.1 apt GCC 11.4.0 apt Python3 3.10.12 apt OpenSSL 3.0.2 apt Ruby 3.0.2p107 apt Go 1.18.8 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.10.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt make 4.3 apt cmake 3.22.1 apt","title":"J-QMS-1"},{"location":"tooling_J-QMS-1/#tools-on-j-qms-1-node","text":"This is QEMU system compute instance with 64-bit RISC-V Linux and it has all the packages ONLY for RISC-V architecture Operating System: Ubuntu 22.04.4 LTS (Jammy Jellyfish) QEMU Linux Version: 7.2.90 (v9.0.0-rc0-68-g853546f812) Tool Version Installed from pip 22.0.2 apt Git 2.34.1 apt OpenJDK 19.0.1 apt GCC 11.4.0 apt Python3 3.10.12 apt OpenSSL 3.0.2 apt Ruby 3.0.2p107 apt Go 1.18.8 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.10.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt make 4.3 apt cmake 3.22.1 apt","title":"Tools on J-QMS-1 node"},{"location":"tooling_J-QMU-1J-VM-1/","text":"Tools on J-x86-1 or J-QMU-1 node Tools which are mentioned for x86 architecture are able to run on J-x86-1 . Tools which are mentioned for RISC-V architecture are able to run on J-QMU-1 . The packages which are supported for QEMU User mode can be used by normal commands once they are loaded. Here PACKAGE_NAME is the package which you want to run on QEMU user mode. Operating System: Debian 11 (bullseye) QEMU User Mode Version: Different Versions (see the table below) Tooling available for J-x86-1 The tools available for J-x86-1 is for use on x86 architecture and these tools do not support execution on RISC-V architecture Tool Versions Installed from Host Architecture Environment Modules Support Git 2.3.0.2 source x86 N/A OpenJDK 19.0.1 apt x86 N/A GCC 10.4.0, 12.2.0 apt x86 Yes Python3 3.8.15, 3.9.2 source x86 Yes Go 1.18.8 apt x86 N/A rustc 1.65.0 source x86 N/A Flex 2.6.4 apt x86 N/A Ninja 1.10.1-1 apt x86 N/A Bison 3.7.5 apt x86 N/A autoconf 2.69 apt x86 N/A gperf 2.2.4 apt x86 N/A spike 1.1.1-dev source x86 Yes Verilator 4.038 apt x86 N/A Sail (riscv_sim_RV64, riscv_sim_RV32) 0.5 source x86 Yes cmake 3.18.4 apt x86 N/A make 4.3 apt x86 N/A ARM EABI GNU toolchain 13.2.Rel1 source x86 Yes qemu-system-arm 8.2.2 source x86 Yes SCons 4.7.0 source x86 Yes Tooling available for J-QMU-1 The tools available for J-QMU-1 is for use on RISC-V architecture and these tools do not support execution on x86 architecture Tool Versions Installed from Host Architecture Environment Modules Support Python3 3.8.15 source RISC-V Yes zlib 1.2.13 source RISC-V N/A OpenSSL 1.1.1r source RISC-V Yes Ruby (without IRB) 3.2.0dev source RISC-V Yes rustc 1.65.0 source RISC-V N/A Flex 2.6.4 source RISC-V yes Ninja 1.12.0.git source RISC-V Yes Bison 3.8.2, 2.3 source RISC-V Yes clang 16.0.0 source RISC-V (cross compiler) Yes riscv-pk 1.0.0-91-g573c858 source RISC-V Yes QEMU User mode and RISC-V GNU Cross compilers From now on RISC-V cross-compilers can only be loaded with their respective QEMU User mode on Cloud-V. This is configured so that there is no confusion between toolchain version and qemu user mode being used because both of these will be \"generally\" taken from the latest releases of nightly builds. Loading a certain RISC-V toolchain using environment modules will automatically load the respective qemu usermode version unless otherwise specified. The loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-glibc/<release-date> And the loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-elf/<release-date> Following table provides relevant information about version of the toolchain and the respective QEMU User mode version (where the release date is mentioned in pattern MMDDYYYY ). Release date GNU Toolchain version (elf and glibc) QEMU Version 03012024 13.2.0 8.2.1 02022024 13.2.0 8.2.1 02022024 13.2.0 8.1.1 Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"J-x86-1 or J-QMU-1"},{"location":"tooling_J-QMU-1J-VM-1/#tools-on-j-x86-1-or-j-qmu-1-node","text":"Tools which are mentioned for x86 architecture are able to run on J-x86-1 . Tools which are mentioned for RISC-V architecture are able to run on J-QMU-1 . The packages which are supported for QEMU User mode can be used by normal commands once they are loaded. Here PACKAGE_NAME is the package which you want to run on QEMU user mode. Operating System: Debian 11 (bullseye) QEMU User Mode Version: Different Versions (see the table below)","title":"Tools on J-x86-1 or J-QMU-1 node"},{"location":"tooling_J-QMU-1J-VM-1/#tooling-available-for-j-x86-1","text":"The tools available for J-x86-1 is for use on x86 architecture and these tools do not support execution on RISC-V architecture Tool Versions Installed from Host Architecture Environment Modules Support Git 2.3.0.2 source x86 N/A OpenJDK 19.0.1 apt x86 N/A GCC 10.4.0, 12.2.0 apt x86 Yes Python3 3.8.15, 3.9.2 source x86 Yes Go 1.18.8 apt x86 N/A rustc 1.65.0 source x86 N/A Flex 2.6.4 apt x86 N/A Ninja 1.10.1-1 apt x86 N/A Bison 3.7.5 apt x86 N/A autoconf 2.69 apt x86 N/A gperf 2.2.4 apt x86 N/A spike 1.1.1-dev source x86 Yes Verilator 4.038 apt x86 N/A Sail (riscv_sim_RV64, riscv_sim_RV32) 0.5 source x86 Yes cmake 3.18.4 apt x86 N/A make 4.3 apt x86 N/A ARM EABI GNU toolchain 13.2.Rel1 source x86 Yes qemu-system-arm 8.2.2 source x86 Yes SCons 4.7.0 source x86 Yes","title":"Tooling available for J-x86-1"},{"location":"tooling_J-QMU-1J-VM-1/#tooling-available-for-j-qmu-1","text":"The tools available for J-QMU-1 is for use on RISC-V architecture and these tools do not support execution on x86 architecture Tool Versions Installed from Host Architecture Environment Modules Support Python3 3.8.15 source RISC-V Yes zlib 1.2.13 source RISC-V N/A OpenSSL 1.1.1r source RISC-V Yes Ruby (without IRB) 3.2.0dev source RISC-V Yes rustc 1.65.0 source RISC-V N/A Flex 2.6.4 source RISC-V yes Ninja 1.12.0.git source RISC-V Yes Bison 3.8.2, 2.3 source RISC-V Yes clang 16.0.0 source RISC-V (cross compiler) Yes riscv-pk 1.0.0-91-g573c858 source RISC-V Yes","title":"Tooling available for J-QMU-1"},{"location":"tooling_J-QMU-1J-VM-1/#qemu-user-mode-and-risc-v-gnu-cross-compilers","text":"From now on RISC-V cross-compilers can only be loaded with their respective QEMU User mode on Cloud-V. This is configured so that there is no confusion between toolchain version and qemu user mode being used because both of these will be \"generally\" taken from the latest releases of nightly builds. Loading a certain RISC-V toolchain using environment modules will automatically load the respective qemu usermode version unless otherwise specified. The loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-glibc/<release-date> And the loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-elf/<release-date> Following table provides relevant information about version of the toolchain and the respective QEMU User mode version (where the release date is mentioned in pattern MMDDYYYY ). Release date GNU Toolchain version (elf and glibc) QEMU Version 03012024 13.2.0 8.2.1 02022024 13.2.0 8.2.1 02022024 13.2.0 8.1.1 Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"QEMU User mode and RISC-V GNU Cross compilers"},{"location":"tooling_J-VF1-x/","text":"Tools on J-VF1-x node This compute instance is Starfive's VisionFive 1 board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 23.04 (Lunar Lobster) Tool Version Installed from Git 2.39.2 apt OpenJDK 21-ea apt GCC 13.1.0 apt Python3 3.11.4 apt OpenSSL 3.0.8 apt Ruby 3.1.2p20 apt Go 1.20.3 apt rustc 1.67.1 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.25.1 apt make 4.3 apt automake 1.16.5 apt gfortran 13.1.0 apt openssh-server 9.0p1 apt","title":"J-VF1-x"},{"location":"tooling_J-VF1-x/#tools-on-j-vf1-x-node","text":"This compute instance is Starfive's VisionFive 1 board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 23.04 (Lunar Lobster) Tool Version Installed from Git 2.39.2 apt OpenJDK 21-ea apt GCC 13.1.0 apt Python3 3.11.4 apt OpenSSL 3.0.8 apt Ruby 3.1.2p20 apt Go 1.20.3 apt rustc 1.67.1 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.25.1 apt make 4.3 apt automake 1.16.5 apt gfortran 13.1.0 apt openssh-server 9.0p1 apt","title":"Tools on J-VF1-x node"},{"location":"tooling_J-VF2-x/","text":"Tools on J-VF2-x node This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.43.0 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.7 apt OpenSSL 3.1.5 apt Ruby 3.1.2p20 apt Go 1.22.0 apt rustc 1.70.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.28.3 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.6p1 apt vim 9.1 apt","title":"J-VF2-x"},{"location":"tooling_J-VF2-x/#tools-on-j-vf2-x-node","text":"This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.43.0 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.7 apt OpenSSL 3.1.5 apt Ruby 3.1.2p20 apt Go 1.22.0 apt rustc 1.70.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.28.3 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.6p1 apt vim 9.1 apt","title":"Tools on J-VF2-x node"}]}
\ No newline at end of file
diff --git a/docs/sitemap.xml.gz b/docs/sitemap.xml.gz
index d734161fa1f5b193a8977226d5b21eaa49dc17ea..14e1119aaea4a479101a7b11c9115a8faa688b6a 100644
GIT binary patch
delta 13
Ucmb=gXP58h;P9xjnaExN02+-0&Hw-a

delta 13
Ucmb=gXP58h;J8*UKasrx03BWgJOBUy

diff --git a/docs/tooling_J-HF-1/index.html b/docs/tooling_J-HF-1/index.html
index 79e8143..e4c9c2d 100644
--- a/docs/tooling_J-HF-1/index.html
+++ b/docs/tooling_J-HF-1/index.html
@@ -71,6 +71,8 @@
     <ul class="current">
     </ul>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>
@@ -205,6 +207,7 @@ <h1 id="tools-on-j-hf-1-node">Tools on <code>J-HF-1</code> node</h1>
           </div><footer>
     <div class="rst-footer-buttons" role="navigation" aria-label="Footer Navigation">
         <a href="../tooling_J-VF2-x/" class="btn btn-neutral float-left" title="J-VF2-x"><span class="icon icon-circle-arrow-left"></span> Previous</a>
+        <a href="../tooling_J-K230-1/" class="btn btn-neutral float-right" title="J-K230-1">Next <span class="icon icon-circle-arrow-right"></span></a>
     </div>
 
   <hr/>
@@ -230,6 +233,8 @@ <h1 id="tools-on-j-hf-1-node">Tools on <code>J-HF-1</code> node</h1>
       <span><a href="../tooling_J-VF2-x/" style="color: #fcfcfc">&laquo; Previous</a></span>
     
     
+      <span><a href="../tooling_J-K230-1/" style="color: #fcfcfc">Next &raquo;</a></span>
+    
   </span>
 </div>
     <script src="../js/jquery-3.6.0.min.js"></script>
diff --git a/docs/tooling_J-K230-1/index.html b/docs/tooling_J-K230-1/index.html
new file mode 100644
index 0000000..dd81e76
--- /dev/null
+++ b/docs/tooling_J-K230-1/index.html
@@ -0,0 +1,259 @@
+<!DOCTYPE html>
+<html class="writer-html5" lang="en" >
+<head>
+    <meta charset="utf-8" />
+    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
+    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+      <link rel="shortcut icon" href="../img/favicon.ico" />
+    <title>J-K230-1 - Cloud-V Docs</title>
+    <link rel="stylesheet" href="../css/theme.css" />
+    <link rel="stylesheet" href="../css/theme_extra.css" />
+        <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.8.0/styles/github.min.css" />
+    
+      <script>
+        // Current page data
+        var mkdocs_page_name = "J-K230-1";
+        var mkdocs_page_input_path = "tooling_J-K230-1.md";
+        var mkdocs_page_url = null;
+      </script>
+    
+    <!--[if lt IE 9]>
+      <script src="../js/html5shiv.min.js"></script>
+    <![endif]-->
+      <script src="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.8.0/highlight.min.js"></script>
+      <script>hljs.highlightAll();</script> 
+</head>
+
+<body class="wy-body-for-nav" role="document">
+
+  <div class="wy-grid-for-nav">
+    <nav data-toggle="wy-nav-shift" class="wy-nav-side stickynav">
+    <div class="wy-side-scroll">
+      <div class="wy-side-nav-search">
+          <a href=".." class="icon icon-home"> Cloud-V Docs
+        </a><div role="search">
+  <form id ="rtd-search-form" class="wy-form" action="../search.html" method="get">
+      <input type="text" name="q" placeholder="Search docs" aria-label="Search docs" title="Type search term here" />
+  </form>
+</div>
+      </div>
+
+      <div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="Navigation menu">
+              <ul>
+                <li class="toctree-l1"><a class="reference internal" href="..">Home</a>
+                </li>
+              </ul>
+              <ul>
+                <li class="toctree-l1"><a class="reference internal" href="../Software_Developer_Guide/">Getting Started</a>
+                </li>
+              </ul>
+              <ul>
+                <li class="toctree-l1"><a class="reference internal" href="../Creating_jenkinsfile/">Creating a CI pipeline file</a>
+                </li>
+              </ul>
+              <ul>
+                <li class="toctree-l1"><a class="reference internal" href="../runner_specs/">Compute Instance Specifications</a>
+                </li>
+              </ul>
+              <p class="caption"><span class="caption-text">Tooling on Compute Instances</span></p>
+              <ul class="current">
+                  <li class="toctree-l1"><a class="reference internal" href="../Tooling/">Using Environment Modules</a>
+                  </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-QMU-1J-VM-1/">J-x86-1 or J-QMU-1</a>
+                  </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-QMS-1/">J-QMS-1</a>
+                  </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-VF1-x/">J-VF1-x</a>
+                  </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-VF2-x/">J-VF2-x</a>
+                  </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-HF-1/">J-HF-1</a>
+                  </li>
+                  <li class="toctree-l1 current"><a class="reference internal current" href="./">J-K230-1</a>
+    <ul class="current">
+    </ul>
+                  </li>
+              </ul>
+      </div>
+    </div>
+    </nav>
+
+    <section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
+      <nav class="wy-nav-top" role="navigation" aria-label="Mobile navigation menu">
+          <i data-toggle="wy-nav-top" class="fa fa-bars"></i>
+          <a href="..">Cloud-V Docs</a>
+        
+      </nav>
+      <div class="wy-nav-content">
+        <div class="rst-content"><div role="navigation" aria-label="breadcrumbs navigation">
+  <ul class="wy-breadcrumbs">
+    <li><a href=".." class="icon icon-home" aria-label="Docs"></a></li>
+          <li class="breadcrumb-item">Tooling on Compute Instances</li>
+      <li class="breadcrumb-item active">J-K230-1</li>
+    <li class="wy-breadcrumbs-aside">
+    </li>
+  </ul>
+  <hr/>
+</div>
+          <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
+            <div class="section" itemprop="articleBody">
+              
+                <h1 id="tools-on-j-k230-1-node">Tools on <code>J-K230-1</code> node</h1>
+<p>This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture.  </p>
+<p><strong>Operating System:</strong> Debian 12 (Bookworm)</p>
+<table>
+<thead>
+<tr>
+<th>Tool</th>
+<th>Version</th>
+<th>Installed from</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>Git</td>
+<td>2.40.1</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>OpenJDK</td>
+<td>21.0.2</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>GCC</td>
+<td>13.2.0</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>Python3</td>
+<td>3.11.6</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>OpenSSL</td>
+<td>3.0.10</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>Ruby</td>
+<td>3.1.2p20</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>Go</td>
+<td>1.21.1</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>rustc</td>
+<td>1.75.0</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>Flex</td>
+<td>2.6.4</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>Ninja</td>
+<td>1.11.1</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>Bison</td>
+<td>3.8.2</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>autoconf</td>
+<td>2.71</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>gperf</td>
+<td>3.1</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>cmake</td>
+<td>3.27.4</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>make</td>
+<td>4.3</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>automake</td>
+<td>1.16.5</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>gfortran</td>
+<td>13.2.0</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>openssh-server</td>
+<td>9.3p1</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>vim</td>
+<td>9.0</td>
+<td>apt</td>
+</tr>
+<tr>
+<td>vim</td>
+<td>3.3a</td>
+<td>apt</td>
+</tr>
+</tbody>
+</table>
+              
+            </div>
+          </div><footer>
+    <div class="rst-footer-buttons" role="navigation" aria-label="Footer Navigation">
+        <a href="../tooling_J-HF-1/" class="btn btn-neutral float-left" title="J-HF-1"><span class="icon icon-circle-arrow-left"></span> Previous</a>
+    </div>
+
+  <hr/>
+
+  <div role="contentinfo">
+    <!-- Copyright etc -->
+  </div>
+
+  Built with <a href="https://www.mkdocs.org/">MkDocs</a> using a <a href="https://github.com/readthedocs/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+</footer>
+          
+        </div>
+      </div>
+
+    </section>
+
+  </div>
+
+  <div class="rst-versions" role="note" aria-label="Versions">
+  <span class="rst-current-version" data-toggle="rst-current-version">
+    
+    
+      <span><a href="../tooling_J-HF-1/" style="color: #fcfcfc">&laquo; Previous</a></span>
+    
+    
+  </span>
+</div>
+    <script src="../js/jquery-3.6.0.min.js"></script>
+    <script>var base_url = "..";</script>
+    <script src="../js/theme_extra.js"></script>
+    <script src="../js/theme.js"></script>
+      <script src="../search/main.js"></script>
+    <script>
+        jQuery(function () {
+            SphinxRtdTheme.Navigation.enable(true);
+        });
+    </script>
+
+</body>
+</html>
diff --git a/docs/tooling_J-QMS-1/index.html b/docs/tooling_J-QMS-1/index.html
index 82bc65a..2276c7d 100644
--- a/docs/tooling_J-QMS-1/index.html
+++ b/docs/tooling_J-QMS-1/index.html
@@ -71,6 +71,8 @@
                   </li>
                   <li class="toctree-l1"><a class="reference internal" href="../tooling_J-HF-1/">J-HF-1</a>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>
diff --git a/docs/tooling_J-QMU-1J-VM-1/index.html b/docs/tooling_J-QMU-1J-VM-1/index.html
index e9c4076..00f0bde 100644
--- a/docs/tooling_J-QMU-1J-VM-1/index.html
+++ b/docs/tooling_J-QMU-1J-VM-1/index.html
@@ -77,6 +77,8 @@
                   </li>
                   <li class="toctree-l1"><a class="reference internal" href="../tooling_J-HF-1/">J-HF-1</a>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>
diff --git a/docs/tooling_J-VF1-x/index.html b/docs/tooling_J-VF1-x/index.html
index 467e4e6..3e971f5 100644
--- a/docs/tooling_J-VF1-x/index.html
+++ b/docs/tooling_J-VF1-x/index.html
@@ -71,6 +71,8 @@
                   </li>
                   <li class="toctree-l1"><a class="reference internal" href="../tooling_J-HF-1/">J-HF-1</a>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>
diff --git a/docs/tooling_J-VF2-x/index.html b/docs/tooling_J-VF2-x/index.html
index 1f43448..d45a197 100644
--- a/docs/tooling_J-VF2-x/index.html
+++ b/docs/tooling_J-VF2-x/index.html
@@ -71,6 +71,8 @@
                   </li>
                   <li class="toctree-l1"><a class="reference internal" href="../tooling_J-HF-1/">J-HF-1</a>
                   </li>
+                  <li class="toctree-l1"><a class="reference internal" href="../tooling_J-K230-1/">J-K230-1</a>
+                  </li>
               </ul>
       </div>
     </div>

From 2fa174f18ddeb2160cad33bd074da90e8a19e316 Mon Sep 17 00:00:00 2001
From: Ali Tariq <alitariq4589@gmail.com>
Date: Thu, 9 May 2024 12:50:19 +0500
Subject: [PATCH 3/4] Re arranged table entries

---
 docs/index.html                 |   2 +-
 docs/runner_specs/index.html    |  31 ++++++++++++++++---------------
 docs/search/search_index.json   |   2 +-
 docs/sitemap.xml.gz             | Bin 127 -> 127 bytes
 mkdocs_src/docs/runner_specs.md |  32 +++++++++++++++++---------------
 5 files changed, 35 insertions(+), 32 deletions(-)

diff --git a/docs/index.html b/docs/index.html
index cd8f74a..1119caa 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -149,5 +149,5 @@ <h1 id="cloud-v-documentation">Cloud-V Documentation</h1>
 
 <!--
 MkDocs version : 1.5.3
-Build Date UTC : 2024-05-09 07:24:56.687063+00:00
+Build Date UTC : 2024-05-09 07:50:02.339791+00:00
 -->
diff --git a/docs/runner_specs/index.html b/docs/runner_specs/index.html
index 2149a48..d0a3c6b 100644
--- a/docs/runner_specs/index.html
+++ b/docs/runner_specs/index.html
@@ -104,28 +104,28 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <tr>
 <th>Name String</th>
 <th>Architecture</th>
+<th>ISA String</th>
 <th>Cores</th>
 <th>Memory</th>
 <th>Compute Instance Type</th>
-<th>ISA String</th>
 </tr>
 </thead>
 <tbody>
 <tr>
 <td>J-x86-1 (or) J-QMU-1</td>
 <td>x86_64</td>
+<td>N/A</td>
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware with application-level emulator</td>
-<td></td>
 </tr>
 <tr>
 <td>J-TESTVM-1</td>
 <td>x86_64</td>
+<td>N/A</td>
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
-<td>N/A</td>
 </tr>
 <tr>
 <td>J-RASP4-1</td>
@@ -138,101 +138,102 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <tr>
 <td>J-QMS-1</td>
 <td>riscv64</td>
+<td>See Ext 1 at bottom</td>
 <td>2</td>
 <td>2GiB</td>
 <td>QEMU System emulator</td>
-<td>rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc</td>
 </tr>
 <tr>
 <td>J-VF1-1</td>
 <td>riscv64</td>
+<td>rv64imafdc</td>
 <td>2</td>
 <td>8GiB</td>
 <td>Hardware</td>
-<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF1-2</td>
 <td>riscv64</td>
+<td>rv64imafdc</td>
 <td>2</td>
 <td>8GiB</td>
 <td>Hardware</td>
-<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF1-3</td>
 <td>riscv64</td>
+<td>rv64imafdc</td>
 <td>2</td>
 <td>8GiB</td>
 <td>Hardware</td>
-<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF2-1</td>
 <td>riscv64</td>
+<td>rv64imafdc</td>
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
-<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF2-2</td>
 <td>riscv64</td>
+<td>rv64imafdc</td>
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
-<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF2-3</td>
 <td>riscv64</td>
+<td>rv64imafdc</td>
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
-<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF2-4</td>
 <td>riscv64</td>
+<td>rv64imafdc</td>
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
-<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF2-5</td>
 <td>riscv64</td>
+<td>rv64imafdc</td>
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
-<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-VF2-6</td>
 <td>riscv64</td>
+<td>rv64imafdc</td>
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
-<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-HF-1</td>
 <td>riscv64</td>
+<td>rv64imafdc</td>
 <td>4</td>
 <td>8GiB</td>
 <td>Hardware</td>
-<td>rv64imafdc</td>
 </tr>
 <tr>
 <td>J-K230-1</td>
 <td>riscv64</td>
+<td>rv64imafdcvxthead</td>
 <td>1</td>
 <td>512MiB</td>
 <td>Hardware</td>
-<td>rv64imafdcvxthead</td>
 </tr>
 </tbody>
 </table>
+<p><em><strong>Ext1:</strong> rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc</em></p>
 <p><em><strong>Note:</strong> The <code>J-QMU-1</code> and <code>J-x86-1</code> are one and the same runner. The purpose of creating two separate executors for same hardware is that <code>J-x86-1</code> is supposed to be specifically for x86 architecture whereas <code>J-QMU-1</code> is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for <code>J-x86-1</code> can also be used for <code>J-QMU-1</code></em></p>
               
             </div>
diff --git a/docs/search/search_index.json b/docs/search/search_index.json
index 2e32ead..109a81a 100644
--- a/docs/search/search_index.json
+++ b/docs/search/search_index.json
@@ -1 +1 @@
-{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"Cloud-V Documentation This documentation lists the tooling and necessary information to use Cloud-V for RISC-V application development on RISC-V compute instances provided by Cloud-V Overview Slides: link Youtube Channel: youtube.com/@Cloud-V","title":"Home"},{"location":"#cloud-v-documentation","text":"This documentation lists the tooling and necessary information to use Cloud-V for RISC-V application development on RISC-V compute instances provided by Cloud-V Overview Slides: link Youtube Channel: youtube.com/@Cloud-V","title":"Cloud-V Documentation"},{"location":"Creating_CI_CD_pipeline/","text":"Creating a CI/CD pipeline in Jenkins Pre Requisistes For sake of this documentation, jenkins built-in sample script is used to create and execute a cd/cd pipeline in jenkins. In the built-in script maven is used as M3, so one must install Maven plugin inside jenkins and name it M3 . Usually maven is already present inside jenkins and can be configured from Global Configuration Tools . Following steps demonstrate configuring Maven plugin. Go to Jenkins Dashboard and click on Manage Jenkins In Manage Jenkins , under System Configuration section, click on Global Tool Configuration . In Global Tool Configuration , scroll down to Maven section and click on the respective option under the Maven Section (should be Maven installations\u2026 or Add Maven ). Under Maven installations , enter M3 in \u201cname\u201d text box, check Install Automatically and select Version greater than 3, then click Apply and Save . This should install Maven version 3 and configure as M3 . Steps for Jenkins pipeline creation After installing Jenkins and having all the suggested plugins installed, go to Jenkins dashboard and click on Create Job . On the next page, give your pipeline a name, select Pipeline and click OK . A Configuration page for the pipeline will appear. Select Build Triggers options and General options according to need and scroll down to the Pipeline section. Definition section contains configuration for stages and steps of the pipeline. Under Definition section, you can either choose Pipeline script and try writing your own script or try some sample pipeline (like Hello World , Github+Maven etc) or you could select Pipeline script from SCM and give a github repository containing configurations of Pipeline. Press Save and Apply . This should take you to the Pipeline and you can build the pipeline and if no unresolved dependencies are present, the pipeline should build without any error.","title":"Creating a CI/CD pipeline in Jenkins"},{"location":"Creating_CI_CD_pipeline/#creating-a-cicd-pipeline-in-jenkins","text":"","title":"Creating a CI/CD pipeline in Jenkins"},{"location":"Creating_CI_CD_pipeline/#pre-requisistes","text":"For sake of this documentation, jenkins built-in sample script is used to create and execute a cd/cd pipeline in jenkins. In the built-in script maven is used as M3, so one must install Maven plugin inside jenkins and name it M3 . Usually maven is already present inside jenkins and can be configured from Global Configuration Tools . Following steps demonstrate configuring Maven plugin. Go to Jenkins Dashboard and click on Manage Jenkins In Manage Jenkins , under System Configuration section, click on Global Tool Configuration . In Global Tool Configuration , scroll down to Maven section and click on the respective option under the Maven Section (should be Maven installations\u2026 or Add Maven ). Under Maven installations , enter M3 in \u201cname\u201d text box, check Install Automatically and select Version greater than 3, then click Apply and Save . This should install Maven version 3 and configure as M3 .","title":"Pre Requisistes"},{"location":"Creating_CI_CD_pipeline/#steps-for-jenkins-pipeline-creation","text":"After installing Jenkins and having all the suggested plugins installed, go to Jenkins dashboard and click on Create Job . On the next page, give your pipeline a name, select Pipeline and click OK . A Configuration page for the pipeline will appear. Select Build Triggers options and General options according to need and scroll down to the Pipeline section. Definition section contains configuration for stages and steps of the pipeline. Under Definition section, you can either choose Pipeline script and try writing your own script or try some sample pipeline (like Hello World , Github+Maven etc) or you could select Pipeline script from SCM and give a github repository containing configurations of Pipeline. Press Save and Apply . This should take you to the Pipeline and you can build the pipeline and if no unresolved dependencies are present, the pipeline should build without any error.","title":"Steps for Jenkins pipeline creation"},{"location":"Creating_jenkinsfile/","text":"Creating a Cloud-V CI Pipeline file What is a Cloud-V CI Pipeline file A cloud-v-pipeline file is a Continuous Integration (CI) jenkins pipeline script which is written in Groovy. It describes various stages (and possibly steps) which are executed in the defined pattern. These stages can be written in bash or they can be written in Groovy itself. Mainly there can be two types of Cloud-V pipeline files are of two types: Scripted: Only contains stages Declarative: Contains stages as well as steps (more feature-rich and recommended) This documentation will cover how to create a cloud-v-pipeline file with bash script inside it and run it on various compute instances (which are known as Nodes in jenkins). Jenkins Node In jenkins, node represents a compute instance. In simple words, it is the platform on which our job build is going to run. Jenkins Master There is a jenkins Master node which is actually the compute instance on which Jenkins is installed. It is the node which schedules builds on runners. For security reason, no job is allowed to run on this node. Jenkins Slave Jenkins slave nodes are the compute instances on which our job builds run safely. They may be attached with jenkins master via hardware or they may be connected through remote SSH connection. cloud-v-pipeline file written with bash Simple Hello World cloud-v-pipeline file In Cloud-V, all the platforms are running Linux operating system, so the cloud-v-pipeline should be written in bash. Following script is an example of how can we run a bash script in scripted cloud-v-pipeline . node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } The keyword sh is used to specify a shell script As there is nothing mentioned with node , so the script will run job build on any available compute instance. cloud-v-pipeline for a Specific Node In previous script, the cloud-v-pipeline would run on any compute instances which are available. But in case if someone wants to run a job build on specific node, then a compute instance name must be specified with keyword node . The following script is an example of running above Hello World program on node named hifive_unleashed . node('hifive_unleashed'){ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } cloud-v-pipeline for Cross-Platform Compilation and Execution Cloud-V supports cross-compilation and execution on emulated RISC-V compute instances. Following tools help in cross compilation and cross-platfrom execution: RISC-V GNU Toolchain QEMU user mode (for running standalone binaries) QEMU System (for running application in Linux) An example pipeline script is given below in scripted pipeline. node('x86_runner2'){ checkout scm //Getting content of this repo stage('*** Compilation Phase ***') { // for display purposes //Compiling helloworld.c using bash commands sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out //Cross compiling for RISC-V ''' } stage (' *** Running Binaries ***'){ sh '''#!/bin/bash ./helloworld.out qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out //Running executable on RISC-V emulated platform ''' } } The equivalent declarative pipeline is as follows: pipeline { agent {label \"x86_runner2\"} stages { stage('Clone Repository') { steps('delegate'){ checkout scm //Clones the repository on the local machine } } stage ('Compilation Phase'){ steps{ sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out ''' sh '''#!/bin/bash riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out ''' } } stage ('Running Binaries'){ steps { sh ''' #!/bin/bash ./helloworld.out ''' sh'''#!/bin/bash qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out ''' } } } } Reference Links https://www.jenkins.io/doc/book/pipeline/syntax/","title":"Creating a CI pipeline file"},{"location":"Creating_jenkinsfile/#creating-a-cloud-v-ci-pipeline-file","text":"","title":"Creating a Cloud-V CI Pipeline file"},{"location":"Creating_jenkinsfile/#what-is-a-cloud-v-ci-pipeline-file","text":"A cloud-v-pipeline file is a Continuous Integration (CI) jenkins pipeline script which is written in Groovy. It describes various stages (and possibly steps) which are executed in the defined pattern. These stages can be written in bash or they can be written in Groovy itself. Mainly there can be two types of Cloud-V pipeline files are of two types: Scripted: Only contains stages Declarative: Contains stages as well as steps (more feature-rich and recommended) This documentation will cover how to create a cloud-v-pipeline file with bash script inside it and run it on various compute instances (which are known as Nodes in jenkins).","title":"What is a Cloud-V CI Pipeline file"},{"location":"Creating_jenkinsfile/#jenkins-node","text":"In jenkins, node represents a compute instance. In simple words, it is the platform on which our job build is going to run.","title":"Jenkins Node"},{"location":"Creating_jenkinsfile/#jenkins-master","text":"There is a jenkins Master node which is actually the compute instance on which Jenkins is installed. It is the node which schedules builds on runners. For security reason, no job is allowed to run on this node.","title":"Jenkins Master"},{"location":"Creating_jenkinsfile/#jenkins-slave","text":"Jenkins slave nodes are the compute instances on which our job builds run safely. They may be attached with jenkins master via hardware or they may be connected through remote SSH connection.","title":"Jenkins Slave"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-file-written-with-bash","text":"","title":"cloud-v-pipeline file written with bash"},{"location":"Creating_jenkinsfile/#simple-hello-world-cloud-v-pipeline-file","text":"In Cloud-V, all the platforms are running Linux operating system, so the cloud-v-pipeline should be written in bash. Following script is an example of how can we run a bash script in scripted cloud-v-pipeline . node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } The keyword sh is used to specify a shell script As there is nothing mentioned with node , so the script will run job build on any available compute instance.","title":"Simple Hello World cloud-v-pipeline file"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-for-a-specific-node","text":"In previous script, the cloud-v-pipeline would run on any compute instances which are available. But in case if someone wants to run a job build on specific node, then a compute instance name must be specified with keyword node . The following script is an example of running above Hello World program on node named hifive_unleashed . node('hifive_unleashed'){ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } }","title":"cloud-v-pipeline for a Specific Node"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-for-cross-platform-compilation-and-execution","text":"Cloud-V supports cross-compilation and execution on emulated RISC-V compute instances. Following tools help in cross compilation and cross-platfrom execution: RISC-V GNU Toolchain QEMU user mode (for running standalone binaries) QEMU System (for running application in Linux) An example pipeline script is given below in scripted pipeline. node('x86_runner2'){ checkout scm //Getting content of this repo stage('*** Compilation Phase ***') { // for display purposes //Compiling helloworld.c using bash commands sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out //Cross compiling for RISC-V ''' } stage (' *** Running Binaries ***'){ sh '''#!/bin/bash ./helloworld.out qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out //Running executable on RISC-V emulated platform ''' } } The equivalent declarative pipeline is as follows: pipeline { agent {label \"x86_runner2\"} stages { stage('Clone Repository') { steps('delegate'){ checkout scm //Clones the repository on the local machine } } stage ('Compilation Phase'){ steps{ sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out ''' sh '''#!/bin/bash riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out ''' } } stage ('Running Binaries'){ steps { sh ''' #!/bin/bash ./helloworld.out ''' sh'''#!/bin/bash qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out ''' } } } }","title":"cloud-v-pipeline for Cross-Platform Compilation and Execution"},{"location":"Creating_jenkinsfile/#reference-links","text":"https://www.jenkins.io/doc/book/pipeline/syntax/","title":"Reference Links"},{"location":"Multinode_Pipelines/","text":"Multinode Pipelines One can create multinode pipelines in jenkins freestyle pipeline job as well as in jenkins native pipeline job. In such a pipeline, different stages of the pipeline can run on separate nodes. The jenkins native pipeline job can have two types. Scripted Pipeline Declarative pipeline For the sake of this documentation, two nodes are used: container-node and container-node2 Label In jenkins, label specifies where the job or a stage of the job can run. In jenkins, a label can be explicitly added in the node's configuration so that each time that label is mentioned in a jenkins job, that specific node is used for building the job, or the name of the node can also be used as label in case if no label is added in the node. Creating multinode pipelines in Jenkins native pipeline job Scripted Pipeline For creating a multinode pipeline with jenkins native scripted pipeline job, jenkinsfile can be tweaked. The keyword node can be used to specify the node in which the stages are going to run and this keyword can also be used in between stages. Following screenshot indicates a code in which first stage runs on node named container-node . While the second node runs on node named container-node2 . node ('container-node') { stage ('*** Creating a directory in container-node ***'){ sh '''#!/bin/bash mkdir newdir_container-node-$RANDOM ''' } stage ('*** Creating a directory in container-node2'){ node ('container-node2'){ sh'''#!/bin/bash mkdir newdir_container-node2-$RANDOM ''' } } } Declarative pipeline For a declarative pipeline the keyword label can be used in the agent block. This can either be done at the start of the pipeline after the keyword pipeline or it can be used inside the stages. The following code builds two stages each of which is built in separate node. The keyword none with agent means that the agent is not specified globally for each stage and it should be specified inside each stage. pipeline { agent none // Means no agent specified. This means each node will specify its own agent stages { stage('container-node') { agent{ label \"container-node\" //Selecting container-node for this stage } steps { sh '''#!/bin/bash echo 'Hello container-node' mkdir \"newdir-container-node-$RANDOM\" ''' } } stage('container-node2'){ agent{ label \"container-node2\" //Selecting container-node2 for this stage } steps{ sh'''#!/bin/bash echo ''Hello container-node2 mkdir \"newdir-container-node2-$RANDOM\" ''' } } } } Creating multinode pipelines using Jenkins freestyle jobs Jenkins freestyle jobs can be combined together by mentioning post-build jobs in the freestyle job settings. Freestyle jobs are customizable and offer more options than jenkins native pipeline jobs. Each job represents a stage and each stage has separate settings. One can use jenkins freestyle jobs to run on a separate node by selecting the option Restrict where this project can be run in the General section of the job's configuration. In the Label Expression , the node's name can be mentioned in which to run the job. The following image shows the option from job's configuration. This can be done in all the job's configuration for the specified node.","title":"Multinode Pipelines"},{"location":"Multinode_Pipelines/#multinode-pipelines","text":"One can create multinode pipelines in jenkins freestyle pipeline job as well as in jenkins native pipeline job. In such a pipeline, different stages of the pipeline can run on separate nodes. The jenkins native pipeline job can have two types. Scripted Pipeline Declarative pipeline For the sake of this documentation, two nodes are used: container-node and container-node2","title":"Multinode Pipelines"},{"location":"Multinode_Pipelines/#label","text":"In jenkins, label specifies where the job or a stage of the job can run. In jenkins, a label can be explicitly added in the node's configuration so that each time that label is mentioned in a jenkins job, that specific node is used for building the job, or the name of the node can also be used as label in case if no label is added in the node.","title":"Label"},{"location":"Multinode_Pipelines/#creating-multinode-pipelines-in-jenkins-native-pipeline-job","text":"","title":"Creating multinode pipelines in Jenkins native pipeline job"},{"location":"Multinode_Pipelines/#scripted-pipeline","text":"For creating a multinode pipeline with jenkins native scripted pipeline job, jenkinsfile can be tweaked. The keyword node can be used to specify the node in which the stages are going to run and this keyword can also be used in between stages. Following screenshot indicates a code in which first stage runs on node named container-node . While the second node runs on node named container-node2 . node ('container-node') { stage ('*** Creating a directory in container-node ***'){ sh '''#!/bin/bash mkdir newdir_container-node-$RANDOM ''' } stage ('*** Creating a directory in container-node2'){ node ('container-node2'){ sh'''#!/bin/bash mkdir newdir_container-node2-$RANDOM ''' } } }","title":"Scripted Pipeline"},{"location":"Multinode_Pipelines/#declarative-pipeline","text":"For a declarative pipeline the keyword label can be used in the agent block. This can either be done at the start of the pipeline after the keyword pipeline or it can be used inside the stages. The following code builds two stages each of which is built in separate node. The keyword none with agent means that the agent is not specified globally for each stage and it should be specified inside each stage. pipeline { agent none // Means no agent specified. This means each node will specify its own agent stages { stage('container-node') { agent{ label \"container-node\" //Selecting container-node for this stage } steps { sh '''#!/bin/bash echo 'Hello container-node' mkdir \"newdir-container-node-$RANDOM\" ''' } } stage('container-node2'){ agent{ label \"container-node2\" //Selecting container-node2 for this stage } steps{ sh'''#!/bin/bash echo ''Hello container-node2 mkdir \"newdir-container-node2-$RANDOM\" ''' } } } }","title":"Declarative pipeline"},{"location":"Multinode_Pipelines/#creating-multinode-pipelines-using-jenkins-freestyle-jobs","text":"Jenkins freestyle jobs can be combined together by mentioning post-build jobs in the freestyle job settings. Freestyle jobs are customizable and offer more options than jenkins native pipeline jobs. Each job represents a stage and each stage has separate settings. One can use jenkins freestyle jobs to run on a separate node by selecting the option Restrict where this project can be run in the General section of the job's configuration. In the Label Expression , the node's name can be mentioned in which to run the job. The following image shows the option from job's configuration. This can be done in all the job's configuration for the specified node.","title":"Creating multinode pipelines using Jenkins freestyle jobs"},{"location":"Software_Developer_Guide/","text":"Software Developer Guide for RISC-V CI A software developer is the end-user who will develop or build his/her projects on RISC-V CI infrastructure. This guide will cover all the things a software developer needs to create a project based on Cloud-V Continuous Integration (CI). Pre-requisites GitHub account. GitHub project repository with owner rights. Getting an account for Cloud-V Fill out this google form with all the required information for getting an account on Cloud-V. After this we will get back to you with login credentials. Setting up cloud-v-pipeline inside github project repository Cloud-V will need a cloud-v-pipeline written with jenkinsfile pipeline syntax to start execution of tests/checks (see link ). This pipeline will contain all the stages (and may be steps) of a CI/CD pipeline. This pipeline can be scripted pipeline which will only have stages or it can also be declarative pipeline which may also have steps inside stages. A simple scripted Helloworld pipeline in linux is as follows: node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } Upon execution of such a pipeline, the console output can be viewed as follows. Note: This cloud-v-pipeline should remain same in all the branches and pull requests. Setting credentials for webhook Cloud-V supports webhooks which can trigger the job from external sources such as GitHub. They work in a way such that, if a specified branch is committed or if a pull request is created, the specified job build starts running depending upon the trigger event which is set in build's configuration in Cloud-V. This process requires access token of the repository CREATED BY OWNER OF REPOSITORY on which the webhook is to be set. These credentials can be safely added to Cloud-V without anyone (even administrator) seeing the passwords as follows. Obtaining github access token for repository Navigate to the dashboard of your github account and click on the your github profile picture on the top-right corner on dashboard. Then click on the \"Settings\" from the list. From the left option bar in Settings scroll down and click on \"Developer settings\". Once there, click on \"Personal access tokens\", then click on \"Fine-grained tokens\" from the dropdown list and after that click on \"Generate new token\". This will open the page for setting up new access token. Follow following steps for creating a token: Give your token a meaningful name under \"Token name\" Set expiration date in \"Expiration\" depending upon how long you would like your repository to be integrated with Cloud-V (think of a meaningful upper bound) The \"Resource owner\" should be the owner of the repository who can access all kinds of settings of the repository Under \"Repository access\", check \"Only select repositories\" and then select the repository for which you would like to create the token Under \"Permissions\" section, expand \"Repository Permissions\" and give the following two permissions: \"Read and write\" access to \"Commit statuses\" (Because after the CI has run, Cloud-V will be able to set the status of the commit accordingly) \"Read-only\" access to \"Webhooks\" Configuring repository webhook In GitHub, Go to repository settings which you want to integrate for Cloud-V. Go to Webhooks Click on Add webhook Add Payload URL as https://dash.cloud-v.co/ghprbhook/ Select content type as application/json Check Enable SSL verification In the section Which events would you like to trigger this webhook? check Let me select individual events and check Pul requests as individual events and dont check any other permission. Webhook settings will look something like this: Configurations inside Cloud-V Note: Currently users are not able to see or modify pipeline build configuration inside Jenkins, that is currently managed by administrator. Users are requested to inform administrator about how they want their pipeline configured. We will provide you with Cloud-V credentials on the provided email. Login with provided credentials. Click on the Credentials in the left menu. This will take you to the credentials page. Scroll down to the Stores scoped to Jenkins and click on the System as shown in the image. Click on Global credentials (unrestricted) . Click on Add Credentials . This will take you to the New Credentials page. Select Kind as Username with password . Select Scope as Global (Jenkins, nodes, items, all child items etc) . Enter your GitHub username in Username Enter Password as GitHub personal authentication token (PAT) which can be acquired from Github account settings. ID is optional but you can enter a unique ID . Description can be left empty. But it is recommended to give a suitable but careful description by which administrator will be able to identify and use these credentials to set up github webhook Select Create This process will look something like this Now credentials will be available in the credentials list and will be shown to you as well as administrator as shown in the image below. This will create an option in configurations for using these credentials in github webhook without changing or viewing them. Note the credentials ID (as shown in the image below) and email it to the same administrator email on which you received the login credentials for Cloud-V. It is important that administrator knows the credentials ID because they will use it in the job build configurations. Note: Please make sure to inform the administrator via email that you have added the credentials in Cloud-V Dashboard. Also, send administrator the ID of credentials via email. Requirements for administrator After the above setup is complete from software developer's side, developer will need to provide the administrator with following information. Dependencies for running the project which can be packages which are needed to install in the RISC-V CI environment by administrator. Events for triggering the job build. URL of GitHub repository. Path and name of cloud-v-pipeline file on the provided GitHub repository. Any additional information which should be given for successful execution of job builds.","title":"Getting Started"},{"location":"Software_Developer_Guide/#software-developer-guide-for-risc-v-ci","text":"A software developer is the end-user who will develop or build his/her projects on RISC-V CI infrastructure. This guide will cover all the things a software developer needs to create a project based on Cloud-V Continuous Integration (CI).","title":"Software Developer Guide for RISC-V CI"},{"location":"Software_Developer_Guide/#pre-requisites","text":"GitHub account. GitHub project repository with owner rights.","title":"Pre-requisites"},{"location":"Software_Developer_Guide/#getting-an-account-for-cloud-v","text":"Fill out this google form with all the required information for getting an account on Cloud-V. After this we will get back to you with login credentials.","title":"Getting an account for Cloud-V"},{"location":"Software_Developer_Guide/#setting-up-cloud-v-pipeline-inside-github-project-repository","text":"Cloud-V will need a cloud-v-pipeline written with jenkinsfile pipeline syntax to start execution of tests/checks (see link ). This pipeline will contain all the stages (and may be steps) of a CI/CD pipeline. This pipeline can be scripted pipeline which will only have stages or it can also be declarative pipeline which may also have steps inside stages. A simple scripted Helloworld pipeline in linux is as follows: node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } Upon execution of such a pipeline, the console output can be viewed as follows. Note: This cloud-v-pipeline should remain same in all the branches and pull requests.","title":"Setting up cloud-v-pipeline inside github project repository"},{"location":"Software_Developer_Guide/#setting-credentials-for-webhook","text":"Cloud-V supports webhooks which can trigger the job from external sources such as GitHub. They work in a way such that, if a specified branch is committed or if a pull request is created, the specified job build starts running depending upon the trigger event which is set in build's configuration in Cloud-V. This process requires access token of the repository CREATED BY OWNER OF REPOSITORY on which the webhook is to be set. These credentials can be safely added to Cloud-V without anyone (even administrator) seeing the passwords as follows.","title":"Setting credentials for webhook"},{"location":"Software_Developer_Guide/#obtaining-github-access-token-for-repository","text":"Navigate to the dashboard of your github account and click on the your github profile picture on the top-right corner on dashboard. Then click on the \"Settings\" from the list. From the left option bar in Settings scroll down and click on \"Developer settings\". Once there, click on \"Personal access tokens\", then click on \"Fine-grained tokens\" from the dropdown list and after that click on \"Generate new token\". This will open the page for setting up new access token. Follow following steps for creating a token: Give your token a meaningful name under \"Token name\" Set expiration date in \"Expiration\" depending upon how long you would like your repository to be integrated with Cloud-V (think of a meaningful upper bound) The \"Resource owner\" should be the owner of the repository who can access all kinds of settings of the repository Under \"Repository access\", check \"Only select repositories\" and then select the repository for which you would like to create the token Under \"Permissions\" section, expand \"Repository Permissions\" and give the following two permissions: \"Read and write\" access to \"Commit statuses\" (Because after the CI has run, Cloud-V will be able to set the status of the commit accordingly) \"Read-only\" access to \"Webhooks\"","title":"Obtaining github access token for repository"},{"location":"Software_Developer_Guide/#configuring-repository-webhook","text":"In GitHub, Go to repository settings which you want to integrate for Cloud-V. Go to Webhooks Click on Add webhook Add Payload URL as https://dash.cloud-v.co/ghprbhook/ Select content type as application/json Check Enable SSL verification In the section Which events would you like to trigger this webhook? check Let me select individual events and check Pul requests as individual events and dont check any other permission. Webhook settings will look something like this:","title":"Configuring repository webhook"},{"location":"Software_Developer_Guide/#configurations-inside-cloud-v","text":"Note: Currently users are not able to see or modify pipeline build configuration inside Jenkins, that is currently managed by administrator. Users are requested to inform administrator about how they want their pipeline configured. We will provide you with Cloud-V credentials on the provided email. Login with provided credentials. Click on the Credentials in the left menu. This will take you to the credentials page. Scroll down to the Stores scoped to Jenkins and click on the System as shown in the image. Click on Global credentials (unrestricted) . Click on Add Credentials . This will take you to the New Credentials page. Select Kind as Username with password . Select Scope as Global (Jenkins, nodes, items, all child items etc) . Enter your GitHub username in Username Enter Password as GitHub personal authentication token (PAT) which can be acquired from Github account settings. ID is optional but you can enter a unique ID . Description can be left empty. But it is recommended to give a suitable but careful description by which administrator will be able to identify and use these credentials to set up github webhook Select Create This process will look something like this Now credentials will be available in the credentials list and will be shown to you as well as administrator as shown in the image below. This will create an option in configurations for using these credentials in github webhook without changing or viewing them. Note the credentials ID (as shown in the image below) and email it to the same administrator email on which you received the login credentials for Cloud-V. It is important that administrator knows the credentials ID because they will use it in the job build configurations. Note: Please make sure to inform the administrator via email that you have added the credentials in Cloud-V Dashboard. Also, send administrator the ID of credentials via email.","title":"Configurations inside Cloud-V"},{"location":"Software_Developer_Guide/#requirements-for-administrator","text":"After the above setup is complete from software developer's side, developer will need to provide the administrator with following information. Dependencies for running the project which can be packages which are needed to install in the RISC-V CI environment by administrator. Events for triggering the job build. URL of GitHub repository. Path and name of cloud-v-pipeline file on the provided GitHub repository. Any additional information which should be given for successful execution of job builds.","title":"Requirements for administrator"},{"location":"Tooling/","text":"Tools on Cloud-V Using Environment Modules Users can use environment modules to load different versions of same program. For using environment modules the pattern is as follows: module load <PACKAGENAME/VERSION> Important Note: Be sure to use #!/bin/bash -l instead of #!/bin/bash in CI pipeline file since that is required for environment modules to load For example if you want to load python version 3.9.2 compiled for x86, you will need to use following command: module load python/3.9.2 For packages compiled for RISC-V architecture host, you will need to append _riscv to package name. For example, for python 3.8.15 compiled for RISC-V, following command will be used. module load python_riscv/3.8.15","title":"Using Environment Modules"},{"location":"Tooling/#tools-on-cloud-v","text":"","title":"Tools on Cloud-V"},{"location":"Tooling/#using-environment-modules","text":"Users can use environment modules to load different versions of same program. For using environment modules the pattern is as follows: module load <PACKAGENAME/VERSION> Important Note: Be sure to use #!/bin/bash -l instead of #!/bin/bash in CI pipeline file since that is required for environment modules to load For example if you want to load python version 3.9.2 compiled for x86, you will need to use following command: module load python/3.9.2 For packages compiled for RISC-V architecture host, you will need to append _riscv to package name. For example, for python 3.8.15 compiled for RISC-V, following command will be used. module load python_riscv/3.8.15","title":"Using Environment Modules"},{"location":"jenkins_gitlab_integration/","text":"Integrating GitLab with Jenkins This documentation will cover how to create an integration between jenkins and GitLab. This will allow users to trigger jenkins job when a merge request or a push is detected in GitLab. Pre-requisites GitLab plugin Git plugin GitLab repository with owner's credentials Configuring Jenkins System First jenkins needs to be configured. Go to Dashboard > Manage Jenkins > Configure System Scroll down to Gitlab section Check Enable authentication for '/project' end-point Enter a Connection name . Enter Gitlab host URL as https://gitlab.com/ . In case there is a different domain name, then enter there instead of above url. In Credentials , click on Add then click on Jenkins . In Kind , select GitLab API token . In API token , enter the gitlab personal access token (this will be obtained below while configuring GitLab). Click on Advanced . Click on Test Connection . If everything goes right, it should print success . Configuring GitLab Click on profile avatar in the top right. Click on Edit profile . Click on Access Tokens . Create a new personal access token and copy it (this is the GitLab API token used in above section Configuring Jenkins System ). Go to repository settings. On left-side pane, select Webhooks . Enter GitLab webhook URL (this is explained below in next section). Enter Secret Token (this is explained in the below section). Check desirable trigger options. Click Add webhook . Configuring Jenkins Job Create a jenkins job. On job configuration page, scroll down to Source Code Management . Select Git . In Credentials , add the owner credentials of GitLab repository. This will be Username and Password . Select the appropriate branch (generally it is main ). Scroll down to Build Triggers . Check Build when a change is pushed to GitLab . There will also be a GitLab webhook URL . This is needed in GitLab. This URL will be called as Webhook URL . Click on Advanced in the same option, then scroll down and generate a secret token. This token is also needed. This token will be called as Secret Token . Scroll down to Post-build Actions and select Publish build status to GitLab . Click on Apply and Save . Now whenever there will be a push (or whatever build trigger option is set in jenkins and gitlab webhook), specified jenkins job will be triggered.","title":"Integrating GitLab with Jenkins"},{"location":"jenkins_gitlab_integration/#integrating-gitlab-with-jenkins","text":"This documentation will cover how to create an integration between jenkins and GitLab. This will allow users to trigger jenkins job when a merge request or a push is detected in GitLab.","title":"Integrating GitLab with Jenkins"},{"location":"jenkins_gitlab_integration/#pre-requisites","text":"GitLab plugin Git plugin GitLab repository with owner's credentials","title":"Pre-requisites"},{"location":"jenkins_gitlab_integration/#configuring-jenkins-system","text":"First jenkins needs to be configured. Go to Dashboard > Manage Jenkins > Configure System Scroll down to Gitlab section Check Enable authentication for '/project' end-point Enter a Connection name . Enter Gitlab host URL as https://gitlab.com/ . In case there is a different domain name, then enter there instead of above url. In Credentials , click on Add then click on Jenkins . In Kind , select GitLab API token . In API token , enter the gitlab personal access token (this will be obtained below while configuring GitLab). Click on Advanced . Click on Test Connection . If everything goes right, it should print success .","title":"Configuring Jenkins System"},{"location":"jenkins_gitlab_integration/#configuring-gitlab","text":"Click on profile avatar in the top right. Click on Edit profile . Click on Access Tokens . Create a new personal access token and copy it (this is the GitLab API token used in above section Configuring Jenkins System ). Go to repository settings. On left-side pane, select Webhooks . Enter GitLab webhook URL (this is explained below in next section). Enter Secret Token (this is explained in the below section). Check desirable trigger options. Click Add webhook .","title":"Configuring GitLab"},{"location":"jenkins_gitlab_integration/#configuring-jenkins-job","text":"Create a jenkins job. On job configuration page, scroll down to Source Code Management . Select Git . In Credentials , add the owner credentials of GitLab repository. This will be Username and Password . Select the appropriate branch (generally it is main ). Scroll down to Build Triggers . Check Build when a change is pushed to GitLab . There will also be a GitLab webhook URL . This is needed in GitLab. This URL will be called as Webhook URL . Click on Advanced in the same option, then scroll down and generate a secret token. This token is also needed. This token will be called as Secret Token . Scroll down to Post-build Actions and select Publish build status to GitLab . Click on Apply and Save . Now whenever there will be a push (or whatever build trigger option is set in jenkins and gitlab webhook), specified jenkins job will be triggered.","title":"Configuring Jenkins Job"},{"location":"runner_specs/","text":"Specifications of compute instances in Cloud-V This document contains the specifications of the compute instances available for users to run builds in Cloud-V. The term \"Compute Instance\", can also be safely interchanged with the terms \"Build Executor\" and \"Runner\". Name String Architecture Cores Memory Compute Instance Type ISA String J-x86-1 (or) J-QMU-1 x86_64 4 8GiB Hardware with application-level emulator J-TESTVM-1 x86_64 4 8GiB Hardware N/A J-RASP4-1 aarch64 4 4GiB Hardware ARMv8-A J-QMS-1 riscv64 2 2GiB QEMU System emulator rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc J-VF1-1 riscv64 2 8GiB Hardware rv64imafdc J-VF1-2 riscv64 2 8GiB Hardware rv64imafdc J-VF1-3 riscv64 2 8GiB Hardware rv64imafdc J-VF2-1 riscv64 4 8GiB Hardware rv64imafdc J-VF2-2 riscv64 4 8GiB Hardware rv64imafdc J-VF2-3 riscv64 4 8GiB Hardware rv64imafdc J-VF2-4 riscv64 4 8GiB Hardware rv64imafdc J-VF2-5 riscv64 4 8GiB Hardware rv64imafdc J-VF2-6 riscv64 4 8GiB Hardware rv64imafdc J-HF-1 riscv64 4 8GiB Hardware rv64imafdc J-K230-1 riscv64 1 512MiB Hardware rv64imafdcvxthead Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"Compute Instance Specifications"},{"location":"runner_specs/#specifications-of-compute-instances-in-cloud-v","text":"This document contains the specifications of the compute instances available for users to run builds in Cloud-V. The term \"Compute Instance\", can also be safely interchanged with the terms \"Build Executor\" and \"Runner\". Name String Architecture Cores Memory Compute Instance Type ISA String J-x86-1 (or) J-QMU-1 x86_64 4 8GiB Hardware with application-level emulator J-TESTVM-1 x86_64 4 8GiB Hardware N/A J-RASP4-1 aarch64 4 4GiB Hardware ARMv8-A J-QMS-1 riscv64 2 2GiB QEMU System emulator rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc J-VF1-1 riscv64 2 8GiB Hardware rv64imafdc J-VF1-2 riscv64 2 8GiB Hardware rv64imafdc J-VF1-3 riscv64 2 8GiB Hardware rv64imafdc J-VF2-1 riscv64 4 8GiB Hardware rv64imafdc J-VF2-2 riscv64 4 8GiB Hardware rv64imafdc J-VF2-3 riscv64 4 8GiB Hardware rv64imafdc J-VF2-4 riscv64 4 8GiB Hardware rv64imafdc J-VF2-5 riscv64 4 8GiB Hardware rv64imafdc J-VF2-6 riscv64 4 8GiB Hardware rv64imafdc J-HF-1 riscv64 4 8GiB Hardware rv64imafdc J-K230-1 riscv64 1 512MiB Hardware rv64imafdcvxthead Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"Specifications of compute instances in Cloud-V"},{"location":"tooling_J-HF-1/","text":"Tools on J-HF-1 node This compute instance is Sifive's HiFive Unleased board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 20.04.6 (Focal Fossa) Tool Version Installed from Git 2.25.1 apt OpenJDK 11.0.20.1 apt GCC 10.5.0 apt Python3 3.8.10 apt OpenSSL 1.1.1f apt Ruby 2.7.0p0 apt Go 1.14.3 apt rustc 1.41.0 apt Flex 2.6.4 apt Ninja 1.10.0 apt Bison 3.5.1 apt autoconf 2.69 apt gperf 3.1 apt cmake 3.16.3 apt make 4.2.1 apt automake 1.16.1 apt gfortran 9.4.0 apt openssh-server 8.2p1 apt","title":"J-HF-1"},{"location":"tooling_J-HF-1/#tools-on-j-hf-1-node","text":"This compute instance is Sifive's HiFive Unleased board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 20.04.6 (Focal Fossa) Tool Version Installed from Git 2.25.1 apt OpenJDK 11.0.20.1 apt GCC 10.5.0 apt Python3 3.8.10 apt OpenSSL 1.1.1f apt Ruby 2.7.0p0 apt Go 1.14.3 apt rustc 1.41.0 apt Flex 2.6.4 apt Ninja 1.10.0 apt Bison 3.5.1 apt autoconf 2.69 apt gperf 3.1 apt cmake 3.16.3 apt make 4.2.1 apt automake 1.16.1 apt gfortran 9.4.0 apt openssh-server 8.2p1 apt","title":"Tools on J-HF-1 node"},{"location":"tooling_J-K230-1/","text":"Tools on J-K230-1 node This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.40.1 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.6 apt OpenSSL 3.0.10 apt Ruby 3.1.2p20 apt Go 1.21.1 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.27.4 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.3p1 apt vim 9.0 apt vim 3.3a apt","title":"J-K230-1"},{"location":"tooling_J-K230-1/#tools-on-j-k230-1-node","text":"This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.40.1 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.6 apt OpenSSL 3.0.10 apt Ruby 3.1.2p20 apt Go 1.21.1 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.27.4 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.3p1 apt vim 9.0 apt vim 3.3a apt","title":"Tools on J-K230-1 node"},{"location":"tooling_J-QMS-1/","text":"Tools on J-QMS-1 node This is QEMU system compute instance with 64-bit RISC-V Linux and it has all the packages ONLY for RISC-V architecture Operating System: Ubuntu 22.04.4 LTS (Jammy Jellyfish) QEMU Linux Version: 7.2.90 (v9.0.0-rc0-68-g853546f812) Tool Version Installed from pip 22.0.2 apt Git 2.34.1 apt OpenJDK 19.0.1 apt GCC 11.4.0 apt Python3 3.10.12 apt OpenSSL 3.0.2 apt Ruby 3.0.2p107 apt Go 1.18.8 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.10.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt make 4.3 apt cmake 3.22.1 apt","title":"J-QMS-1"},{"location":"tooling_J-QMS-1/#tools-on-j-qms-1-node","text":"This is QEMU system compute instance with 64-bit RISC-V Linux and it has all the packages ONLY for RISC-V architecture Operating System: Ubuntu 22.04.4 LTS (Jammy Jellyfish) QEMU Linux Version: 7.2.90 (v9.0.0-rc0-68-g853546f812) Tool Version Installed from pip 22.0.2 apt Git 2.34.1 apt OpenJDK 19.0.1 apt GCC 11.4.0 apt Python3 3.10.12 apt OpenSSL 3.0.2 apt Ruby 3.0.2p107 apt Go 1.18.8 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.10.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt make 4.3 apt cmake 3.22.1 apt","title":"Tools on J-QMS-1 node"},{"location":"tooling_J-QMU-1J-VM-1/","text":"Tools on J-x86-1 or J-QMU-1 node Tools which are mentioned for x86 architecture are able to run on J-x86-1 . Tools which are mentioned for RISC-V architecture are able to run on J-QMU-1 . The packages which are supported for QEMU User mode can be used by normal commands once they are loaded. Here PACKAGE_NAME is the package which you want to run on QEMU user mode. Operating System: Debian 11 (bullseye) QEMU User Mode Version: Different Versions (see the table below) Tooling available for J-x86-1 The tools available for J-x86-1 is for use on x86 architecture and these tools do not support execution on RISC-V architecture Tool Versions Installed from Host Architecture Environment Modules Support Git 2.3.0.2 source x86 N/A OpenJDK 19.0.1 apt x86 N/A GCC 10.4.0, 12.2.0 apt x86 Yes Python3 3.8.15, 3.9.2 source x86 Yes Go 1.18.8 apt x86 N/A rustc 1.65.0 source x86 N/A Flex 2.6.4 apt x86 N/A Ninja 1.10.1-1 apt x86 N/A Bison 3.7.5 apt x86 N/A autoconf 2.69 apt x86 N/A gperf 2.2.4 apt x86 N/A spike 1.1.1-dev source x86 Yes Verilator 4.038 apt x86 N/A Sail (riscv_sim_RV64, riscv_sim_RV32) 0.5 source x86 Yes cmake 3.18.4 apt x86 N/A make 4.3 apt x86 N/A ARM EABI GNU toolchain 13.2.Rel1 source x86 Yes qemu-system-arm 8.2.2 source x86 Yes SCons 4.7.0 source x86 Yes Tooling available for J-QMU-1 The tools available for J-QMU-1 is for use on RISC-V architecture and these tools do not support execution on x86 architecture Tool Versions Installed from Host Architecture Environment Modules Support Python3 3.8.15 source RISC-V Yes zlib 1.2.13 source RISC-V N/A OpenSSL 1.1.1r source RISC-V Yes Ruby (without IRB) 3.2.0dev source RISC-V Yes rustc 1.65.0 source RISC-V N/A Flex 2.6.4 source RISC-V yes Ninja 1.12.0.git source RISC-V Yes Bison 3.8.2, 2.3 source RISC-V Yes clang 16.0.0 source RISC-V (cross compiler) Yes riscv-pk 1.0.0-91-g573c858 source RISC-V Yes QEMU User mode and RISC-V GNU Cross compilers From now on RISC-V cross-compilers can only be loaded with their respective QEMU User mode on Cloud-V. This is configured so that there is no confusion between toolchain version and qemu user mode being used because both of these will be \"generally\" taken from the latest releases of nightly builds. Loading a certain RISC-V toolchain using environment modules will automatically load the respective qemu usermode version unless otherwise specified. The loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-glibc/<release-date> And the loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-elf/<release-date> Following table provides relevant information about version of the toolchain and the respective QEMU User mode version (where the release date is mentioned in pattern MMDDYYYY ). Release date GNU Toolchain version (elf and glibc) QEMU Version 03012024 13.2.0 8.2.1 02022024 13.2.0 8.2.1 02022024 13.2.0 8.1.1 Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"J-x86-1 or J-QMU-1"},{"location":"tooling_J-QMU-1J-VM-1/#tools-on-j-x86-1-or-j-qmu-1-node","text":"Tools which are mentioned for x86 architecture are able to run on J-x86-1 . Tools which are mentioned for RISC-V architecture are able to run on J-QMU-1 . The packages which are supported for QEMU User mode can be used by normal commands once they are loaded. Here PACKAGE_NAME is the package which you want to run on QEMU user mode. Operating System: Debian 11 (bullseye) QEMU User Mode Version: Different Versions (see the table below)","title":"Tools on J-x86-1 or J-QMU-1 node"},{"location":"tooling_J-QMU-1J-VM-1/#tooling-available-for-j-x86-1","text":"The tools available for J-x86-1 is for use on x86 architecture and these tools do not support execution on RISC-V architecture Tool Versions Installed from Host Architecture Environment Modules Support Git 2.3.0.2 source x86 N/A OpenJDK 19.0.1 apt x86 N/A GCC 10.4.0, 12.2.0 apt x86 Yes Python3 3.8.15, 3.9.2 source x86 Yes Go 1.18.8 apt x86 N/A rustc 1.65.0 source x86 N/A Flex 2.6.4 apt x86 N/A Ninja 1.10.1-1 apt x86 N/A Bison 3.7.5 apt x86 N/A autoconf 2.69 apt x86 N/A gperf 2.2.4 apt x86 N/A spike 1.1.1-dev source x86 Yes Verilator 4.038 apt x86 N/A Sail (riscv_sim_RV64, riscv_sim_RV32) 0.5 source x86 Yes cmake 3.18.4 apt x86 N/A make 4.3 apt x86 N/A ARM EABI GNU toolchain 13.2.Rel1 source x86 Yes qemu-system-arm 8.2.2 source x86 Yes SCons 4.7.0 source x86 Yes","title":"Tooling available for J-x86-1"},{"location":"tooling_J-QMU-1J-VM-1/#tooling-available-for-j-qmu-1","text":"The tools available for J-QMU-1 is for use on RISC-V architecture and these tools do not support execution on x86 architecture Tool Versions Installed from Host Architecture Environment Modules Support Python3 3.8.15 source RISC-V Yes zlib 1.2.13 source RISC-V N/A OpenSSL 1.1.1r source RISC-V Yes Ruby (without IRB) 3.2.0dev source RISC-V Yes rustc 1.65.0 source RISC-V N/A Flex 2.6.4 source RISC-V yes Ninja 1.12.0.git source RISC-V Yes Bison 3.8.2, 2.3 source RISC-V Yes clang 16.0.0 source RISC-V (cross compiler) Yes riscv-pk 1.0.0-91-g573c858 source RISC-V Yes","title":"Tooling available for J-QMU-1"},{"location":"tooling_J-QMU-1J-VM-1/#qemu-user-mode-and-risc-v-gnu-cross-compilers","text":"From now on RISC-V cross-compilers can only be loaded with their respective QEMU User mode on Cloud-V. This is configured so that there is no confusion between toolchain version and qemu user mode being used because both of these will be \"generally\" taken from the latest releases of nightly builds. Loading a certain RISC-V toolchain using environment modules will automatically load the respective qemu usermode version unless otherwise specified. The loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-glibc/<release-date> And the loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-elf/<release-date> Following table provides relevant information about version of the toolchain and the respective QEMU User mode version (where the release date is mentioned in pattern MMDDYYYY ). Release date GNU Toolchain version (elf and glibc) QEMU Version 03012024 13.2.0 8.2.1 02022024 13.2.0 8.2.1 02022024 13.2.0 8.1.1 Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"QEMU User mode and RISC-V GNU Cross compilers"},{"location":"tooling_J-VF1-x/","text":"Tools on J-VF1-x node This compute instance is Starfive's VisionFive 1 board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 23.04 (Lunar Lobster) Tool Version Installed from Git 2.39.2 apt OpenJDK 21-ea apt GCC 13.1.0 apt Python3 3.11.4 apt OpenSSL 3.0.8 apt Ruby 3.1.2p20 apt Go 1.20.3 apt rustc 1.67.1 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.25.1 apt make 4.3 apt automake 1.16.5 apt gfortran 13.1.0 apt openssh-server 9.0p1 apt","title":"J-VF1-x"},{"location":"tooling_J-VF1-x/#tools-on-j-vf1-x-node","text":"This compute instance is Starfive's VisionFive 1 board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 23.04 (Lunar Lobster) Tool Version Installed from Git 2.39.2 apt OpenJDK 21-ea apt GCC 13.1.0 apt Python3 3.11.4 apt OpenSSL 3.0.8 apt Ruby 3.1.2p20 apt Go 1.20.3 apt rustc 1.67.1 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.25.1 apt make 4.3 apt automake 1.16.5 apt gfortran 13.1.0 apt openssh-server 9.0p1 apt","title":"Tools on J-VF1-x node"},{"location":"tooling_J-VF2-x/","text":"Tools on J-VF2-x node This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.43.0 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.7 apt OpenSSL 3.1.5 apt Ruby 3.1.2p20 apt Go 1.22.0 apt rustc 1.70.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.28.3 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.6p1 apt vim 9.1 apt","title":"J-VF2-x"},{"location":"tooling_J-VF2-x/#tools-on-j-vf2-x-node","text":"This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.43.0 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.7 apt OpenSSL 3.1.5 apt Ruby 3.1.2p20 apt Go 1.22.0 apt rustc 1.70.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.28.3 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.6p1 apt vim 9.1 apt","title":"Tools on J-VF2-x node"}]}
\ No newline at end of file
+{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"Cloud-V Documentation This documentation lists the tooling and necessary information to use Cloud-V for RISC-V application development on RISC-V compute instances provided by Cloud-V Overview Slides: link Youtube Channel: youtube.com/@Cloud-V","title":"Home"},{"location":"#cloud-v-documentation","text":"This documentation lists the tooling and necessary information to use Cloud-V for RISC-V application development on RISC-V compute instances provided by Cloud-V Overview Slides: link Youtube Channel: youtube.com/@Cloud-V","title":"Cloud-V Documentation"},{"location":"Creating_CI_CD_pipeline/","text":"Creating a CI/CD pipeline in Jenkins Pre Requisistes For sake of this documentation, jenkins built-in sample script is used to create and execute a cd/cd pipeline in jenkins. In the built-in script maven is used as M3, so one must install Maven plugin inside jenkins and name it M3 . Usually maven is already present inside jenkins and can be configured from Global Configuration Tools . Following steps demonstrate configuring Maven plugin. Go to Jenkins Dashboard and click on Manage Jenkins In Manage Jenkins , under System Configuration section, click on Global Tool Configuration . In Global Tool Configuration , scroll down to Maven section and click on the respective option under the Maven Section (should be Maven installations\u2026 or Add Maven ). Under Maven installations , enter M3 in \u201cname\u201d text box, check Install Automatically and select Version greater than 3, then click Apply and Save . This should install Maven version 3 and configure as M3 . Steps for Jenkins pipeline creation After installing Jenkins and having all the suggested plugins installed, go to Jenkins dashboard and click on Create Job . On the next page, give your pipeline a name, select Pipeline and click OK . A Configuration page for the pipeline will appear. Select Build Triggers options and General options according to need and scroll down to the Pipeline section. Definition section contains configuration for stages and steps of the pipeline. Under Definition section, you can either choose Pipeline script and try writing your own script or try some sample pipeline (like Hello World , Github+Maven etc) or you could select Pipeline script from SCM and give a github repository containing configurations of Pipeline. Press Save and Apply . This should take you to the Pipeline and you can build the pipeline and if no unresolved dependencies are present, the pipeline should build without any error.","title":"Creating a CI/CD pipeline in Jenkins"},{"location":"Creating_CI_CD_pipeline/#creating-a-cicd-pipeline-in-jenkins","text":"","title":"Creating a CI/CD pipeline in Jenkins"},{"location":"Creating_CI_CD_pipeline/#pre-requisistes","text":"For sake of this documentation, jenkins built-in sample script is used to create and execute a cd/cd pipeline in jenkins. In the built-in script maven is used as M3, so one must install Maven plugin inside jenkins and name it M3 . Usually maven is already present inside jenkins and can be configured from Global Configuration Tools . Following steps demonstrate configuring Maven plugin. Go to Jenkins Dashboard and click on Manage Jenkins In Manage Jenkins , under System Configuration section, click on Global Tool Configuration . In Global Tool Configuration , scroll down to Maven section and click on the respective option under the Maven Section (should be Maven installations\u2026 or Add Maven ). Under Maven installations , enter M3 in \u201cname\u201d text box, check Install Automatically and select Version greater than 3, then click Apply and Save . This should install Maven version 3 and configure as M3 .","title":"Pre Requisistes"},{"location":"Creating_CI_CD_pipeline/#steps-for-jenkins-pipeline-creation","text":"After installing Jenkins and having all the suggested plugins installed, go to Jenkins dashboard and click on Create Job . On the next page, give your pipeline a name, select Pipeline and click OK . A Configuration page for the pipeline will appear. Select Build Triggers options and General options according to need and scroll down to the Pipeline section. Definition section contains configuration for stages and steps of the pipeline. Under Definition section, you can either choose Pipeline script and try writing your own script or try some sample pipeline (like Hello World , Github+Maven etc) or you could select Pipeline script from SCM and give a github repository containing configurations of Pipeline. Press Save and Apply . This should take you to the Pipeline and you can build the pipeline and if no unresolved dependencies are present, the pipeline should build without any error.","title":"Steps for Jenkins pipeline creation"},{"location":"Creating_jenkinsfile/","text":"Creating a Cloud-V CI Pipeline file What is a Cloud-V CI Pipeline file A cloud-v-pipeline file is a Continuous Integration (CI) jenkins pipeline script which is written in Groovy. It describes various stages (and possibly steps) which are executed in the defined pattern. These stages can be written in bash or they can be written in Groovy itself. Mainly there can be two types of Cloud-V pipeline files are of two types: Scripted: Only contains stages Declarative: Contains stages as well as steps (more feature-rich and recommended) This documentation will cover how to create a cloud-v-pipeline file with bash script inside it and run it on various compute instances (which are known as Nodes in jenkins). Jenkins Node In jenkins, node represents a compute instance. In simple words, it is the platform on which our job build is going to run. Jenkins Master There is a jenkins Master node which is actually the compute instance on which Jenkins is installed. It is the node which schedules builds on runners. For security reason, no job is allowed to run on this node. Jenkins Slave Jenkins slave nodes are the compute instances on which our job builds run safely. They may be attached with jenkins master via hardware or they may be connected through remote SSH connection. cloud-v-pipeline file written with bash Simple Hello World cloud-v-pipeline file In Cloud-V, all the platforms are running Linux operating system, so the cloud-v-pipeline should be written in bash. Following script is an example of how can we run a bash script in scripted cloud-v-pipeline . node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } The keyword sh is used to specify a shell script As there is nothing mentioned with node , so the script will run job build on any available compute instance. cloud-v-pipeline for a Specific Node In previous script, the cloud-v-pipeline would run on any compute instances which are available. But in case if someone wants to run a job build on specific node, then a compute instance name must be specified with keyword node . The following script is an example of running above Hello World program on node named hifive_unleashed . node('hifive_unleashed'){ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } cloud-v-pipeline for Cross-Platform Compilation and Execution Cloud-V supports cross-compilation and execution on emulated RISC-V compute instances. Following tools help in cross compilation and cross-platfrom execution: RISC-V GNU Toolchain QEMU user mode (for running standalone binaries) QEMU System (for running application in Linux) An example pipeline script is given below in scripted pipeline. node('x86_runner2'){ checkout scm //Getting content of this repo stage('*** Compilation Phase ***') { // for display purposes //Compiling helloworld.c using bash commands sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out //Cross compiling for RISC-V ''' } stage (' *** Running Binaries ***'){ sh '''#!/bin/bash ./helloworld.out qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out //Running executable on RISC-V emulated platform ''' } } The equivalent declarative pipeline is as follows: pipeline { agent {label \"x86_runner2\"} stages { stage('Clone Repository') { steps('delegate'){ checkout scm //Clones the repository on the local machine } } stage ('Compilation Phase'){ steps{ sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out ''' sh '''#!/bin/bash riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out ''' } } stage ('Running Binaries'){ steps { sh ''' #!/bin/bash ./helloworld.out ''' sh'''#!/bin/bash qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out ''' } } } } Reference Links https://www.jenkins.io/doc/book/pipeline/syntax/","title":"Creating a CI pipeline file"},{"location":"Creating_jenkinsfile/#creating-a-cloud-v-ci-pipeline-file","text":"","title":"Creating a Cloud-V CI Pipeline file"},{"location":"Creating_jenkinsfile/#what-is-a-cloud-v-ci-pipeline-file","text":"A cloud-v-pipeline file is a Continuous Integration (CI) jenkins pipeline script which is written in Groovy. It describes various stages (and possibly steps) which are executed in the defined pattern. These stages can be written in bash or they can be written in Groovy itself. Mainly there can be two types of Cloud-V pipeline files are of two types: Scripted: Only contains stages Declarative: Contains stages as well as steps (more feature-rich and recommended) This documentation will cover how to create a cloud-v-pipeline file with bash script inside it and run it on various compute instances (which are known as Nodes in jenkins).","title":"What is a Cloud-V CI Pipeline file"},{"location":"Creating_jenkinsfile/#jenkins-node","text":"In jenkins, node represents a compute instance. In simple words, it is the platform on which our job build is going to run.","title":"Jenkins Node"},{"location":"Creating_jenkinsfile/#jenkins-master","text":"There is a jenkins Master node which is actually the compute instance on which Jenkins is installed. It is the node which schedules builds on runners. For security reason, no job is allowed to run on this node.","title":"Jenkins Master"},{"location":"Creating_jenkinsfile/#jenkins-slave","text":"Jenkins slave nodes are the compute instances on which our job builds run safely. They may be attached with jenkins master via hardware or they may be connected through remote SSH connection.","title":"Jenkins Slave"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-file-written-with-bash","text":"","title":"cloud-v-pipeline file written with bash"},{"location":"Creating_jenkinsfile/#simple-hello-world-cloud-v-pipeline-file","text":"In Cloud-V, all the platforms are running Linux operating system, so the cloud-v-pipeline should be written in bash. Following script is an example of how can we run a bash script in scripted cloud-v-pipeline . node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } The keyword sh is used to specify a shell script As there is nothing mentioned with node , so the script will run job build on any available compute instance.","title":"Simple Hello World cloud-v-pipeline file"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-for-a-specific-node","text":"In previous script, the cloud-v-pipeline would run on any compute instances which are available. But in case if someone wants to run a job build on specific node, then a compute instance name must be specified with keyword node . The following script is an example of running above Hello World program on node named hifive_unleashed . node('hifive_unleashed'){ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } }","title":"cloud-v-pipeline for a Specific Node"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-for-cross-platform-compilation-and-execution","text":"Cloud-V supports cross-compilation and execution on emulated RISC-V compute instances. Following tools help in cross compilation and cross-platfrom execution: RISC-V GNU Toolchain QEMU user mode (for running standalone binaries) QEMU System (for running application in Linux) An example pipeline script is given below in scripted pipeline. node('x86_runner2'){ checkout scm //Getting content of this repo stage('*** Compilation Phase ***') { // for display purposes //Compiling helloworld.c using bash commands sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out //Cross compiling for RISC-V ''' } stage (' *** Running Binaries ***'){ sh '''#!/bin/bash ./helloworld.out qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out //Running executable on RISC-V emulated platform ''' } } The equivalent declarative pipeline is as follows: pipeline { agent {label \"x86_runner2\"} stages { stage('Clone Repository') { steps('delegate'){ checkout scm //Clones the repository on the local machine } } stage ('Compilation Phase'){ steps{ sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out ''' sh '''#!/bin/bash riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out ''' } } stage ('Running Binaries'){ steps { sh ''' #!/bin/bash ./helloworld.out ''' sh'''#!/bin/bash qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out ''' } } } }","title":"cloud-v-pipeline for Cross-Platform Compilation and Execution"},{"location":"Creating_jenkinsfile/#reference-links","text":"https://www.jenkins.io/doc/book/pipeline/syntax/","title":"Reference Links"},{"location":"Multinode_Pipelines/","text":"Multinode Pipelines One can create multinode pipelines in jenkins freestyle pipeline job as well as in jenkins native pipeline job. In such a pipeline, different stages of the pipeline can run on separate nodes. The jenkins native pipeline job can have two types. Scripted Pipeline Declarative pipeline For the sake of this documentation, two nodes are used: container-node and container-node2 Label In jenkins, label specifies where the job or a stage of the job can run. In jenkins, a label can be explicitly added in the node's configuration so that each time that label is mentioned in a jenkins job, that specific node is used for building the job, or the name of the node can also be used as label in case if no label is added in the node. Creating multinode pipelines in Jenkins native pipeline job Scripted Pipeline For creating a multinode pipeline with jenkins native scripted pipeline job, jenkinsfile can be tweaked. The keyword node can be used to specify the node in which the stages are going to run and this keyword can also be used in between stages. Following screenshot indicates a code in which first stage runs on node named container-node . While the second node runs on node named container-node2 . node ('container-node') { stage ('*** Creating a directory in container-node ***'){ sh '''#!/bin/bash mkdir newdir_container-node-$RANDOM ''' } stage ('*** Creating a directory in container-node2'){ node ('container-node2'){ sh'''#!/bin/bash mkdir newdir_container-node2-$RANDOM ''' } } } Declarative pipeline For a declarative pipeline the keyword label can be used in the agent block. This can either be done at the start of the pipeline after the keyword pipeline or it can be used inside the stages. The following code builds two stages each of which is built in separate node. The keyword none with agent means that the agent is not specified globally for each stage and it should be specified inside each stage. pipeline { agent none // Means no agent specified. This means each node will specify its own agent stages { stage('container-node') { agent{ label \"container-node\" //Selecting container-node for this stage } steps { sh '''#!/bin/bash echo 'Hello container-node' mkdir \"newdir-container-node-$RANDOM\" ''' } } stage('container-node2'){ agent{ label \"container-node2\" //Selecting container-node2 for this stage } steps{ sh'''#!/bin/bash echo ''Hello container-node2 mkdir \"newdir-container-node2-$RANDOM\" ''' } } } } Creating multinode pipelines using Jenkins freestyle jobs Jenkins freestyle jobs can be combined together by mentioning post-build jobs in the freestyle job settings. Freestyle jobs are customizable and offer more options than jenkins native pipeline jobs. Each job represents a stage and each stage has separate settings. One can use jenkins freestyle jobs to run on a separate node by selecting the option Restrict where this project can be run in the General section of the job's configuration. In the Label Expression , the node's name can be mentioned in which to run the job. The following image shows the option from job's configuration. This can be done in all the job's configuration for the specified node.","title":"Multinode Pipelines"},{"location":"Multinode_Pipelines/#multinode-pipelines","text":"One can create multinode pipelines in jenkins freestyle pipeline job as well as in jenkins native pipeline job. In such a pipeline, different stages of the pipeline can run on separate nodes. The jenkins native pipeline job can have two types. Scripted Pipeline Declarative pipeline For the sake of this documentation, two nodes are used: container-node and container-node2","title":"Multinode Pipelines"},{"location":"Multinode_Pipelines/#label","text":"In jenkins, label specifies where the job or a stage of the job can run. In jenkins, a label can be explicitly added in the node's configuration so that each time that label is mentioned in a jenkins job, that specific node is used for building the job, or the name of the node can also be used as label in case if no label is added in the node.","title":"Label"},{"location":"Multinode_Pipelines/#creating-multinode-pipelines-in-jenkins-native-pipeline-job","text":"","title":"Creating multinode pipelines in Jenkins native pipeline job"},{"location":"Multinode_Pipelines/#scripted-pipeline","text":"For creating a multinode pipeline with jenkins native scripted pipeline job, jenkinsfile can be tweaked. The keyword node can be used to specify the node in which the stages are going to run and this keyword can also be used in between stages. Following screenshot indicates a code in which first stage runs on node named container-node . While the second node runs on node named container-node2 . node ('container-node') { stage ('*** Creating a directory in container-node ***'){ sh '''#!/bin/bash mkdir newdir_container-node-$RANDOM ''' } stage ('*** Creating a directory in container-node2'){ node ('container-node2'){ sh'''#!/bin/bash mkdir newdir_container-node2-$RANDOM ''' } } }","title":"Scripted Pipeline"},{"location":"Multinode_Pipelines/#declarative-pipeline","text":"For a declarative pipeline the keyword label can be used in the agent block. This can either be done at the start of the pipeline after the keyword pipeline or it can be used inside the stages. The following code builds two stages each of which is built in separate node. The keyword none with agent means that the agent is not specified globally for each stage and it should be specified inside each stage. pipeline { agent none // Means no agent specified. This means each node will specify its own agent stages { stage('container-node') { agent{ label \"container-node\" //Selecting container-node for this stage } steps { sh '''#!/bin/bash echo 'Hello container-node' mkdir \"newdir-container-node-$RANDOM\" ''' } } stage('container-node2'){ agent{ label \"container-node2\" //Selecting container-node2 for this stage } steps{ sh'''#!/bin/bash echo ''Hello container-node2 mkdir \"newdir-container-node2-$RANDOM\" ''' } } } }","title":"Declarative pipeline"},{"location":"Multinode_Pipelines/#creating-multinode-pipelines-using-jenkins-freestyle-jobs","text":"Jenkins freestyle jobs can be combined together by mentioning post-build jobs in the freestyle job settings. Freestyle jobs are customizable and offer more options than jenkins native pipeline jobs. Each job represents a stage and each stage has separate settings. One can use jenkins freestyle jobs to run on a separate node by selecting the option Restrict where this project can be run in the General section of the job's configuration. In the Label Expression , the node's name can be mentioned in which to run the job. The following image shows the option from job's configuration. This can be done in all the job's configuration for the specified node.","title":"Creating multinode pipelines using Jenkins freestyle jobs"},{"location":"Software_Developer_Guide/","text":"Software Developer Guide for RISC-V CI A software developer is the end-user who will develop or build his/her projects on RISC-V CI infrastructure. This guide will cover all the things a software developer needs to create a project based on Cloud-V Continuous Integration (CI). Pre-requisites GitHub account. GitHub project repository with owner rights. Getting an account for Cloud-V Fill out this google form with all the required information for getting an account on Cloud-V. After this we will get back to you with login credentials. Setting up cloud-v-pipeline inside github project repository Cloud-V will need a cloud-v-pipeline written with jenkinsfile pipeline syntax to start execution of tests/checks (see link ). This pipeline will contain all the stages (and may be steps) of a CI/CD pipeline. This pipeline can be scripted pipeline which will only have stages or it can also be declarative pipeline which may also have steps inside stages. A simple scripted Helloworld pipeline in linux is as follows: node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } Upon execution of such a pipeline, the console output can be viewed as follows. Note: This cloud-v-pipeline should remain same in all the branches and pull requests. Setting credentials for webhook Cloud-V supports webhooks which can trigger the job from external sources such as GitHub. They work in a way such that, if a specified branch is committed or if a pull request is created, the specified job build starts running depending upon the trigger event which is set in build's configuration in Cloud-V. This process requires access token of the repository CREATED BY OWNER OF REPOSITORY on which the webhook is to be set. These credentials can be safely added to Cloud-V without anyone (even administrator) seeing the passwords as follows. Obtaining github access token for repository Navigate to the dashboard of your github account and click on the your github profile picture on the top-right corner on dashboard. Then click on the \"Settings\" from the list. From the left option bar in Settings scroll down and click on \"Developer settings\". Once there, click on \"Personal access tokens\", then click on \"Fine-grained tokens\" from the dropdown list and after that click on \"Generate new token\". This will open the page for setting up new access token. Follow following steps for creating a token: Give your token a meaningful name under \"Token name\" Set expiration date in \"Expiration\" depending upon how long you would like your repository to be integrated with Cloud-V (think of a meaningful upper bound) The \"Resource owner\" should be the owner of the repository who can access all kinds of settings of the repository Under \"Repository access\", check \"Only select repositories\" and then select the repository for which you would like to create the token Under \"Permissions\" section, expand \"Repository Permissions\" and give the following two permissions: \"Read and write\" access to \"Commit statuses\" (Because after the CI has run, Cloud-V will be able to set the status of the commit accordingly) \"Read-only\" access to \"Webhooks\" Configuring repository webhook In GitHub, Go to repository settings which you want to integrate for Cloud-V. Go to Webhooks Click on Add webhook Add Payload URL as https://dash.cloud-v.co/ghprbhook/ Select content type as application/json Check Enable SSL verification In the section Which events would you like to trigger this webhook? check Let me select individual events and check Pul requests as individual events and dont check any other permission. Webhook settings will look something like this: Configurations inside Cloud-V Note: Currently users are not able to see or modify pipeline build configuration inside Jenkins, that is currently managed by administrator. Users are requested to inform administrator about how they want their pipeline configured. We will provide you with Cloud-V credentials on the provided email. Login with provided credentials. Click on the Credentials in the left menu. This will take you to the credentials page. Scroll down to the Stores scoped to Jenkins and click on the System as shown in the image. Click on Global credentials (unrestricted) . Click on Add Credentials . This will take you to the New Credentials page. Select Kind as Username with password . Select Scope as Global (Jenkins, nodes, items, all child items etc) . Enter your GitHub username in Username Enter Password as GitHub personal authentication token (PAT) which can be acquired from Github account settings. ID is optional but you can enter a unique ID . Description can be left empty. But it is recommended to give a suitable but careful description by which administrator will be able to identify and use these credentials to set up github webhook Select Create This process will look something like this Now credentials will be available in the credentials list and will be shown to you as well as administrator as shown in the image below. This will create an option in configurations for using these credentials in github webhook without changing or viewing them. Note the credentials ID (as shown in the image below) and email it to the same administrator email on which you received the login credentials for Cloud-V. It is important that administrator knows the credentials ID because they will use it in the job build configurations. Note: Please make sure to inform the administrator via email that you have added the credentials in Cloud-V Dashboard. Also, send administrator the ID of credentials via email. Requirements for administrator After the above setup is complete from software developer's side, developer will need to provide the administrator with following information. Dependencies for running the project which can be packages which are needed to install in the RISC-V CI environment by administrator. Events for triggering the job build. URL of GitHub repository. Path and name of cloud-v-pipeline file on the provided GitHub repository. Any additional information which should be given for successful execution of job builds.","title":"Getting Started"},{"location":"Software_Developer_Guide/#software-developer-guide-for-risc-v-ci","text":"A software developer is the end-user who will develop or build his/her projects on RISC-V CI infrastructure. This guide will cover all the things a software developer needs to create a project based on Cloud-V Continuous Integration (CI).","title":"Software Developer Guide for RISC-V CI"},{"location":"Software_Developer_Guide/#pre-requisites","text":"GitHub account. GitHub project repository with owner rights.","title":"Pre-requisites"},{"location":"Software_Developer_Guide/#getting-an-account-for-cloud-v","text":"Fill out this google form with all the required information for getting an account on Cloud-V. After this we will get back to you with login credentials.","title":"Getting an account for Cloud-V"},{"location":"Software_Developer_Guide/#setting-up-cloud-v-pipeline-inside-github-project-repository","text":"Cloud-V will need a cloud-v-pipeline written with jenkinsfile pipeline syntax to start execution of tests/checks (see link ). This pipeline will contain all the stages (and may be steps) of a CI/CD pipeline. This pipeline can be scripted pipeline which will only have stages or it can also be declarative pipeline which may also have steps inside stages. A simple scripted Helloworld pipeline in linux is as follows: node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } Upon execution of such a pipeline, the console output can be viewed as follows. Note: This cloud-v-pipeline should remain same in all the branches and pull requests.","title":"Setting up cloud-v-pipeline inside github project repository"},{"location":"Software_Developer_Guide/#setting-credentials-for-webhook","text":"Cloud-V supports webhooks which can trigger the job from external sources such as GitHub. They work in a way such that, if a specified branch is committed or if a pull request is created, the specified job build starts running depending upon the trigger event which is set in build's configuration in Cloud-V. This process requires access token of the repository CREATED BY OWNER OF REPOSITORY on which the webhook is to be set. These credentials can be safely added to Cloud-V without anyone (even administrator) seeing the passwords as follows.","title":"Setting credentials for webhook"},{"location":"Software_Developer_Guide/#obtaining-github-access-token-for-repository","text":"Navigate to the dashboard of your github account and click on the your github profile picture on the top-right corner on dashboard. Then click on the \"Settings\" from the list. From the left option bar in Settings scroll down and click on \"Developer settings\". Once there, click on \"Personal access tokens\", then click on \"Fine-grained tokens\" from the dropdown list and after that click on \"Generate new token\". This will open the page for setting up new access token. Follow following steps for creating a token: Give your token a meaningful name under \"Token name\" Set expiration date in \"Expiration\" depending upon how long you would like your repository to be integrated with Cloud-V (think of a meaningful upper bound) The \"Resource owner\" should be the owner of the repository who can access all kinds of settings of the repository Under \"Repository access\", check \"Only select repositories\" and then select the repository for which you would like to create the token Under \"Permissions\" section, expand \"Repository Permissions\" and give the following two permissions: \"Read and write\" access to \"Commit statuses\" (Because after the CI has run, Cloud-V will be able to set the status of the commit accordingly) \"Read-only\" access to \"Webhooks\"","title":"Obtaining github access token for repository"},{"location":"Software_Developer_Guide/#configuring-repository-webhook","text":"In GitHub, Go to repository settings which you want to integrate for Cloud-V. Go to Webhooks Click on Add webhook Add Payload URL as https://dash.cloud-v.co/ghprbhook/ Select content type as application/json Check Enable SSL verification In the section Which events would you like to trigger this webhook? check Let me select individual events and check Pul requests as individual events and dont check any other permission. Webhook settings will look something like this:","title":"Configuring repository webhook"},{"location":"Software_Developer_Guide/#configurations-inside-cloud-v","text":"Note: Currently users are not able to see or modify pipeline build configuration inside Jenkins, that is currently managed by administrator. Users are requested to inform administrator about how they want their pipeline configured. We will provide you with Cloud-V credentials on the provided email. Login with provided credentials. Click on the Credentials in the left menu. This will take you to the credentials page. Scroll down to the Stores scoped to Jenkins and click on the System as shown in the image. Click on Global credentials (unrestricted) . Click on Add Credentials . This will take you to the New Credentials page. Select Kind as Username with password . Select Scope as Global (Jenkins, nodes, items, all child items etc) . Enter your GitHub username in Username Enter Password as GitHub personal authentication token (PAT) which can be acquired from Github account settings. ID is optional but you can enter a unique ID . Description can be left empty. But it is recommended to give a suitable but careful description by which administrator will be able to identify and use these credentials to set up github webhook Select Create This process will look something like this Now credentials will be available in the credentials list and will be shown to you as well as administrator as shown in the image below. This will create an option in configurations for using these credentials in github webhook without changing or viewing them. Note the credentials ID (as shown in the image below) and email it to the same administrator email on which you received the login credentials for Cloud-V. It is important that administrator knows the credentials ID because they will use it in the job build configurations. Note: Please make sure to inform the administrator via email that you have added the credentials in Cloud-V Dashboard. Also, send administrator the ID of credentials via email.","title":"Configurations inside Cloud-V"},{"location":"Software_Developer_Guide/#requirements-for-administrator","text":"After the above setup is complete from software developer's side, developer will need to provide the administrator with following information. Dependencies for running the project which can be packages which are needed to install in the RISC-V CI environment by administrator. Events for triggering the job build. URL of GitHub repository. Path and name of cloud-v-pipeline file on the provided GitHub repository. Any additional information which should be given for successful execution of job builds.","title":"Requirements for administrator"},{"location":"Tooling/","text":"Tools on Cloud-V Using Environment Modules Users can use environment modules to load different versions of same program. For using environment modules the pattern is as follows: module load <PACKAGENAME/VERSION> Important Note: Be sure to use #!/bin/bash -l instead of #!/bin/bash in CI pipeline file since that is required for environment modules to load For example if you want to load python version 3.9.2 compiled for x86, you will need to use following command: module load python/3.9.2 For packages compiled for RISC-V architecture host, you will need to append _riscv to package name. For example, for python 3.8.15 compiled for RISC-V, following command will be used. module load python_riscv/3.8.15","title":"Using Environment Modules"},{"location":"Tooling/#tools-on-cloud-v","text":"","title":"Tools on Cloud-V"},{"location":"Tooling/#using-environment-modules","text":"Users can use environment modules to load different versions of same program. For using environment modules the pattern is as follows: module load <PACKAGENAME/VERSION> Important Note: Be sure to use #!/bin/bash -l instead of #!/bin/bash in CI pipeline file since that is required for environment modules to load For example if you want to load python version 3.9.2 compiled for x86, you will need to use following command: module load python/3.9.2 For packages compiled for RISC-V architecture host, you will need to append _riscv to package name. For example, for python 3.8.15 compiled for RISC-V, following command will be used. module load python_riscv/3.8.15","title":"Using Environment Modules"},{"location":"jenkins_gitlab_integration/","text":"Integrating GitLab with Jenkins This documentation will cover how to create an integration between jenkins and GitLab. This will allow users to trigger jenkins job when a merge request or a push is detected in GitLab. Pre-requisites GitLab plugin Git plugin GitLab repository with owner's credentials Configuring Jenkins System First jenkins needs to be configured. Go to Dashboard > Manage Jenkins > Configure System Scroll down to Gitlab section Check Enable authentication for '/project' end-point Enter a Connection name . Enter Gitlab host URL as https://gitlab.com/ . In case there is a different domain name, then enter there instead of above url. In Credentials , click on Add then click on Jenkins . In Kind , select GitLab API token . In API token , enter the gitlab personal access token (this will be obtained below while configuring GitLab). Click on Advanced . Click on Test Connection . If everything goes right, it should print success . Configuring GitLab Click on profile avatar in the top right. Click on Edit profile . Click on Access Tokens . Create a new personal access token and copy it (this is the GitLab API token used in above section Configuring Jenkins System ). Go to repository settings. On left-side pane, select Webhooks . Enter GitLab webhook URL (this is explained below in next section). Enter Secret Token (this is explained in the below section). Check desirable trigger options. Click Add webhook . Configuring Jenkins Job Create a jenkins job. On job configuration page, scroll down to Source Code Management . Select Git . In Credentials , add the owner credentials of GitLab repository. This will be Username and Password . Select the appropriate branch (generally it is main ). Scroll down to Build Triggers . Check Build when a change is pushed to GitLab . There will also be a GitLab webhook URL . This is needed in GitLab. This URL will be called as Webhook URL . Click on Advanced in the same option, then scroll down and generate a secret token. This token is also needed. This token will be called as Secret Token . Scroll down to Post-build Actions and select Publish build status to GitLab . Click on Apply and Save . Now whenever there will be a push (or whatever build trigger option is set in jenkins and gitlab webhook), specified jenkins job will be triggered.","title":"Integrating GitLab with Jenkins"},{"location":"jenkins_gitlab_integration/#integrating-gitlab-with-jenkins","text":"This documentation will cover how to create an integration between jenkins and GitLab. This will allow users to trigger jenkins job when a merge request or a push is detected in GitLab.","title":"Integrating GitLab with Jenkins"},{"location":"jenkins_gitlab_integration/#pre-requisites","text":"GitLab plugin Git plugin GitLab repository with owner's credentials","title":"Pre-requisites"},{"location":"jenkins_gitlab_integration/#configuring-jenkins-system","text":"First jenkins needs to be configured. Go to Dashboard > Manage Jenkins > Configure System Scroll down to Gitlab section Check Enable authentication for '/project' end-point Enter a Connection name . Enter Gitlab host URL as https://gitlab.com/ . In case there is a different domain name, then enter there instead of above url. In Credentials , click on Add then click on Jenkins . In Kind , select GitLab API token . In API token , enter the gitlab personal access token (this will be obtained below while configuring GitLab). Click on Advanced . Click on Test Connection . If everything goes right, it should print success .","title":"Configuring Jenkins System"},{"location":"jenkins_gitlab_integration/#configuring-gitlab","text":"Click on profile avatar in the top right. Click on Edit profile . Click on Access Tokens . Create a new personal access token and copy it (this is the GitLab API token used in above section Configuring Jenkins System ). Go to repository settings. On left-side pane, select Webhooks . Enter GitLab webhook URL (this is explained below in next section). Enter Secret Token (this is explained in the below section). Check desirable trigger options. Click Add webhook .","title":"Configuring GitLab"},{"location":"jenkins_gitlab_integration/#configuring-jenkins-job","text":"Create a jenkins job. On job configuration page, scroll down to Source Code Management . Select Git . In Credentials , add the owner credentials of GitLab repository. This will be Username and Password . Select the appropriate branch (generally it is main ). Scroll down to Build Triggers . Check Build when a change is pushed to GitLab . There will also be a GitLab webhook URL . This is needed in GitLab. This URL will be called as Webhook URL . Click on Advanced in the same option, then scroll down and generate a secret token. This token is also needed. This token will be called as Secret Token . Scroll down to Post-build Actions and select Publish build status to GitLab . Click on Apply and Save . Now whenever there will be a push (or whatever build trigger option is set in jenkins and gitlab webhook), specified jenkins job will be triggered.","title":"Configuring Jenkins Job"},{"location":"runner_specs/","text":"Specifications of compute instances in Cloud-V This document contains the specifications of the compute instances available for users to run builds in Cloud-V. The term \"Compute Instance\", can also be safely interchanged with the terms \"Build Executor\" and \"Runner\". Name String Architecture ISA String Cores Memory Compute Instance Type J-x86-1 (or) J-QMU-1 x86_64 N/A 4 8GiB Hardware with application-level emulator J-TESTVM-1 x86_64 N/A 4 8GiB Hardware J-RASP4-1 aarch64 4 4GiB Hardware ARMv8-A J-QMS-1 riscv64 See Ext 1 at bottom 2 2GiB QEMU System emulator J-VF1-1 riscv64 rv64imafdc 2 8GiB Hardware J-VF1-2 riscv64 rv64imafdc 2 8GiB Hardware J-VF1-3 riscv64 rv64imafdc 2 8GiB Hardware J-VF2-1 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-2 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-3 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-4 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-5 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-6 riscv64 rv64imafdc 4 8GiB Hardware J-HF-1 riscv64 rv64imafdc 4 8GiB Hardware J-K230-1 riscv64 rv64imafdcvxthead 1 512MiB Hardware Ext1: rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"Compute Instance Specifications"},{"location":"runner_specs/#specifications-of-compute-instances-in-cloud-v","text":"This document contains the specifications of the compute instances available for users to run builds in Cloud-V. The term \"Compute Instance\", can also be safely interchanged with the terms \"Build Executor\" and \"Runner\". Name String Architecture ISA String Cores Memory Compute Instance Type J-x86-1 (or) J-QMU-1 x86_64 N/A 4 8GiB Hardware with application-level emulator J-TESTVM-1 x86_64 N/A 4 8GiB Hardware J-RASP4-1 aarch64 4 4GiB Hardware ARMv8-A J-QMS-1 riscv64 See Ext 1 at bottom 2 2GiB QEMU System emulator J-VF1-1 riscv64 rv64imafdc 2 8GiB Hardware J-VF1-2 riscv64 rv64imafdc 2 8GiB Hardware J-VF1-3 riscv64 rv64imafdc 2 8GiB Hardware J-VF2-1 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-2 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-3 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-4 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-5 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-6 riscv64 rv64imafdc 4 8GiB Hardware J-HF-1 riscv64 rv64imafdc 4 8GiB Hardware J-K230-1 riscv64 rv64imafdcvxthead 1 512MiB Hardware Ext1: rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"Specifications of compute instances in Cloud-V"},{"location":"tooling_J-HF-1/","text":"Tools on J-HF-1 node This compute instance is Sifive's HiFive Unleased board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 20.04.6 (Focal Fossa) Tool Version Installed from Git 2.25.1 apt OpenJDK 11.0.20.1 apt GCC 10.5.0 apt Python3 3.8.10 apt OpenSSL 1.1.1f apt Ruby 2.7.0p0 apt Go 1.14.3 apt rustc 1.41.0 apt Flex 2.6.4 apt Ninja 1.10.0 apt Bison 3.5.1 apt autoconf 2.69 apt gperf 3.1 apt cmake 3.16.3 apt make 4.2.1 apt automake 1.16.1 apt gfortran 9.4.0 apt openssh-server 8.2p1 apt","title":"J-HF-1"},{"location":"tooling_J-HF-1/#tools-on-j-hf-1-node","text":"This compute instance is Sifive's HiFive Unleased board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 20.04.6 (Focal Fossa) Tool Version Installed from Git 2.25.1 apt OpenJDK 11.0.20.1 apt GCC 10.5.0 apt Python3 3.8.10 apt OpenSSL 1.1.1f apt Ruby 2.7.0p0 apt Go 1.14.3 apt rustc 1.41.0 apt Flex 2.6.4 apt Ninja 1.10.0 apt Bison 3.5.1 apt autoconf 2.69 apt gperf 3.1 apt cmake 3.16.3 apt make 4.2.1 apt automake 1.16.1 apt gfortran 9.4.0 apt openssh-server 8.2p1 apt","title":"Tools on J-HF-1 node"},{"location":"tooling_J-K230-1/","text":"Tools on J-K230-1 node This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.40.1 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.6 apt OpenSSL 3.0.10 apt Ruby 3.1.2p20 apt Go 1.21.1 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.27.4 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.3p1 apt vim 9.0 apt vim 3.3a apt","title":"J-K230-1"},{"location":"tooling_J-K230-1/#tools-on-j-k230-1-node","text":"This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.40.1 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.6 apt OpenSSL 3.0.10 apt Ruby 3.1.2p20 apt Go 1.21.1 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.27.4 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.3p1 apt vim 9.0 apt vim 3.3a apt","title":"Tools on J-K230-1 node"},{"location":"tooling_J-QMS-1/","text":"Tools on J-QMS-1 node This is QEMU system compute instance with 64-bit RISC-V Linux and it has all the packages ONLY for RISC-V architecture Operating System: Ubuntu 22.04.4 LTS (Jammy Jellyfish) QEMU Linux Version: 7.2.90 (v9.0.0-rc0-68-g853546f812) Tool Version Installed from pip 22.0.2 apt Git 2.34.1 apt OpenJDK 19.0.1 apt GCC 11.4.0 apt Python3 3.10.12 apt OpenSSL 3.0.2 apt Ruby 3.0.2p107 apt Go 1.18.8 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.10.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt make 4.3 apt cmake 3.22.1 apt","title":"J-QMS-1"},{"location":"tooling_J-QMS-1/#tools-on-j-qms-1-node","text":"This is QEMU system compute instance with 64-bit RISC-V Linux and it has all the packages ONLY for RISC-V architecture Operating System: Ubuntu 22.04.4 LTS (Jammy Jellyfish) QEMU Linux Version: 7.2.90 (v9.0.0-rc0-68-g853546f812) Tool Version Installed from pip 22.0.2 apt Git 2.34.1 apt OpenJDK 19.0.1 apt GCC 11.4.0 apt Python3 3.10.12 apt OpenSSL 3.0.2 apt Ruby 3.0.2p107 apt Go 1.18.8 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.10.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt make 4.3 apt cmake 3.22.1 apt","title":"Tools on J-QMS-1 node"},{"location":"tooling_J-QMU-1J-VM-1/","text":"Tools on J-x86-1 or J-QMU-1 node Tools which are mentioned for x86 architecture are able to run on J-x86-1 . Tools which are mentioned for RISC-V architecture are able to run on J-QMU-1 . The packages which are supported for QEMU User mode can be used by normal commands once they are loaded. Here PACKAGE_NAME is the package which you want to run on QEMU user mode. Operating System: Debian 11 (bullseye) QEMU User Mode Version: Different Versions (see the table below) Tooling available for J-x86-1 The tools available for J-x86-1 is for use on x86 architecture and these tools do not support execution on RISC-V architecture Tool Versions Installed from Host Architecture Environment Modules Support Git 2.3.0.2 source x86 N/A OpenJDK 19.0.1 apt x86 N/A GCC 10.4.0, 12.2.0 apt x86 Yes Python3 3.8.15, 3.9.2 source x86 Yes Go 1.18.8 apt x86 N/A rustc 1.65.0 source x86 N/A Flex 2.6.4 apt x86 N/A Ninja 1.10.1-1 apt x86 N/A Bison 3.7.5 apt x86 N/A autoconf 2.69 apt x86 N/A gperf 2.2.4 apt x86 N/A spike 1.1.1-dev source x86 Yes Verilator 4.038 apt x86 N/A Sail (riscv_sim_RV64, riscv_sim_RV32) 0.5 source x86 Yes cmake 3.18.4 apt x86 N/A make 4.3 apt x86 N/A ARM EABI GNU toolchain 13.2.Rel1 source x86 Yes qemu-system-arm 8.2.2 source x86 Yes SCons 4.7.0 source x86 Yes Tooling available for J-QMU-1 The tools available for J-QMU-1 is for use on RISC-V architecture and these tools do not support execution on x86 architecture Tool Versions Installed from Host Architecture Environment Modules Support Python3 3.8.15 source RISC-V Yes zlib 1.2.13 source RISC-V N/A OpenSSL 1.1.1r source RISC-V Yes Ruby (without IRB) 3.2.0dev source RISC-V Yes rustc 1.65.0 source RISC-V N/A Flex 2.6.4 source RISC-V yes Ninja 1.12.0.git source RISC-V Yes Bison 3.8.2, 2.3 source RISC-V Yes clang 16.0.0 source RISC-V (cross compiler) Yes riscv-pk 1.0.0-91-g573c858 source RISC-V Yes QEMU User mode and RISC-V GNU Cross compilers From now on RISC-V cross-compilers can only be loaded with their respective QEMU User mode on Cloud-V. This is configured so that there is no confusion between toolchain version and qemu user mode being used because both of these will be \"generally\" taken from the latest releases of nightly builds. Loading a certain RISC-V toolchain using environment modules will automatically load the respective qemu usermode version unless otherwise specified. The loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-glibc/<release-date> And the loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-elf/<release-date> Following table provides relevant information about version of the toolchain and the respective QEMU User mode version (where the release date is mentioned in pattern MMDDYYYY ). Release date GNU Toolchain version (elf and glibc) QEMU Version 03012024 13.2.0 8.2.1 02022024 13.2.0 8.2.1 02022024 13.2.0 8.1.1 Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"J-x86-1 or J-QMU-1"},{"location":"tooling_J-QMU-1J-VM-1/#tools-on-j-x86-1-or-j-qmu-1-node","text":"Tools which are mentioned for x86 architecture are able to run on J-x86-1 . Tools which are mentioned for RISC-V architecture are able to run on J-QMU-1 . The packages which are supported for QEMU User mode can be used by normal commands once they are loaded. Here PACKAGE_NAME is the package which you want to run on QEMU user mode. Operating System: Debian 11 (bullseye) QEMU User Mode Version: Different Versions (see the table below)","title":"Tools on J-x86-1 or J-QMU-1 node"},{"location":"tooling_J-QMU-1J-VM-1/#tooling-available-for-j-x86-1","text":"The tools available for J-x86-1 is for use on x86 architecture and these tools do not support execution on RISC-V architecture Tool Versions Installed from Host Architecture Environment Modules Support Git 2.3.0.2 source x86 N/A OpenJDK 19.0.1 apt x86 N/A GCC 10.4.0, 12.2.0 apt x86 Yes Python3 3.8.15, 3.9.2 source x86 Yes Go 1.18.8 apt x86 N/A rustc 1.65.0 source x86 N/A Flex 2.6.4 apt x86 N/A Ninja 1.10.1-1 apt x86 N/A Bison 3.7.5 apt x86 N/A autoconf 2.69 apt x86 N/A gperf 2.2.4 apt x86 N/A spike 1.1.1-dev source x86 Yes Verilator 4.038 apt x86 N/A Sail (riscv_sim_RV64, riscv_sim_RV32) 0.5 source x86 Yes cmake 3.18.4 apt x86 N/A make 4.3 apt x86 N/A ARM EABI GNU toolchain 13.2.Rel1 source x86 Yes qemu-system-arm 8.2.2 source x86 Yes SCons 4.7.0 source x86 Yes","title":"Tooling available for J-x86-1"},{"location":"tooling_J-QMU-1J-VM-1/#tooling-available-for-j-qmu-1","text":"The tools available for J-QMU-1 is for use on RISC-V architecture and these tools do not support execution on x86 architecture Tool Versions Installed from Host Architecture Environment Modules Support Python3 3.8.15 source RISC-V Yes zlib 1.2.13 source RISC-V N/A OpenSSL 1.1.1r source RISC-V Yes Ruby (without IRB) 3.2.0dev source RISC-V Yes rustc 1.65.0 source RISC-V N/A Flex 2.6.4 source RISC-V yes Ninja 1.12.0.git source RISC-V Yes Bison 3.8.2, 2.3 source RISC-V Yes clang 16.0.0 source RISC-V (cross compiler) Yes riscv-pk 1.0.0-91-g573c858 source RISC-V Yes","title":"Tooling available for J-QMU-1"},{"location":"tooling_J-QMU-1J-VM-1/#qemu-user-mode-and-risc-v-gnu-cross-compilers","text":"From now on RISC-V cross-compilers can only be loaded with their respective QEMU User mode on Cloud-V. This is configured so that there is no confusion between toolchain version and qemu user mode being used because both of these will be \"generally\" taken from the latest releases of nightly builds. Loading a certain RISC-V toolchain using environment modules will automatically load the respective qemu usermode version unless otherwise specified. The loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-glibc/<release-date> And the loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-elf/<release-date> Following table provides relevant information about version of the toolchain and the respective QEMU User mode version (where the release date is mentioned in pattern MMDDYYYY ). Release date GNU Toolchain version (elf and glibc) QEMU Version 03012024 13.2.0 8.2.1 02022024 13.2.0 8.2.1 02022024 13.2.0 8.1.1 Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"QEMU User mode and RISC-V GNU Cross compilers"},{"location":"tooling_J-VF1-x/","text":"Tools on J-VF1-x node This compute instance is Starfive's VisionFive 1 board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 23.04 (Lunar Lobster) Tool Version Installed from Git 2.39.2 apt OpenJDK 21-ea apt GCC 13.1.0 apt Python3 3.11.4 apt OpenSSL 3.0.8 apt Ruby 3.1.2p20 apt Go 1.20.3 apt rustc 1.67.1 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.25.1 apt make 4.3 apt automake 1.16.5 apt gfortran 13.1.0 apt openssh-server 9.0p1 apt","title":"J-VF1-x"},{"location":"tooling_J-VF1-x/#tools-on-j-vf1-x-node","text":"This compute instance is Starfive's VisionFive 1 board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 23.04 (Lunar Lobster) Tool Version Installed from Git 2.39.2 apt OpenJDK 21-ea apt GCC 13.1.0 apt Python3 3.11.4 apt OpenSSL 3.0.8 apt Ruby 3.1.2p20 apt Go 1.20.3 apt rustc 1.67.1 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.25.1 apt make 4.3 apt automake 1.16.5 apt gfortran 13.1.0 apt openssh-server 9.0p1 apt","title":"Tools on J-VF1-x node"},{"location":"tooling_J-VF2-x/","text":"Tools on J-VF2-x node This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.43.0 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.7 apt OpenSSL 3.1.5 apt Ruby 3.1.2p20 apt Go 1.22.0 apt rustc 1.70.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.28.3 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.6p1 apt vim 9.1 apt","title":"J-VF2-x"},{"location":"tooling_J-VF2-x/#tools-on-j-vf2-x-node","text":"This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.43.0 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.7 apt OpenSSL 3.1.5 apt Ruby 3.1.2p20 apt Go 1.22.0 apt rustc 1.70.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.28.3 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.6p1 apt vim 9.1 apt","title":"Tools on J-VF2-x node"}]}
\ No newline at end of file
diff --git a/docs/sitemap.xml.gz b/docs/sitemap.xml.gz
index 14e1119aaea4a479101a7b11c9115a8faa688b6a..1e35ca1ec9cfc7e80e565c789e43d77262f597f1 100644
GIT binary patch
delta 12
Tcmb=gXOr*d;LvKA$W{pe7Lo&b

delta 12
Tcmb=gXOr*d;P9xL$W{pe7Z3xH

diff --git a/mkdocs_src/docs/runner_specs.md b/mkdocs_src/docs/runner_specs.md
index 39e3937..2b7e93e 100644
--- a/mkdocs_src/docs/runner_specs.md
+++ b/mkdocs_src/docs/runner_specs.md
@@ -2,22 +2,24 @@
 
 This document contains the specifications of the compute instances available for users to run builds in Cloud-V. The term "Compute Instance", can also be safely interchanged with the terms "Build Executor" and "Runner".
 
-| Name String | Architecture | Cores | Memory | Compute Instance Type | ISA String |
+| Name String | Architecture | ISA String | Cores | Memory | Compute Instance Type |
 | ---- | ------- | -------------- | ------------ | ------------------ | ---- |
-| J-x86-1 (or) J-QMU-1 | x86_64 | 4 | 8GiB | Hardware with application-level emulator |
-| J-TESTVM-1 | x86_64 | 4 | 8GiB | Hardware | N/A |
+| J-x86-1 (or) J-QMU-1 | x86_64 | N/A | 4 | 8GiB | Hardware with application-level emulator |
+| J-TESTVM-1 | x86_64 | N/A | 4 | 8GiB | Hardware |
 | J-RASP4-1 | aarch64 | 4 | 4GiB | Hardware | ARMv8-A |
-| J-QMS-1 | riscv64 | 2 | 2GiB | QEMU System emulator | rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc |
-| J-VF1-1 | riscv64 | 2 | 8GiB | Hardware | rv64imafdc |
-| J-VF1-2 | riscv64 | 2 | 8GiB | Hardware | rv64imafdc |
-| J-VF1-3 | riscv64 | 2 | 8GiB | Hardware | rv64imafdc |
-| J-VF2-1 | riscv64 | 4 | 8GiB | Hardware | rv64imafdc |
-| J-VF2-2 | riscv64 | 4 | 8GiB | Hardware | rv64imafdc |
-| J-VF2-3 | riscv64 | 4 | 8GiB | Hardware | rv64imafdc |
-| J-VF2-4 | riscv64 | 4 | 8GiB | Hardware | rv64imafdc |
-| J-VF2-5 | riscv64 | 4 | 8GiB | Hardware | rv64imafdc |
-| J-VF2-6 | riscv64 | 4 | 8GiB | Hardware | rv64imafdc |
-| J-HF-1 | riscv64 | 4 | 8GiB | Hardware | rv64imafdc |
-| J-K230-1 | riscv64 | 1 | 512MiB | Hardware | rv64imafdcvxthead |
+| J-QMS-1 | riscv64 | See Ext 1 at bottom | 2 | 2GiB | QEMU System emulator |
+| J-VF1-1 | riscv64 | rv64imafdc | 2 | 8GiB | Hardware |
+| J-VF1-2 | riscv64 | rv64imafdc | 2 | 8GiB | Hardware |
+| J-VF1-3 | riscv64 | rv64imafdc | 2 | 8GiB | Hardware |
+| J-VF2-1 | riscv64 | rv64imafdc | 4 | 8GiB | Hardware |
+| J-VF2-2 | riscv64 | rv64imafdc | 4 | 8GiB | Hardware |
+| J-VF2-3 | riscv64 | rv64imafdc | 4 | 8GiB | Hardware |
+| J-VF2-4 | riscv64 | rv64imafdc | 4 | 8GiB | Hardware |
+| J-VF2-5 | riscv64 | rv64imafdc | 4 | 8GiB | Hardware |
+| J-VF2-6 | riscv64 | rv64imafdc | 4 | 8GiB | Hardware |
+| J-HF-1 | riscv64 | rv64imafdc | 4 | 8GiB | Hardware |
+| J-K230-1 | riscv64 | rv64imafdcvxthead | 1 | 512MiB | Hardware |
+
+***Ext1:** rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc*
 
 ***Note:** The `J-QMU-1` and `J-x86-1` are one and the same runner. The purpose of creating two separate executors for same hardware is that `J-x86-1` is supposed to be specifically for x86 architecture whereas `J-QMU-1` is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for `J-x86-1` can also be used for `J-QMU-1`*

From 993f7ddccf3def197ecc5198b6de2a351bdfedc9 Mon Sep 17 00:00:00 2001
From: Ali Tariq <alitariq4589@gmail.com>
Date: Thu, 9 May 2024 12:52:23 +0500
Subject: [PATCH 4/4] Re arranged table entries

---
 docs/index.html                 |   2 +-
 docs/runner_specs/index.html    |   2 +-
 docs/search/search_index.json   |   2 +-
 docs/sitemap.xml.gz             | Bin 127 -> 127 bytes
 mkdocs_src/docs/runner_specs.md |   2 +-
 5 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/index.html b/docs/index.html
index 1119caa..6a9bbb2 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -149,5 +149,5 @@ <h1 id="cloud-v-documentation">Cloud-V Documentation</h1>
 
 <!--
 MkDocs version : 1.5.3
-Build Date UTC : 2024-05-09 07:50:02.339791+00:00
+Build Date UTC : 2024-05-09 07:52:14.942979+00:00
 -->
diff --git a/docs/runner_specs/index.html b/docs/runner_specs/index.html
index d0a3c6b..68117a4 100644
--- a/docs/runner_specs/index.html
+++ b/docs/runner_specs/index.html
@@ -130,10 +130,10 @@ <h1 id="specifications-of-compute-instances-in-cloud-v">Specifications of comput
 <tr>
 <td>J-RASP4-1</td>
 <td>aarch64</td>
+<td>ARMv8-A</td>
 <td>4</td>
 <td>4GiB</td>
 <td>Hardware</td>
-<td>ARMv8-A</td>
 </tr>
 <tr>
 <td>J-QMS-1</td>
diff --git a/docs/search/search_index.json b/docs/search/search_index.json
index 109a81a..6dc9f6e 100644
--- a/docs/search/search_index.json
+++ b/docs/search/search_index.json
@@ -1 +1 @@
-{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"Cloud-V Documentation This documentation lists the tooling and necessary information to use Cloud-V for RISC-V application development on RISC-V compute instances provided by Cloud-V Overview Slides: link Youtube Channel: youtube.com/@Cloud-V","title":"Home"},{"location":"#cloud-v-documentation","text":"This documentation lists the tooling and necessary information to use Cloud-V for RISC-V application development on RISC-V compute instances provided by Cloud-V Overview Slides: link Youtube Channel: youtube.com/@Cloud-V","title":"Cloud-V Documentation"},{"location":"Creating_CI_CD_pipeline/","text":"Creating a CI/CD pipeline in Jenkins Pre Requisistes For sake of this documentation, jenkins built-in sample script is used to create and execute a cd/cd pipeline in jenkins. In the built-in script maven is used as M3, so one must install Maven plugin inside jenkins and name it M3 . Usually maven is already present inside jenkins and can be configured from Global Configuration Tools . Following steps demonstrate configuring Maven plugin. Go to Jenkins Dashboard and click on Manage Jenkins In Manage Jenkins , under System Configuration section, click on Global Tool Configuration . In Global Tool Configuration , scroll down to Maven section and click on the respective option under the Maven Section (should be Maven installations\u2026 or Add Maven ). Under Maven installations , enter M3 in \u201cname\u201d text box, check Install Automatically and select Version greater than 3, then click Apply and Save . This should install Maven version 3 and configure as M3 . Steps for Jenkins pipeline creation After installing Jenkins and having all the suggested plugins installed, go to Jenkins dashboard and click on Create Job . On the next page, give your pipeline a name, select Pipeline and click OK . A Configuration page for the pipeline will appear. Select Build Triggers options and General options according to need and scroll down to the Pipeline section. Definition section contains configuration for stages and steps of the pipeline. Under Definition section, you can either choose Pipeline script and try writing your own script or try some sample pipeline (like Hello World , Github+Maven etc) or you could select Pipeline script from SCM and give a github repository containing configurations of Pipeline. Press Save and Apply . This should take you to the Pipeline and you can build the pipeline and if no unresolved dependencies are present, the pipeline should build without any error.","title":"Creating a CI/CD pipeline in Jenkins"},{"location":"Creating_CI_CD_pipeline/#creating-a-cicd-pipeline-in-jenkins","text":"","title":"Creating a CI/CD pipeline in Jenkins"},{"location":"Creating_CI_CD_pipeline/#pre-requisistes","text":"For sake of this documentation, jenkins built-in sample script is used to create and execute a cd/cd pipeline in jenkins. In the built-in script maven is used as M3, so one must install Maven plugin inside jenkins and name it M3 . Usually maven is already present inside jenkins and can be configured from Global Configuration Tools . Following steps demonstrate configuring Maven plugin. Go to Jenkins Dashboard and click on Manage Jenkins In Manage Jenkins , under System Configuration section, click on Global Tool Configuration . In Global Tool Configuration , scroll down to Maven section and click on the respective option under the Maven Section (should be Maven installations\u2026 or Add Maven ). Under Maven installations , enter M3 in \u201cname\u201d text box, check Install Automatically and select Version greater than 3, then click Apply and Save . This should install Maven version 3 and configure as M3 .","title":"Pre Requisistes"},{"location":"Creating_CI_CD_pipeline/#steps-for-jenkins-pipeline-creation","text":"After installing Jenkins and having all the suggested plugins installed, go to Jenkins dashboard and click on Create Job . On the next page, give your pipeline a name, select Pipeline and click OK . A Configuration page for the pipeline will appear. Select Build Triggers options and General options according to need and scroll down to the Pipeline section. Definition section contains configuration for stages and steps of the pipeline. Under Definition section, you can either choose Pipeline script and try writing your own script or try some sample pipeline (like Hello World , Github+Maven etc) or you could select Pipeline script from SCM and give a github repository containing configurations of Pipeline. Press Save and Apply . This should take you to the Pipeline and you can build the pipeline and if no unresolved dependencies are present, the pipeline should build without any error.","title":"Steps for Jenkins pipeline creation"},{"location":"Creating_jenkinsfile/","text":"Creating a Cloud-V CI Pipeline file What is a Cloud-V CI Pipeline file A cloud-v-pipeline file is a Continuous Integration (CI) jenkins pipeline script which is written in Groovy. It describes various stages (and possibly steps) which are executed in the defined pattern. These stages can be written in bash or they can be written in Groovy itself. Mainly there can be two types of Cloud-V pipeline files are of two types: Scripted: Only contains stages Declarative: Contains stages as well as steps (more feature-rich and recommended) This documentation will cover how to create a cloud-v-pipeline file with bash script inside it and run it on various compute instances (which are known as Nodes in jenkins). Jenkins Node In jenkins, node represents a compute instance. In simple words, it is the platform on which our job build is going to run. Jenkins Master There is a jenkins Master node which is actually the compute instance on which Jenkins is installed. It is the node which schedules builds on runners. For security reason, no job is allowed to run on this node. Jenkins Slave Jenkins slave nodes are the compute instances on which our job builds run safely. They may be attached with jenkins master via hardware or they may be connected through remote SSH connection. cloud-v-pipeline file written with bash Simple Hello World cloud-v-pipeline file In Cloud-V, all the platforms are running Linux operating system, so the cloud-v-pipeline should be written in bash. Following script is an example of how can we run a bash script in scripted cloud-v-pipeline . node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } The keyword sh is used to specify a shell script As there is nothing mentioned with node , so the script will run job build on any available compute instance. cloud-v-pipeline for a Specific Node In previous script, the cloud-v-pipeline would run on any compute instances which are available. But in case if someone wants to run a job build on specific node, then a compute instance name must be specified with keyword node . The following script is an example of running above Hello World program on node named hifive_unleashed . node('hifive_unleashed'){ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } cloud-v-pipeline for Cross-Platform Compilation and Execution Cloud-V supports cross-compilation and execution on emulated RISC-V compute instances. Following tools help in cross compilation and cross-platfrom execution: RISC-V GNU Toolchain QEMU user mode (for running standalone binaries) QEMU System (for running application in Linux) An example pipeline script is given below in scripted pipeline. node('x86_runner2'){ checkout scm //Getting content of this repo stage('*** Compilation Phase ***') { // for display purposes //Compiling helloworld.c using bash commands sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out //Cross compiling for RISC-V ''' } stage (' *** Running Binaries ***'){ sh '''#!/bin/bash ./helloworld.out qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out //Running executable on RISC-V emulated platform ''' } } The equivalent declarative pipeline is as follows: pipeline { agent {label \"x86_runner2\"} stages { stage('Clone Repository') { steps('delegate'){ checkout scm //Clones the repository on the local machine } } stage ('Compilation Phase'){ steps{ sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out ''' sh '''#!/bin/bash riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out ''' } } stage ('Running Binaries'){ steps { sh ''' #!/bin/bash ./helloworld.out ''' sh'''#!/bin/bash qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out ''' } } } } Reference Links https://www.jenkins.io/doc/book/pipeline/syntax/","title":"Creating a CI pipeline file"},{"location":"Creating_jenkinsfile/#creating-a-cloud-v-ci-pipeline-file","text":"","title":"Creating a Cloud-V CI Pipeline file"},{"location":"Creating_jenkinsfile/#what-is-a-cloud-v-ci-pipeline-file","text":"A cloud-v-pipeline file is a Continuous Integration (CI) jenkins pipeline script which is written in Groovy. It describes various stages (and possibly steps) which are executed in the defined pattern. These stages can be written in bash or they can be written in Groovy itself. Mainly there can be two types of Cloud-V pipeline files are of two types: Scripted: Only contains stages Declarative: Contains stages as well as steps (more feature-rich and recommended) This documentation will cover how to create a cloud-v-pipeline file with bash script inside it and run it on various compute instances (which are known as Nodes in jenkins).","title":"What is a Cloud-V CI Pipeline file"},{"location":"Creating_jenkinsfile/#jenkins-node","text":"In jenkins, node represents a compute instance. In simple words, it is the platform on which our job build is going to run.","title":"Jenkins Node"},{"location":"Creating_jenkinsfile/#jenkins-master","text":"There is a jenkins Master node which is actually the compute instance on which Jenkins is installed. It is the node which schedules builds on runners. For security reason, no job is allowed to run on this node.","title":"Jenkins Master"},{"location":"Creating_jenkinsfile/#jenkins-slave","text":"Jenkins slave nodes are the compute instances on which our job builds run safely. They may be attached with jenkins master via hardware or they may be connected through remote SSH connection.","title":"Jenkins Slave"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-file-written-with-bash","text":"","title":"cloud-v-pipeline file written with bash"},{"location":"Creating_jenkinsfile/#simple-hello-world-cloud-v-pipeline-file","text":"In Cloud-V, all the platforms are running Linux operating system, so the cloud-v-pipeline should be written in bash. Following script is an example of how can we run a bash script in scripted cloud-v-pipeline . node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } The keyword sh is used to specify a shell script As there is nothing mentioned with node , so the script will run job build on any available compute instance.","title":"Simple Hello World cloud-v-pipeline file"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-for-a-specific-node","text":"In previous script, the cloud-v-pipeline would run on any compute instances which are available. But in case if someone wants to run a job build on specific node, then a compute instance name must be specified with keyword node . The following script is an example of running above Hello World program on node named hifive_unleashed . node('hifive_unleashed'){ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } }","title":"cloud-v-pipeline for a Specific Node"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-for-cross-platform-compilation-and-execution","text":"Cloud-V supports cross-compilation and execution on emulated RISC-V compute instances. Following tools help in cross compilation and cross-platfrom execution: RISC-V GNU Toolchain QEMU user mode (for running standalone binaries) QEMU System (for running application in Linux) An example pipeline script is given below in scripted pipeline. node('x86_runner2'){ checkout scm //Getting content of this repo stage('*** Compilation Phase ***') { // for display purposes //Compiling helloworld.c using bash commands sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out //Cross compiling for RISC-V ''' } stage (' *** Running Binaries ***'){ sh '''#!/bin/bash ./helloworld.out qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out //Running executable on RISC-V emulated platform ''' } } The equivalent declarative pipeline is as follows: pipeline { agent {label \"x86_runner2\"} stages { stage('Clone Repository') { steps('delegate'){ checkout scm //Clones the repository on the local machine } } stage ('Compilation Phase'){ steps{ sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out ''' sh '''#!/bin/bash riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out ''' } } stage ('Running Binaries'){ steps { sh ''' #!/bin/bash ./helloworld.out ''' sh'''#!/bin/bash qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out ''' } } } }","title":"cloud-v-pipeline for Cross-Platform Compilation and Execution"},{"location":"Creating_jenkinsfile/#reference-links","text":"https://www.jenkins.io/doc/book/pipeline/syntax/","title":"Reference Links"},{"location":"Multinode_Pipelines/","text":"Multinode Pipelines One can create multinode pipelines in jenkins freestyle pipeline job as well as in jenkins native pipeline job. In such a pipeline, different stages of the pipeline can run on separate nodes. The jenkins native pipeline job can have two types. Scripted Pipeline Declarative pipeline For the sake of this documentation, two nodes are used: container-node and container-node2 Label In jenkins, label specifies where the job or a stage of the job can run. In jenkins, a label can be explicitly added in the node's configuration so that each time that label is mentioned in a jenkins job, that specific node is used for building the job, or the name of the node can also be used as label in case if no label is added in the node. Creating multinode pipelines in Jenkins native pipeline job Scripted Pipeline For creating a multinode pipeline with jenkins native scripted pipeline job, jenkinsfile can be tweaked. The keyword node can be used to specify the node in which the stages are going to run and this keyword can also be used in between stages. Following screenshot indicates a code in which first stage runs on node named container-node . While the second node runs on node named container-node2 . node ('container-node') { stage ('*** Creating a directory in container-node ***'){ sh '''#!/bin/bash mkdir newdir_container-node-$RANDOM ''' } stage ('*** Creating a directory in container-node2'){ node ('container-node2'){ sh'''#!/bin/bash mkdir newdir_container-node2-$RANDOM ''' } } } Declarative pipeline For a declarative pipeline the keyword label can be used in the agent block. This can either be done at the start of the pipeline after the keyword pipeline or it can be used inside the stages. The following code builds two stages each of which is built in separate node. The keyword none with agent means that the agent is not specified globally for each stage and it should be specified inside each stage. pipeline { agent none // Means no agent specified. This means each node will specify its own agent stages { stage('container-node') { agent{ label \"container-node\" //Selecting container-node for this stage } steps { sh '''#!/bin/bash echo 'Hello container-node' mkdir \"newdir-container-node-$RANDOM\" ''' } } stage('container-node2'){ agent{ label \"container-node2\" //Selecting container-node2 for this stage } steps{ sh'''#!/bin/bash echo ''Hello container-node2 mkdir \"newdir-container-node2-$RANDOM\" ''' } } } } Creating multinode pipelines using Jenkins freestyle jobs Jenkins freestyle jobs can be combined together by mentioning post-build jobs in the freestyle job settings. Freestyle jobs are customizable and offer more options than jenkins native pipeline jobs. Each job represents a stage and each stage has separate settings. One can use jenkins freestyle jobs to run on a separate node by selecting the option Restrict where this project can be run in the General section of the job's configuration. In the Label Expression , the node's name can be mentioned in which to run the job. The following image shows the option from job's configuration. This can be done in all the job's configuration for the specified node.","title":"Multinode Pipelines"},{"location":"Multinode_Pipelines/#multinode-pipelines","text":"One can create multinode pipelines in jenkins freestyle pipeline job as well as in jenkins native pipeline job. In such a pipeline, different stages of the pipeline can run on separate nodes. The jenkins native pipeline job can have two types. Scripted Pipeline Declarative pipeline For the sake of this documentation, two nodes are used: container-node and container-node2","title":"Multinode Pipelines"},{"location":"Multinode_Pipelines/#label","text":"In jenkins, label specifies where the job or a stage of the job can run. In jenkins, a label can be explicitly added in the node's configuration so that each time that label is mentioned in a jenkins job, that specific node is used for building the job, or the name of the node can also be used as label in case if no label is added in the node.","title":"Label"},{"location":"Multinode_Pipelines/#creating-multinode-pipelines-in-jenkins-native-pipeline-job","text":"","title":"Creating multinode pipelines in Jenkins native pipeline job"},{"location":"Multinode_Pipelines/#scripted-pipeline","text":"For creating a multinode pipeline with jenkins native scripted pipeline job, jenkinsfile can be tweaked. The keyword node can be used to specify the node in which the stages are going to run and this keyword can also be used in between stages. Following screenshot indicates a code in which first stage runs on node named container-node . While the second node runs on node named container-node2 . node ('container-node') { stage ('*** Creating a directory in container-node ***'){ sh '''#!/bin/bash mkdir newdir_container-node-$RANDOM ''' } stage ('*** Creating a directory in container-node2'){ node ('container-node2'){ sh'''#!/bin/bash mkdir newdir_container-node2-$RANDOM ''' } } }","title":"Scripted Pipeline"},{"location":"Multinode_Pipelines/#declarative-pipeline","text":"For a declarative pipeline the keyword label can be used in the agent block. This can either be done at the start of the pipeline after the keyword pipeline or it can be used inside the stages. The following code builds two stages each of which is built in separate node. The keyword none with agent means that the agent is not specified globally for each stage and it should be specified inside each stage. pipeline { agent none // Means no agent specified. This means each node will specify its own agent stages { stage('container-node') { agent{ label \"container-node\" //Selecting container-node for this stage } steps { sh '''#!/bin/bash echo 'Hello container-node' mkdir \"newdir-container-node-$RANDOM\" ''' } } stage('container-node2'){ agent{ label \"container-node2\" //Selecting container-node2 for this stage } steps{ sh'''#!/bin/bash echo ''Hello container-node2 mkdir \"newdir-container-node2-$RANDOM\" ''' } } } }","title":"Declarative pipeline"},{"location":"Multinode_Pipelines/#creating-multinode-pipelines-using-jenkins-freestyle-jobs","text":"Jenkins freestyle jobs can be combined together by mentioning post-build jobs in the freestyle job settings. Freestyle jobs are customizable and offer more options than jenkins native pipeline jobs. Each job represents a stage and each stage has separate settings. One can use jenkins freestyle jobs to run on a separate node by selecting the option Restrict where this project can be run in the General section of the job's configuration. In the Label Expression , the node's name can be mentioned in which to run the job. The following image shows the option from job's configuration. This can be done in all the job's configuration for the specified node.","title":"Creating multinode pipelines using Jenkins freestyle jobs"},{"location":"Software_Developer_Guide/","text":"Software Developer Guide for RISC-V CI A software developer is the end-user who will develop or build his/her projects on RISC-V CI infrastructure. This guide will cover all the things a software developer needs to create a project based on Cloud-V Continuous Integration (CI). Pre-requisites GitHub account. GitHub project repository with owner rights. Getting an account for Cloud-V Fill out this google form with all the required information for getting an account on Cloud-V. After this we will get back to you with login credentials. Setting up cloud-v-pipeline inside github project repository Cloud-V will need a cloud-v-pipeline written with jenkinsfile pipeline syntax to start execution of tests/checks (see link ). This pipeline will contain all the stages (and may be steps) of a CI/CD pipeline. This pipeline can be scripted pipeline which will only have stages or it can also be declarative pipeline which may also have steps inside stages. A simple scripted Helloworld pipeline in linux is as follows: node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } Upon execution of such a pipeline, the console output can be viewed as follows. Note: This cloud-v-pipeline should remain same in all the branches and pull requests. Setting credentials for webhook Cloud-V supports webhooks which can trigger the job from external sources such as GitHub. They work in a way such that, if a specified branch is committed or if a pull request is created, the specified job build starts running depending upon the trigger event which is set in build's configuration in Cloud-V. This process requires access token of the repository CREATED BY OWNER OF REPOSITORY on which the webhook is to be set. These credentials can be safely added to Cloud-V without anyone (even administrator) seeing the passwords as follows. Obtaining github access token for repository Navigate to the dashboard of your github account and click on the your github profile picture on the top-right corner on dashboard. Then click on the \"Settings\" from the list. From the left option bar in Settings scroll down and click on \"Developer settings\". Once there, click on \"Personal access tokens\", then click on \"Fine-grained tokens\" from the dropdown list and after that click on \"Generate new token\". This will open the page for setting up new access token. Follow following steps for creating a token: Give your token a meaningful name under \"Token name\" Set expiration date in \"Expiration\" depending upon how long you would like your repository to be integrated with Cloud-V (think of a meaningful upper bound) The \"Resource owner\" should be the owner of the repository who can access all kinds of settings of the repository Under \"Repository access\", check \"Only select repositories\" and then select the repository for which you would like to create the token Under \"Permissions\" section, expand \"Repository Permissions\" and give the following two permissions: \"Read and write\" access to \"Commit statuses\" (Because after the CI has run, Cloud-V will be able to set the status of the commit accordingly) \"Read-only\" access to \"Webhooks\" Configuring repository webhook In GitHub, Go to repository settings which you want to integrate for Cloud-V. Go to Webhooks Click on Add webhook Add Payload URL as https://dash.cloud-v.co/ghprbhook/ Select content type as application/json Check Enable SSL verification In the section Which events would you like to trigger this webhook? check Let me select individual events and check Pul requests as individual events and dont check any other permission. Webhook settings will look something like this: Configurations inside Cloud-V Note: Currently users are not able to see or modify pipeline build configuration inside Jenkins, that is currently managed by administrator. Users are requested to inform administrator about how they want their pipeline configured. We will provide you with Cloud-V credentials on the provided email. Login with provided credentials. Click on the Credentials in the left menu. This will take you to the credentials page. Scroll down to the Stores scoped to Jenkins and click on the System as shown in the image. Click on Global credentials (unrestricted) . Click on Add Credentials . This will take you to the New Credentials page. Select Kind as Username with password . Select Scope as Global (Jenkins, nodes, items, all child items etc) . Enter your GitHub username in Username Enter Password as GitHub personal authentication token (PAT) which can be acquired from Github account settings. ID is optional but you can enter a unique ID . Description can be left empty. But it is recommended to give a suitable but careful description by which administrator will be able to identify and use these credentials to set up github webhook Select Create This process will look something like this Now credentials will be available in the credentials list and will be shown to you as well as administrator as shown in the image below. This will create an option in configurations for using these credentials in github webhook without changing or viewing them. Note the credentials ID (as shown in the image below) and email it to the same administrator email on which you received the login credentials for Cloud-V. It is important that administrator knows the credentials ID because they will use it in the job build configurations. Note: Please make sure to inform the administrator via email that you have added the credentials in Cloud-V Dashboard. Also, send administrator the ID of credentials via email. Requirements for administrator After the above setup is complete from software developer's side, developer will need to provide the administrator with following information. Dependencies for running the project which can be packages which are needed to install in the RISC-V CI environment by administrator. Events for triggering the job build. URL of GitHub repository. Path and name of cloud-v-pipeline file on the provided GitHub repository. Any additional information which should be given for successful execution of job builds.","title":"Getting Started"},{"location":"Software_Developer_Guide/#software-developer-guide-for-risc-v-ci","text":"A software developer is the end-user who will develop or build his/her projects on RISC-V CI infrastructure. This guide will cover all the things a software developer needs to create a project based on Cloud-V Continuous Integration (CI).","title":"Software Developer Guide for RISC-V CI"},{"location":"Software_Developer_Guide/#pre-requisites","text":"GitHub account. GitHub project repository with owner rights.","title":"Pre-requisites"},{"location":"Software_Developer_Guide/#getting-an-account-for-cloud-v","text":"Fill out this google form with all the required information for getting an account on Cloud-V. After this we will get back to you with login credentials.","title":"Getting an account for Cloud-V"},{"location":"Software_Developer_Guide/#setting-up-cloud-v-pipeline-inside-github-project-repository","text":"Cloud-V will need a cloud-v-pipeline written with jenkinsfile pipeline syntax to start execution of tests/checks (see link ). This pipeline will contain all the stages (and may be steps) of a CI/CD pipeline. This pipeline can be scripted pipeline which will only have stages or it can also be declarative pipeline which may also have steps inside stages. A simple scripted Helloworld pipeline in linux is as follows: node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } Upon execution of such a pipeline, the console output can be viewed as follows. Note: This cloud-v-pipeline should remain same in all the branches and pull requests.","title":"Setting up cloud-v-pipeline inside github project repository"},{"location":"Software_Developer_Guide/#setting-credentials-for-webhook","text":"Cloud-V supports webhooks which can trigger the job from external sources such as GitHub. They work in a way such that, if a specified branch is committed or if a pull request is created, the specified job build starts running depending upon the trigger event which is set in build's configuration in Cloud-V. This process requires access token of the repository CREATED BY OWNER OF REPOSITORY on which the webhook is to be set. These credentials can be safely added to Cloud-V without anyone (even administrator) seeing the passwords as follows.","title":"Setting credentials for webhook"},{"location":"Software_Developer_Guide/#obtaining-github-access-token-for-repository","text":"Navigate to the dashboard of your github account and click on the your github profile picture on the top-right corner on dashboard. Then click on the \"Settings\" from the list. From the left option bar in Settings scroll down and click on \"Developer settings\". Once there, click on \"Personal access tokens\", then click on \"Fine-grained tokens\" from the dropdown list and after that click on \"Generate new token\". This will open the page for setting up new access token. Follow following steps for creating a token: Give your token a meaningful name under \"Token name\" Set expiration date in \"Expiration\" depending upon how long you would like your repository to be integrated with Cloud-V (think of a meaningful upper bound) The \"Resource owner\" should be the owner of the repository who can access all kinds of settings of the repository Under \"Repository access\", check \"Only select repositories\" and then select the repository for which you would like to create the token Under \"Permissions\" section, expand \"Repository Permissions\" and give the following two permissions: \"Read and write\" access to \"Commit statuses\" (Because after the CI has run, Cloud-V will be able to set the status of the commit accordingly) \"Read-only\" access to \"Webhooks\"","title":"Obtaining github access token for repository"},{"location":"Software_Developer_Guide/#configuring-repository-webhook","text":"In GitHub, Go to repository settings which you want to integrate for Cloud-V. Go to Webhooks Click on Add webhook Add Payload URL as https://dash.cloud-v.co/ghprbhook/ Select content type as application/json Check Enable SSL verification In the section Which events would you like to trigger this webhook? check Let me select individual events and check Pul requests as individual events and dont check any other permission. Webhook settings will look something like this:","title":"Configuring repository webhook"},{"location":"Software_Developer_Guide/#configurations-inside-cloud-v","text":"Note: Currently users are not able to see or modify pipeline build configuration inside Jenkins, that is currently managed by administrator. Users are requested to inform administrator about how they want their pipeline configured. We will provide you with Cloud-V credentials on the provided email. Login with provided credentials. Click on the Credentials in the left menu. This will take you to the credentials page. Scroll down to the Stores scoped to Jenkins and click on the System as shown in the image. Click on Global credentials (unrestricted) . Click on Add Credentials . This will take you to the New Credentials page. Select Kind as Username with password . Select Scope as Global (Jenkins, nodes, items, all child items etc) . Enter your GitHub username in Username Enter Password as GitHub personal authentication token (PAT) which can be acquired from Github account settings. ID is optional but you can enter a unique ID . Description can be left empty. But it is recommended to give a suitable but careful description by which administrator will be able to identify and use these credentials to set up github webhook Select Create This process will look something like this Now credentials will be available in the credentials list and will be shown to you as well as administrator as shown in the image below. This will create an option in configurations for using these credentials in github webhook without changing or viewing them. Note the credentials ID (as shown in the image below) and email it to the same administrator email on which you received the login credentials for Cloud-V. It is important that administrator knows the credentials ID because they will use it in the job build configurations. Note: Please make sure to inform the administrator via email that you have added the credentials in Cloud-V Dashboard. Also, send administrator the ID of credentials via email.","title":"Configurations inside Cloud-V"},{"location":"Software_Developer_Guide/#requirements-for-administrator","text":"After the above setup is complete from software developer's side, developer will need to provide the administrator with following information. Dependencies for running the project which can be packages which are needed to install in the RISC-V CI environment by administrator. Events for triggering the job build. URL of GitHub repository. Path and name of cloud-v-pipeline file on the provided GitHub repository. Any additional information which should be given for successful execution of job builds.","title":"Requirements for administrator"},{"location":"Tooling/","text":"Tools on Cloud-V Using Environment Modules Users can use environment modules to load different versions of same program. For using environment modules the pattern is as follows: module load <PACKAGENAME/VERSION> Important Note: Be sure to use #!/bin/bash -l instead of #!/bin/bash in CI pipeline file since that is required for environment modules to load For example if you want to load python version 3.9.2 compiled for x86, you will need to use following command: module load python/3.9.2 For packages compiled for RISC-V architecture host, you will need to append _riscv to package name. For example, for python 3.8.15 compiled for RISC-V, following command will be used. module load python_riscv/3.8.15","title":"Using Environment Modules"},{"location":"Tooling/#tools-on-cloud-v","text":"","title":"Tools on Cloud-V"},{"location":"Tooling/#using-environment-modules","text":"Users can use environment modules to load different versions of same program. For using environment modules the pattern is as follows: module load <PACKAGENAME/VERSION> Important Note: Be sure to use #!/bin/bash -l instead of #!/bin/bash in CI pipeline file since that is required for environment modules to load For example if you want to load python version 3.9.2 compiled for x86, you will need to use following command: module load python/3.9.2 For packages compiled for RISC-V architecture host, you will need to append _riscv to package name. For example, for python 3.8.15 compiled for RISC-V, following command will be used. module load python_riscv/3.8.15","title":"Using Environment Modules"},{"location":"jenkins_gitlab_integration/","text":"Integrating GitLab with Jenkins This documentation will cover how to create an integration between jenkins and GitLab. This will allow users to trigger jenkins job when a merge request or a push is detected in GitLab. Pre-requisites GitLab plugin Git plugin GitLab repository with owner's credentials Configuring Jenkins System First jenkins needs to be configured. Go to Dashboard > Manage Jenkins > Configure System Scroll down to Gitlab section Check Enable authentication for '/project' end-point Enter a Connection name . Enter Gitlab host URL as https://gitlab.com/ . In case there is a different domain name, then enter there instead of above url. In Credentials , click on Add then click on Jenkins . In Kind , select GitLab API token . In API token , enter the gitlab personal access token (this will be obtained below while configuring GitLab). Click on Advanced . Click on Test Connection . If everything goes right, it should print success . Configuring GitLab Click on profile avatar in the top right. Click on Edit profile . Click on Access Tokens . Create a new personal access token and copy it (this is the GitLab API token used in above section Configuring Jenkins System ). Go to repository settings. On left-side pane, select Webhooks . Enter GitLab webhook URL (this is explained below in next section). Enter Secret Token (this is explained in the below section). Check desirable trigger options. Click Add webhook . Configuring Jenkins Job Create a jenkins job. On job configuration page, scroll down to Source Code Management . Select Git . In Credentials , add the owner credentials of GitLab repository. This will be Username and Password . Select the appropriate branch (generally it is main ). Scroll down to Build Triggers . Check Build when a change is pushed to GitLab . There will also be a GitLab webhook URL . This is needed in GitLab. This URL will be called as Webhook URL . Click on Advanced in the same option, then scroll down and generate a secret token. This token is also needed. This token will be called as Secret Token . Scroll down to Post-build Actions and select Publish build status to GitLab . Click on Apply and Save . Now whenever there will be a push (or whatever build trigger option is set in jenkins and gitlab webhook), specified jenkins job will be triggered.","title":"Integrating GitLab with Jenkins"},{"location":"jenkins_gitlab_integration/#integrating-gitlab-with-jenkins","text":"This documentation will cover how to create an integration between jenkins and GitLab. This will allow users to trigger jenkins job when a merge request or a push is detected in GitLab.","title":"Integrating GitLab with Jenkins"},{"location":"jenkins_gitlab_integration/#pre-requisites","text":"GitLab plugin Git plugin GitLab repository with owner's credentials","title":"Pre-requisites"},{"location":"jenkins_gitlab_integration/#configuring-jenkins-system","text":"First jenkins needs to be configured. Go to Dashboard > Manage Jenkins > Configure System Scroll down to Gitlab section Check Enable authentication for '/project' end-point Enter a Connection name . Enter Gitlab host URL as https://gitlab.com/ . In case there is a different domain name, then enter there instead of above url. In Credentials , click on Add then click on Jenkins . In Kind , select GitLab API token . In API token , enter the gitlab personal access token (this will be obtained below while configuring GitLab). Click on Advanced . Click on Test Connection . If everything goes right, it should print success .","title":"Configuring Jenkins System"},{"location":"jenkins_gitlab_integration/#configuring-gitlab","text":"Click on profile avatar in the top right. Click on Edit profile . Click on Access Tokens . Create a new personal access token and copy it (this is the GitLab API token used in above section Configuring Jenkins System ). Go to repository settings. On left-side pane, select Webhooks . Enter GitLab webhook URL (this is explained below in next section). Enter Secret Token (this is explained in the below section). Check desirable trigger options. Click Add webhook .","title":"Configuring GitLab"},{"location":"jenkins_gitlab_integration/#configuring-jenkins-job","text":"Create a jenkins job. On job configuration page, scroll down to Source Code Management . Select Git . In Credentials , add the owner credentials of GitLab repository. This will be Username and Password . Select the appropriate branch (generally it is main ). Scroll down to Build Triggers . Check Build when a change is pushed to GitLab . There will also be a GitLab webhook URL . This is needed in GitLab. This URL will be called as Webhook URL . Click on Advanced in the same option, then scroll down and generate a secret token. This token is also needed. This token will be called as Secret Token . Scroll down to Post-build Actions and select Publish build status to GitLab . Click on Apply and Save . Now whenever there will be a push (or whatever build trigger option is set in jenkins and gitlab webhook), specified jenkins job will be triggered.","title":"Configuring Jenkins Job"},{"location":"runner_specs/","text":"Specifications of compute instances in Cloud-V This document contains the specifications of the compute instances available for users to run builds in Cloud-V. The term \"Compute Instance\", can also be safely interchanged with the terms \"Build Executor\" and \"Runner\". Name String Architecture ISA String Cores Memory Compute Instance Type J-x86-1 (or) J-QMU-1 x86_64 N/A 4 8GiB Hardware with application-level emulator J-TESTVM-1 x86_64 N/A 4 8GiB Hardware J-RASP4-1 aarch64 4 4GiB Hardware ARMv8-A J-QMS-1 riscv64 See Ext 1 at bottom 2 2GiB QEMU System emulator J-VF1-1 riscv64 rv64imafdc 2 8GiB Hardware J-VF1-2 riscv64 rv64imafdc 2 8GiB Hardware J-VF1-3 riscv64 rv64imafdc 2 8GiB Hardware J-VF2-1 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-2 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-3 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-4 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-5 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-6 riscv64 rv64imafdc 4 8GiB Hardware J-HF-1 riscv64 rv64imafdc 4 8GiB Hardware J-K230-1 riscv64 rv64imafdcvxthead 1 512MiB Hardware Ext1: rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"Compute Instance Specifications"},{"location":"runner_specs/#specifications-of-compute-instances-in-cloud-v","text":"This document contains the specifications of the compute instances available for users to run builds in Cloud-V. The term \"Compute Instance\", can also be safely interchanged with the terms \"Build Executor\" and \"Runner\". Name String Architecture ISA String Cores Memory Compute Instance Type J-x86-1 (or) J-QMU-1 x86_64 N/A 4 8GiB Hardware with application-level emulator J-TESTVM-1 x86_64 N/A 4 8GiB Hardware J-RASP4-1 aarch64 4 4GiB Hardware ARMv8-A J-QMS-1 riscv64 See Ext 1 at bottom 2 2GiB QEMU System emulator J-VF1-1 riscv64 rv64imafdc 2 8GiB Hardware J-VF1-2 riscv64 rv64imafdc 2 8GiB Hardware J-VF1-3 riscv64 rv64imafdc 2 8GiB Hardware J-VF2-1 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-2 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-3 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-4 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-5 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-6 riscv64 rv64imafdc 4 8GiB Hardware J-HF-1 riscv64 rv64imafdc 4 8GiB Hardware J-K230-1 riscv64 rv64imafdcvxthead 1 512MiB Hardware Ext1: rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"Specifications of compute instances in Cloud-V"},{"location":"tooling_J-HF-1/","text":"Tools on J-HF-1 node This compute instance is Sifive's HiFive Unleased board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 20.04.6 (Focal Fossa) Tool Version Installed from Git 2.25.1 apt OpenJDK 11.0.20.1 apt GCC 10.5.0 apt Python3 3.8.10 apt OpenSSL 1.1.1f apt Ruby 2.7.0p0 apt Go 1.14.3 apt rustc 1.41.0 apt Flex 2.6.4 apt Ninja 1.10.0 apt Bison 3.5.1 apt autoconf 2.69 apt gperf 3.1 apt cmake 3.16.3 apt make 4.2.1 apt automake 1.16.1 apt gfortran 9.4.0 apt openssh-server 8.2p1 apt","title":"J-HF-1"},{"location":"tooling_J-HF-1/#tools-on-j-hf-1-node","text":"This compute instance is Sifive's HiFive Unleased board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 20.04.6 (Focal Fossa) Tool Version Installed from Git 2.25.1 apt OpenJDK 11.0.20.1 apt GCC 10.5.0 apt Python3 3.8.10 apt OpenSSL 1.1.1f apt Ruby 2.7.0p0 apt Go 1.14.3 apt rustc 1.41.0 apt Flex 2.6.4 apt Ninja 1.10.0 apt Bison 3.5.1 apt autoconf 2.69 apt gperf 3.1 apt cmake 3.16.3 apt make 4.2.1 apt automake 1.16.1 apt gfortran 9.4.0 apt openssh-server 8.2p1 apt","title":"Tools on J-HF-1 node"},{"location":"tooling_J-K230-1/","text":"Tools on J-K230-1 node This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.40.1 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.6 apt OpenSSL 3.0.10 apt Ruby 3.1.2p20 apt Go 1.21.1 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.27.4 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.3p1 apt vim 9.0 apt vim 3.3a apt","title":"J-K230-1"},{"location":"tooling_J-K230-1/#tools-on-j-k230-1-node","text":"This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.40.1 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.6 apt OpenSSL 3.0.10 apt Ruby 3.1.2p20 apt Go 1.21.1 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.27.4 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.3p1 apt vim 9.0 apt vim 3.3a apt","title":"Tools on J-K230-1 node"},{"location":"tooling_J-QMS-1/","text":"Tools on J-QMS-1 node This is QEMU system compute instance with 64-bit RISC-V Linux and it has all the packages ONLY for RISC-V architecture Operating System: Ubuntu 22.04.4 LTS (Jammy Jellyfish) QEMU Linux Version: 7.2.90 (v9.0.0-rc0-68-g853546f812) Tool Version Installed from pip 22.0.2 apt Git 2.34.1 apt OpenJDK 19.0.1 apt GCC 11.4.0 apt Python3 3.10.12 apt OpenSSL 3.0.2 apt Ruby 3.0.2p107 apt Go 1.18.8 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.10.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt make 4.3 apt cmake 3.22.1 apt","title":"J-QMS-1"},{"location":"tooling_J-QMS-1/#tools-on-j-qms-1-node","text":"This is QEMU system compute instance with 64-bit RISC-V Linux and it has all the packages ONLY for RISC-V architecture Operating System: Ubuntu 22.04.4 LTS (Jammy Jellyfish) QEMU Linux Version: 7.2.90 (v9.0.0-rc0-68-g853546f812) Tool Version Installed from pip 22.0.2 apt Git 2.34.1 apt OpenJDK 19.0.1 apt GCC 11.4.0 apt Python3 3.10.12 apt OpenSSL 3.0.2 apt Ruby 3.0.2p107 apt Go 1.18.8 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.10.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt make 4.3 apt cmake 3.22.1 apt","title":"Tools on J-QMS-1 node"},{"location":"tooling_J-QMU-1J-VM-1/","text":"Tools on J-x86-1 or J-QMU-1 node Tools which are mentioned for x86 architecture are able to run on J-x86-1 . Tools which are mentioned for RISC-V architecture are able to run on J-QMU-1 . The packages which are supported for QEMU User mode can be used by normal commands once they are loaded. Here PACKAGE_NAME is the package which you want to run on QEMU user mode. Operating System: Debian 11 (bullseye) QEMU User Mode Version: Different Versions (see the table below) Tooling available for J-x86-1 The tools available for J-x86-1 is for use on x86 architecture and these tools do not support execution on RISC-V architecture Tool Versions Installed from Host Architecture Environment Modules Support Git 2.3.0.2 source x86 N/A OpenJDK 19.0.1 apt x86 N/A GCC 10.4.0, 12.2.0 apt x86 Yes Python3 3.8.15, 3.9.2 source x86 Yes Go 1.18.8 apt x86 N/A rustc 1.65.0 source x86 N/A Flex 2.6.4 apt x86 N/A Ninja 1.10.1-1 apt x86 N/A Bison 3.7.5 apt x86 N/A autoconf 2.69 apt x86 N/A gperf 2.2.4 apt x86 N/A spike 1.1.1-dev source x86 Yes Verilator 4.038 apt x86 N/A Sail (riscv_sim_RV64, riscv_sim_RV32) 0.5 source x86 Yes cmake 3.18.4 apt x86 N/A make 4.3 apt x86 N/A ARM EABI GNU toolchain 13.2.Rel1 source x86 Yes qemu-system-arm 8.2.2 source x86 Yes SCons 4.7.0 source x86 Yes Tooling available for J-QMU-1 The tools available for J-QMU-1 is for use on RISC-V architecture and these tools do not support execution on x86 architecture Tool Versions Installed from Host Architecture Environment Modules Support Python3 3.8.15 source RISC-V Yes zlib 1.2.13 source RISC-V N/A OpenSSL 1.1.1r source RISC-V Yes Ruby (without IRB) 3.2.0dev source RISC-V Yes rustc 1.65.0 source RISC-V N/A Flex 2.6.4 source RISC-V yes Ninja 1.12.0.git source RISC-V Yes Bison 3.8.2, 2.3 source RISC-V Yes clang 16.0.0 source RISC-V (cross compiler) Yes riscv-pk 1.0.0-91-g573c858 source RISC-V Yes QEMU User mode and RISC-V GNU Cross compilers From now on RISC-V cross-compilers can only be loaded with their respective QEMU User mode on Cloud-V. This is configured so that there is no confusion between toolchain version and qemu user mode being used because both of these will be \"generally\" taken from the latest releases of nightly builds. Loading a certain RISC-V toolchain using environment modules will automatically load the respective qemu usermode version unless otherwise specified. The loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-glibc/<release-date> And the loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-elf/<release-date> Following table provides relevant information about version of the toolchain and the respective QEMU User mode version (where the release date is mentioned in pattern MMDDYYYY ). Release date GNU Toolchain version (elf and glibc) QEMU Version 03012024 13.2.0 8.2.1 02022024 13.2.0 8.2.1 02022024 13.2.0 8.1.1 Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"J-x86-1 or J-QMU-1"},{"location":"tooling_J-QMU-1J-VM-1/#tools-on-j-x86-1-or-j-qmu-1-node","text":"Tools which are mentioned for x86 architecture are able to run on J-x86-1 . Tools which are mentioned for RISC-V architecture are able to run on J-QMU-1 . The packages which are supported for QEMU User mode can be used by normal commands once they are loaded. Here PACKAGE_NAME is the package which you want to run on QEMU user mode. Operating System: Debian 11 (bullseye) QEMU User Mode Version: Different Versions (see the table below)","title":"Tools on J-x86-1 or J-QMU-1 node"},{"location":"tooling_J-QMU-1J-VM-1/#tooling-available-for-j-x86-1","text":"The tools available for J-x86-1 is for use on x86 architecture and these tools do not support execution on RISC-V architecture Tool Versions Installed from Host Architecture Environment Modules Support Git 2.3.0.2 source x86 N/A OpenJDK 19.0.1 apt x86 N/A GCC 10.4.0, 12.2.0 apt x86 Yes Python3 3.8.15, 3.9.2 source x86 Yes Go 1.18.8 apt x86 N/A rustc 1.65.0 source x86 N/A Flex 2.6.4 apt x86 N/A Ninja 1.10.1-1 apt x86 N/A Bison 3.7.5 apt x86 N/A autoconf 2.69 apt x86 N/A gperf 2.2.4 apt x86 N/A spike 1.1.1-dev source x86 Yes Verilator 4.038 apt x86 N/A Sail (riscv_sim_RV64, riscv_sim_RV32) 0.5 source x86 Yes cmake 3.18.4 apt x86 N/A make 4.3 apt x86 N/A ARM EABI GNU toolchain 13.2.Rel1 source x86 Yes qemu-system-arm 8.2.2 source x86 Yes SCons 4.7.0 source x86 Yes","title":"Tooling available for J-x86-1"},{"location":"tooling_J-QMU-1J-VM-1/#tooling-available-for-j-qmu-1","text":"The tools available for J-QMU-1 is for use on RISC-V architecture and these tools do not support execution on x86 architecture Tool Versions Installed from Host Architecture Environment Modules Support Python3 3.8.15 source RISC-V Yes zlib 1.2.13 source RISC-V N/A OpenSSL 1.1.1r source RISC-V Yes Ruby (without IRB) 3.2.0dev source RISC-V Yes rustc 1.65.0 source RISC-V N/A Flex 2.6.4 source RISC-V yes Ninja 1.12.0.git source RISC-V Yes Bison 3.8.2, 2.3 source RISC-V Yes clang 16.0.0 source RISC-V (cross compiler) Yes riscv-pk 1.0.0-91-g573c858 source RISC-V Yes","title":"Tooling available for J-QMU-1"},{"location":"tooling_J-QMU-1J-VM-1/#qemu-user-mode-and-risc-v-gnu-cross-compilers","text":"From now on RISC-V cross-compilers can only be loaded with their respective QEMU User mode on Cloud-V. This is configured so that there is no confusion between toolchain version and qemu user mode being used because both of these will be \"generally\" taken from the latest releases of nightly builds. Loading a certain RISC-V toolchain using environment modules will automatically load the respective qemu usermode version unless otherwise specified. The loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-glibc/<release-date> And the loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-elf/<release-date> Following table provides relevant information about version of the toolchain and the respective QEMU User mode version (where the release date is mentioned in pattern MMDDYYYY ). Release date GNU Toolchain version (elf and glibc) QEMU Version 03012024 13.2.0 8.2.1 02022024 13.2.0 8.2.1 02022024 13.2.0 8.1.1 Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"QEMU User mode and RISC-V GNU Cross compilers"},{"location":"tooling_J-VF1-x/","text":"Tools on J-VF1-x node This compute instance is Starfive's VisionFive 1 board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 23.04 (Lunar Lobster) Tool Version Installed from Git 2.39.2 apt OpenJDK 21-ea apt GCC 13.1.0 apt Python3 3.11.4 apt OpenSSL 3.0.8 apt Ruby 3.1.2p20 apt Go 1.20.3 apt rustc 1.67.1 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.25.1 apt make 4.3 apt automake 1.16.5 apt gfortran 13.1.0 apt openssh-server 9.0p1 apt","title":"J-VF1-x"},{"location":"tooling_J-VF1-x/#tools-on-j-vf1-x-node","text":"This compute instance is Starfive's VisionFive 1 board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 23.04 (Lunar Lobster) Tool Version Installed from Git 2.39.2 apt OpenJDK 21-ea apt GCC 13.1.0 apt Python3 3.11.4 apt OpenSSL 3.0.8 apt Ruby 3.1.2p20 apt Go 1.20.3 apt rustc 1.67.1 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.25.1 apt make 4.3 apt automake 1.16.5 apt gfortran 13.1.0 apt openssh-server 9.0p1 apt","title":"Tools on J-VF1-x node"},{"location":"tooling_J-VF2-x/","text":"Tools on J-VF2-x node This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.43.0 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.7 apt OpenSSL 3.1.5 apt Ruby 3.1.2p20 apt Go 1.22.0 apt rustc 1.70.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.28.3 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.6p1 apt vim 9.1 apt","title":"J-VF2-x"},{"location":"tooling_J-VF2-x/#tools-on-j-vf2-x-node","text":"This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.43.0 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.7 apt OpenSSL 3.1.5 apt Ruby 3.1.2p20 apt Go 1.22.0 apt rustc 1.70.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.28.3 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.6p1 apt vim 9.1 apt","title":"Tools on J-VF2-x node"}]}
\ No newline at end of file
+{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"Cloud-V Documentation This documentation lists the tooling and necessary information to use Cloud-V for RISC-V application development on RISC-V compute instances provided by Cloud-V Overview Slides: link Youtube Channel: youtube.com/@Cloud-V","title":"Home"},{"location":"#cloud-v-documentation","text":"This documentation lists the tooling and necessary information to use Cloud-V for RISC-V application development on RISC-V compute instances provided by Cloud-V Overview Slides: link Youtube Channel: youtube.com/@Cloud-V","title":"Cloud-V Documentation"},{"location":"Creating_CI_CD_pipeline/","text":"Creating a CI/CD pipeline in Jenkins Pre Requisistes For sake of this documentation, jenkins built-in sample script is used to create and execute a cd/cd pipeline in jenkins. In the built-in script maven is used as M3, so one must install Maven plugin inside jenkins and name it M3 . Usually maven is already present inside jenkins and can be configured from Global Configuration Tools . Following steps demonstrate configuring Maven plugin. Go to Jenkins Dashboard and click on Manage Jenkins In Manage Jenkins , under System Configuration section, click on Global Tool Configuration . In Global Tool Configuration , scroll down to Maven section and click on the respective option under the Maven Section (should be Maven installations\u2026 or Add Maven ). Under Maven installations , enter M3 in \u201cname\u201d text box, check Install Automatically and select Version greater than 3, then click Apply and Save . This should install Maven version 3 and configure as M3 . Steps for Jenkins pipeline creation After installing Jenkins and having all the suggested plugins installed, go to Jenkins dashboard and click on Create Job . On the next page, give your pipeline a name, select Pipeline and click OK . A Configuration page for the pipeline will appear. Select Build Triggers options and General options according to need and scroll down to the Pipeline section. Definition section contains configuration for stages and steps of the pipeline. Under Definition section, you can either choose Pipeline script and try writing your own script or try some sample pipeline (like Hello World , Github+Maven etc) or you could select Pipeline script from SCM and give a github repository containing configurations of Pipeline. Press Save and Apply . This should take you to the Pipeline and you can build the pipeline and if no unresolved dependencies are present, the pipeline should build without any error.","title":"Creating a CI/CD pipeline in Jenkins"},{"location":"Creating_CI_CD_pipeline/#creating-a-cicd-pipeline-in-jenkins","text":"","title":"Creating a CI/CD pipeline in Jenkins"},{"location":"Creating_CI_CD_pipeline/#pre-requisistes","text":"For sake of this documentation, jenkins built-in sample script is used to create and execute a cd/cd pipeline in jenkins. In the built-in script maven is used as M3, so one must install Maven plugin inside jenkins and name it M3 . Usually maven is already present inside jenkins and can be configured from Global Configuration Tools . Following steps demonstrate configuring Maven plugin. Go to Jenkins Dashboard and click on Manage Jenkins In Manage Jenkins , under System Configuration section, click on Global Tool Configuration . In Global Tool Configuration , scroll down to Maven section and click on the respective option under the Maven Section (should be Maven installations\u2026 or Add Maven ). Under Maven installations , enter M3 in \u201cname\u201d text box, check Install Automatically and select Version greater than 3, then click Apply and Save . This should install Maven version 3 and configure as M3 .","title":"Pre Requisistes"},{"location":"Creating_CI_CD_pipeline/#steps-for-jenkins-pipeline-creation","text":"After installing Jenkins and having all the suggested plugins installed, go to Jenkins dashboard and click on Create Job . On the next page, give your pipeline a name, select Pipeline and click OK . A Configuration page for the pipeline will appear. Select Build Triggers options and General options according to need and scroll down to the Pipeline section. Definition section contains configuration for stages and steps of the pipeline. Under Definition section, you can either choose Pipeline script and try writing your own script or try some sample pipeline (like Hello World , Github+Maven etc) or you could select Pipeline script from SCM and give a github repository containing configurations of Pipeline. Press Save and Apply . This should take you to the Pipeline and you can build the pipeline and if no unresolved dependencies are present, the pipeline should build without any error.","title":"Steps for Jenkins pipeline creation"},{"location":"Creating_jenkinsfile/","text":"Creating a Cloud-V CI Pipeline file What is a Cloud-V CI Pipeline file A cloud-v-pipeline file is a Continuous Integration (CI) jenkins pipeline script which is written in Groovy. It describes various stages (and possibly steps) which are executed in the defined pattern. These stages can be written in bash or they can be written in Groovy itself. Mainly there can be two types of Cloud-V pipeline files are of two types: Scripted: Only contains stages Declarative: Contains stages as well as steps (more feature-rich and recommended) This documentation will cover how to create a cloud-v-pipeline file with bash script inside it and run it on various compute instances (which are known as Nodes in jenkins). Jenkins Node In jenkins, node represents a compute instance. In simple words, it is the platform on which our job build is going to run. Jenkins Master There is a jenkins Master node which is actually the compute instance on which Jenkins is installed. It is the node which schedules builds on runners. For security reason, no job is allowed to run on this node. Jenkins Slave Jenkins slave nodes are the compute instances on which our job builds run safely. They may be attached with jenkins master via hardware or they may be connected through remote SSH connection. cloud-v-pipeline file written with bash Simple Hello World cloud-v-pipeline file In Cloud-V, all the platforms are running Linux operating system, so the cloud-v-pipeline should be written in bash. Following script is an example of how can we run a bash script in scripted cloud-v-pipeline . node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } The keyword sh is used to specify a shell script As there is nothing mentioned with node , so the script will run job build on any available compute instance. cloud-v-pipeline for a Specific Node In previous script, the cloud-v-pipeline would run on any compute instances which are available. But in case if someone wants to run a job build on specific node, then a compute instance name must be specified with keyword node . The following script is an example of running above Hello World program on node named hifive_unleashed . node('hifive_unleashed'){ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } cloud-v-pipeline for Cross-Platform Compilation and Execution Cloud-V supports cross-compilation and execution on emulated RISC-V compute instances. Following tools help in cross compilation and cross-platfrom execution: RISC-V GNU Toolchain QEMU user mode (for running standalone binaries) QEMU System (for running application in Linux) An example pipeline script is given below in scripted pipeline. node('x86_runner2'){ checkout scm //Getting content of this repo stage('*** Compilation Phase ***') { // for display purposes //Compiling helloworld.c using bash commands sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out //Cross compiling for RISC-V ''' } stage (' *** Running Binaries ***'){ sh '''#!/bin/bash ./helloworld.out qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out //Running executable on RISC-V emulated platform ''' } } The equivalent declarative pipeline is as follows: pipeline { agent {label \"x86_runner2\"} stages { stage('Clone Repository') { steps('delegate'){ checkout scm //Clones the repository on the local machine } } stage ('Compilation Phase'){ steps{ sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out ''' sh '''#!/bin/bash riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out ''' } } stage ('Running Binaries'){ steps { sh ''' #!/bin/bash ./helloworld.out ''' sh'''#!/bin/bash qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out ''' } } } } Reference Links https://www.jenkins.io/doc/book/pipeline/syntax/","title":"Creating a CI pipeline file"},{"location":"Creating_jenkinsfile/#creating-a-cloud-v-ci-pipeline-file","text":"","title":"Creating a Cloud-V CI Pipeline file"},{"location":"Creating_jenkinsfile/#what-is-a-cloud-v-ci-pipeline-file","text":"A cloud-v-pipeline file is a Continuous Integration (CI) jenkins pipeline script which is written in Groovy. It describes various stages (and possibly steps) which are executed in the defined pattern. These stages can be written in bash or they can be written in Groovy itself. Mainly there can be two types of Cloud-V pipeline files are of two types: Scripted: Only contains stages Declarative: Contains stages as well as steps (more feature-rich and recommended) This documentation will cover how to create a cloud-v-pipeline file with bash script inside it and run it on various compute instances (which are known as Nodes in jenkins).","title":"What is a Cloud-V CI Pipeline file"},{"location":"Creating_jenkinsfile/#jenkins-node","text":"In jenkins, node represents a compute instance. In simple words, it is the platform on which our job build is going to run.","title":"Jenkins Node"},{"location":"Creating_jenkinsfile/#jenkins-master","text":"There is a jenkins Master node which is actually the compute instance on which Jenkins is installed. It is the node which schedules builds on runners. For security reason, no job is allowed to run on this node.","title":"Jenkins Master"},{"location":"Creating_jenkinsfile/#jenkins-slave","text":"Jenkins slave nodes are the compute instances on which our job builds run safely. They may be attached with jenkins master via hardware or they may be connected through remote SSH connection.","title":"Jenkins Slave"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-file-written-with-bash","text":"","title":"cloud-v-pipeline file written with bash"},{"location":"Creating_jenkinsfile/#simple-hello-world-cloud-v-pipeline-file","text":"In Cloud-V, all the platforms are running Linux operating system, so the cloud-v-pipeline should be written in bash. Following script is an example of how can we run a bash script in scripted cloud-v-pipeline . node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } The keyword sh is used to specify a shell script As there is nothing mentioned with node , so the script will run job build on any available compute instance.","title":"Simple Hello World cloud-v-pipeline file"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-for-a-specific-node","text":"In previous script, the cloud-v-pipeline would run on any compute instances which are available. But in case if someone wants to run a job build on specific node, then a compute instance name must be specified with keyword node . The following script is an example of running above Hello World program on node named hifive_unleashed . node('hifive_unleashed'){ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } }","title":"cloud-v-pipeline for a Specific Node"},{"location":"Creating_jenkinsfile/#cloud-v-pipeline-for-cross-platform-compilation-and-execution","text":"Cloud-V supports cross-compilation and execution on emulated RISC-V compute instances. Following tools help in cross compilation and cross-platfrom execution: RISC-V GNU Toolchain QEMU user mode (for running standalone binaries) QEMU System (for running application in Linux) An example pipeline script is given below in scripted pipeline. node('x86_runner2'){ checkout scm //Getting content of this repo stage('*** Compilation Phase ***') { // for display purposes //Compiling helloworld.c using bash commands sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out //Cross compiling for RISC-V ''' } stage (' *** Running Binaries ***'){ sh '''#!/bin/bash ./helloworld.out qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out //Running executable on RISC-V emulated platform ''' } } The equivalent declarative pipeline is as follows: pipeline { agent {label \"x86_runner2\"} stages { stage('Clone Repository') { steps('delegate'){ checkout scm //Clones the repository on the local machine } } stage ('Compilation Phase'){ steps{ sh '''#!/bin/bash gcc -g ./helloworld.c -o helloworld.out ''' sh '''#!/bin/bash riscv64-unknown-linux-gnu-gcc ./helloworld.c -o helloworld_riscv_compiled.out ''' } } stage ('Running Binaries'){ steps { sh ''' #!/bin/bash ./helloworld.out ''' sh'''#!/bin/bash qemu-riscv64 -L $RISCV_SYSROOT helloworld_riscv_compiled.out ''' } } } }","title":"cloud-v-pipeline for Cross-Platform Compilation and Execution"},{"location":"Creating_jenkinsfile/#reference-links","text":"https://www.jenkins.io/doc/book/pipeline/syntax/","title":"Reference Links"},{"location":"Multinode_Pipelines/","text":"Multinode Pipelines One can create multinode pipelines in jenkins freestyle pipeline job as well as in jenkins native pipeline job. In such a pipeline, different stages of the pipeline can run on separate nodes. The jenkins native pipeline job can have two types. Scripted Pipeline Declarative pipeline For the sake of this documentation, two nodes are used: container-node and container-node2 Label In jenkins, label specifies where the job or a stage of the job can run. In jenkins, a label can be explicitly added in the node's configuration so that each time that label is mentioned in a jenkins job, that specific node is used for building the job, or the name of the node can also be used as label in case if no label is added in the node. Creating multinode pipelines in Jenkins native pipeline job Scripted Pipeline For creating a multinode pipeline with jenkins native scripted pipeline job, jenkinsfile can be tweaked. The keyword node can be used to specify the node in which the stages are going to run and this keyword can also be used in between stages. Following screenshot indicates a code in which first stage runs on node named container-node . While the second node runs on node named container-node2 . node ('container-node') { stage ('*** Creating a directory in container-node ***'){ sh '''#!/bin/bash mkdir newdir_container-node-$RANDOM ''' } stage ('*** Creating a directory in container-node2'){ node ('container-node2'){ sh'''#!/bin/bash mkdir newdir_container-node2-$RANDOM ''' } } } Declarative pipeline For a declarative pipeline the keyword label can be used in the agent block. This can either be done at the start of the pipeline after the keyword pipeline or it can be used inside the stages. The following code builds two stages each of which is built in separate node. The keyword none with agent means that the agent is not specified globally for each stage and it should be specified inside each stage. pipeline { agent none // Means no agent specified. This means each node will specify its own agent stages { stage('container-node') { agent{ label \"container-node\" //Selecting container-node for this stage } steps { sh '''#!/bin/bash echo 'Hello container-node' mkdir \"newdir-container-node-$RANDOM\" ''' } } stage('container-node2'){ agent{ label \"container-node2\" //Selecting container-node2 for this stage } steps{ sh'''#!/bin/bash echo ''Hello container-node2 mkdir \"newdir-container-node2-$RANDOM\" ''' } } } } Creating multinode pipelines using Jenkins freestyle jobs Jenkins freestyle jobs can be combined together by mentioning post-build jobs in the freestyle job settings. Freestyle jobs are customizable and offer more options than jenkins native pipeline jobs. Each job represents a stage and each stage has separate settings. One can use jenkins freestyle jobs to run on a separate node by selecting the option Restrict where this project can be run in the General section of the job's configuration. In the Label Expression , the node's name can be mentioned in which to run the job. The following image shows the option from job's configuration. This can be done in all the job's configuration for the specified node.","title":"Multinode Pipelines"},{"location":"Multinode_Pipelines/#multinode-pipelines","text":"One can create multinode pipelines in jenkins freestyle pipeline job as well as in jenkins native pipeline job. In such a pipeline, different stages of the pipeline can run on separate nodes. The jenkins native pipeline job can have two types. Scripted Pipeline Declarative pipeline For the sake of this documentation, two nodes are used: container-node and container-node2","title":"Multinode Pipelines"},{"location":"Multinode_Pipelines/#label","text":"In jenkins, label specifies where the job or a stage of the job can run. In jenkins, a label can be explicitly added in the node's configuration so that each time that label is mentioned in a jenkins job, that specific node is used for building the job, or the name of the node can also be used as label in case if no label is added in the node.","title":"Label"},{"location":"Multinode_Pipelines/#creating-multinode-pipelines-in-jenkins-native-pipeline-job","text":"","title":"Creating multinode pipelines in Jenkins native pipeline job"},{"location":"Multinode_Pipelines/#scripted-pipeline","text":"For creating a multinode pipeline with jenkins native scripted pipeline job, jenkinsfile can be tweaked. The keyword node can be used to specify the node in which the stages are going to run and this keyword can also be used in between stages. Following screenshot indicates a code in which first stage runs on node named container-node . While the second node runs on node named container-node2 . node ('container-node') { stage ('*** Creating a directory in container-node ***'){ sh '''#!/bin/bash mkdir newdir_container-node-$RANDOM ''' } stage ('*** Creating a directory in container-node2'){ node ('container-node2'){ sh'''#!/bin/bash mkdir newdir_container-node2-$RANDOM ''' } } }","title":"Scripted Pipeline"},{"location":"Multinode_Pipelines/#declarative-pipeline","text":"For a declarative pipeline the keyword label can be used in the agent block. This can either be done at the start of the pipeline after the keyword pipeline or it can be used inside the stages. The following code builds two stages each of which is built in separate node. The keyword none with agent means that the agent is not specified globally for each stage and it should be specified inside each stage. pipeline { agent none // Means no agent specified. This means each node will specify its own agent stages { stage('container-node') { agent{ label \"container-node\" //Selecting container-node for this stage } steps { sh '''#!/bin/bash echo 'Hello container-node' mkdir \"newdir-container-node-$RANDOM\" ''' } } stage('container-node2'){ agent{ label \"container-node2\" //Selecting container-node2 for this stage } steps{ sh'''#!/bin/bash echo ''Hello container-node2 mkdir \"newdir-container-node2-$RANDOM\" ''' } } } }","title":"Declarative pipeline"},{"location":"Multinode_Pipelines/#creating-multinode-pipelines-using-jenkins-freestyle-jobs","text":"Jenkins freestyle jobs can be combined together by mentioning post-build jobs in the freestyle job settings. Freestyle jobs are customizable and offer more options than jenkins native pipeline jobs. Each job represents a stage and each stage has separate settings. One can use jenkins freestyle jobs to run on a separate node by selecting the option Restrict where this project can be run in the General section of the job's configuration. In the Label Expression , the node's name can be mentioned in which to run the job. The following image shows the option from job's configuration. This can be done in all the job's configuration for the specified node.","title":"Creating multinode pipelines using Jenkins freestyle jobs"},{"location":"Software_Developer_Guide/","text":"Software Developer Guide for RISC-V CI A software developer is the end-user who will develop or build his/her projects on RISC-V CI infrastructure. This guide will cover all the things a software developer needs to create a project based on Cloud-V Continuous Integration (CI). Pre-requisites GitHub account. GitHub project repository with owner rights. Getting an account for Cloud-V Fill out this google form with all the required information for getting an account on Cloud-V. After this we will get back to you with login credentials. Setting up cloud-v-pipeline inside github project repository Cloud-V will need a cloud-v-pipeline written with jenkinsfile pipeline syntax to start execution of tests/checks (see link ). This pipeline will contain all the stages (and may be steps) of a CI/CD pipeline. This pipeline can be scripted pipeline which will only have stages or it can also be declarative pipeline which may also have steps inside stages. A simple scripted Helloworld pipeline in linux is as follows: node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } Upon execution of such a pipeline, the console output can be viewed as follows. Note: This cloud-v-pipeline should remain same in all the branches and pull requests. Setting credentials for webhook Cloud-V supports webhooks which can trigger the job from external sources such as GitHub. They work in a way such that, if a specified branch is committed or if a pull request is created, the specified job build starts running depending upon the trigger event which is set in build's configuration in Cloud-V. This process requires access token of the repository CREATED BY OWNER OF REPOSITORY on which the webhook is to be set. These credentials can be safely added to Cloud-V without anyone (even administrator) seeing the passwords as follows. Obtaining github access token for repository Navigate to the dashboard of your github account and click on the your github profile picture on the top-right corner on dashboard. Then click on the \"Settings\" from the list. From the left option bar in Settings scroll down and click on \"Developer settings\". Once there, click on \"Personal access tokens\", then click on \"Fine-grained tokens\" from the dropdown list and after that click on \"Generate new token\". This will open the page for setting up new access token. Follow following steps for creating a token: Give your token a meaningful name under \"Token name\" Set expiration date in \"Expiration\" depending upon how long you would like your repository to be integrated with Cloud-V (think of a meaningful upper bound) The \"Resource owner\" should be the owner of the repository who can access all kinds of settings of the repository Under \"Repository access\", check \"Only select repositories\" and then select the repository for which you would like to create the token Under \"Permissions\" section, expand \"Repository Permissions\" and give the following two permissions: \"Read and write\" access to \"Commit statuses\" (Because after the CI has run, Cloud-V will be able to set the status of the commit accordingly) \"Read-only\" access to \"Webhooks\" Configuring repository webhook In GitHub, Go to repository settings which you want to integrate for Cloud-V. Go to Webhooks Click on Add webhook Add Payload URL as https://dash.cloud-v.co/ghprbhook/ Select content type as application/json Check Enable SSL verification In the section Which events would you like to trigger this webhook? check Let me select individual events and check Pul requests as individual events and dont check any other permission. Webhook settings will look something like this: Configurations inside Cloud-V Note: Currently users are not able to see or modify pipeline build configuration inside Jenkins, that is currently managed by administrator. Users are requested to inform administrator about how they want their pipeline configured. We will provide you with Cloud-V credentials on the provided email. Login with provided credentials. Click on the Credentials in the left menu. This will take you to the credentials page. Scroll down to the Stores scoped to Jenkins and click on the System as shown in the image. Click on Global credentials (unrestricted) . Click on Add Credentials . This will take you to the New Credentials page. Select Kind as Username with password . Select Scope as Global (Jenkins, nodes, items, all child items etc) . Enter your GitHub username in Username Enter Password as GitHub personal authentication token (PAT) which can be acquired from Github account settings. ID is optional but you can enter a unique ID . Description can be left empty. But it is recommended to give a suitable but careful description by which administrator will be able to identify and use these credentials to set up github webhook Select Create This process will look something like this Now credentials will be available in the credentials list and will be shown to you as well as administrator as shown in the image below. This will create an option in configurations for using these credentials in github webhook without changing or viewing them. Note the credentials ID (as shown in the image below) and email it to the same administrator email on which you received the login credentials for Cloud-V. It is important that administrator knows the credentials ID because they will use it in the job build configurations. Note: Please make sure to inform the administrator via email that you have added the credentials in Cloud-V Dashboard. Also, send administrator the ID of credentials via email. Requirements for administrator After the above setup is complete from software developer's side, developer will need to provide the administrator with following information. Dependencies for running the project which can be packages which are needed to install in the RISC-V CI environment by administrator. Events for triggering the job build. URL of GitHub repository. Path and name of cloud-v-pipeline file on the provided GitHub repository. Any additional information which should be given for successful execution of job builds.","title":"Getting Started"},{"location":"Software_Developer_Guide/#software-developer-guide-for-risc-v-ci","text":"A software developer is the end-user who will develop or build his/her projects on RISC-V CI infrastructure. This guide will cover all the things a software developer needs to create a project based on Cloud-V Continuous Integration (CI).","title":"Software Developer Guide for RISC-V CI"},{"location":"Software_Developer_Guide/#pre-requisites","text":"GitHub account. GitHub project repository with owner rights.","title":"Pre-requisites"},{"location":"Software_Developer_Guide/#getting-an-account-for-cloud-v","text":"Fill out this google form with all the required information for getting an account on Cloud-V. After this we will get back to you with login credentials.","title":"Getting an account for Cloud-V"},{"location":"Software_Developer_Guide/#setting-up-cloud-v-pipeline-inside-github-project-repository","text":"Cloud-V will need a cloud-v-pipeline written with jenkinsfile pipeline syntax to start execution of tests/checks (see link ). This pipeline will contain all the stages (and may be steps) of a CI/CD pipeline. This pipeline can be scripted pipeline which will only have stages or it can also be declarative pipeline which may also have steps inside stages. A simple scripted Helloworld pipeline in linux is as follows: node{ stage('*** Phase 1 ***') { //Using bash commands sh '''#!/bin/bash echo \"Hello World !\\n\" ''' } } Upon execution of such a pipeline, the console output can be viewed as follows. Note: This cloud-v-pipeline should remain same in all the branches and pull requests.","title":"Setting up cloud-v-pipeline inside github project repository"},{"location":"Software_Developer_Guide/#setting-credentials-for-webhook","text":"Cloud-V supports webhooks which can trigger the job from external sources such as GitHub. They work in a way such that, if a specified branch is committed or if a pull request is created, the specified job build starts running depending upon the trigger event which is set in build's configuration in Cloud-V. This process requires access token of the repository CREATED BY OWNER OF REPOSITORY on which the webhook is to be set. These credentials can be safely added to Cloud-V without anyone (even administrator) seeing the passwords as follows.","title":"Setting credentials for webhook"},{"location":"Software_Developer_Guide/#obtaining-github-access-token-for-repository","text":"Navigate to the dashboard of your github account and click on the your github profile picture on the top-right corner on dashboard. Then click on the \"Settings\" from the list. From the left option bar in Settings scroll down and click on \"Developer settings\". Once there, click on \"Personal access tokens\", then click on \"Fine-grained tokens\" from the dropdown list and after that click on \"Generate new token\". This will open the page for setting up new access token. Follow following steps for creating a token: Give your token a meaningful name under \"Token name\" Set expiration date in \"Expiration\" depending upon how long you would like your repository to be integrated with Cloud-V (think of a meaningful upper bound) The \"Resource owner\" should be the owner of the repository who can access all kinds of settings of the repository Under \"Repository access\", check \"Only select repositories\" and then select the repository for which you would like to create the token Under \"Permissions\" section, expand \"Repository Permissions\" and give the following two permissions: \"Read and write\" access to \"Commit statuses\" (Because after the CI has run, Cloud-V will be able to set the status of the commit accordingly) \"Read-only\" access to \"Webhooks\"","title":"Obtaining github access token for repository"},{"location":"Software_Developer_Guide/#configuring-repository-webhook","text":"In GitHub, Go to repository settings which you want to integrate for Cloud-V. Go to Webhooks Click on Add webhook Add Payload URL as https://dash.cloud-v.co/ghprbhook/ Select content type as application/json Check Enable SSL verification In the section Which events would you like to trigger this webhook? check Let me select individual events and check Pul requests as individual events and dont check any other permission. Webhook settings will look something like this:","title":"Configuring repository webhook"},{"location":"Software_Developer_Guide/#configurations-inside-cloud-v","text":"Note: Currently users are not able to see or modify pipeline build configuration inside Jenkins, that is currently managed by administrator. Users are requested to inform administrator about how they want their pipeline configured. We will provide you with Cloud-V credentials on the provided email. Login with provided credentials. Click on the Credentials in the left menu. This will take you to the credentials page. Scroll down to the Stores scoped to Jenkins and click on the System as shown in the image. Click on Global credentials (unrestricted) . Click on Add Credentials . This will take you to the New Credentials page. Select Kind as Username with password . Select Scope as Global (Jenkins, nodes, items, all child items etc) . Enter your GitHub username in Username Enter Password as GitHub personal authentication token (PAT) which can be acquired from Github account settings. ID is optional but you can enter a unique ID . Description can be left empty. But it is recommended to give a suitable but careful description by which administrator will be able to identify and use these credentials to set up github webhook Select Create This process will look something like this Now credentials will be available in the credentials list and will be shown to you as well as administrator as shown in the image below. This will create an option in configurations for using these credentials in github webhook without changing or viewing them. Note the credentials ID (as shown in the image below) and email it to the same administrator email on which you received the login credentials for Cloud-V. It is important that administrator knows the credentials ID because they will use it in the job build configurations. Note: Please make sure to inform the administrator via email that you have added the credentials in Cloud-V Dashboard. Also, send administrator the ID of credentials via email.","title":"Configurations inside Cloud-V"},{"location":"Software_Developer_Guide/#requirements-for-administrator","text":"After the above setup is complete from software developer's side, developer will need to provide the administrator with following information. Dependencies for running the project which can be packages which are needed to install in the RISC-V CI environment by administrator. Events for triggering the job build. URL of GitHub repository. Path and name of cloud-v-pipeline file on the provided GitHub repository. Any additional information which should be given for successful execution of job builds.","title":"Requirements for administrator"},{"location":"Tooling/","text":"Tools on Cloud-V Using Environment Modules Users can use environment modules to load different versions of same program. For using environment modules the pattern is as follows: module load <PACKAGENAME/VERSION> Important Note: Be sure to use #!/bin/bash -l instead of #!/bin/bash in CI pipeline file since that is required for environment modules to load For example if you want to load python version 3.9.2 compiled for x86, you will need to use following command: module load python/3.9.2 For packages compiled for RISC-V architecture host, you will need to append _riscv to package name. For example, for python 3.8.15 compiled for RISC-V, following command will be used. module load python_riscv/3.8.15","title":"Using Environment Modules"},{"location":"Tooling/#tools-on-cloud-v","text":"","title":"Tools on Cloud-V"},{"location":"Tooling/#using-environment-modules","text":"Users can use environment modules to load different versions of same program. For using environment modules the pattern is as follows: module load <PACKAGENAME/VERSION> Important Note: Be sure to use #!/bin/bash -l instead of #!/bin/bash in CI pipeline file since that is required for environment modules to load For example if you want to load python version 3.9.2 compiled for x86, you will need to use following command: module load python/3.9.2 For packages compiled for RISC-V architecture host, you will need to append _riscv to package name. For example, for python 3.8.15 compiled for RISC-V, following command will be used. module load python_riscv/3.8.15","title":"Using Environment Modules"},{"location":"jenkins_gitlab_integration/","text":"Integrating GitLab with Jenkins This documentation will cover how to create an integration between jenkins and GitLab. This will allow users to trigger jenkins job when a merge request or a push is detected in GitLab. Pre-requisites GitLab plugin Git plugin GitLab repository with owner's credentials Configuring Jenkins System First jenkins needs to be configured. Go to Dashboard > Manage Jenkins > Configure System Scroll down to Gitlab section Check Enable authentication for '/project' end-point Enter a Connection name . Enter Gitlab host URL as https://gitlab.com/ . In case there is a different domain name, then enter there instead of above url. In Credentials , click on Add then click on Jenkins . In Kind , select GitLab API token . In API token , enter the gitlab personal access token (this will be obtained below while configuring GitLab). Click on Advanced . Click on Test Connection . If everything goes right, it should print success . Configuring GitLab Click on profile avatar in the top right. Click on Edit profile . Click on Access Tokens . Create a new personal access token and copy it (this is the GitLab API token used in above section Configuring Jenkins System ). Go to repository settings. On left-side pane, select Webhooks . Enter GitLab webhook URL (this is explained below in next section). Enter Secret Token (this is explained in the below section). Check desirable trigger options. Click Add webhook . Configuring Jenkins Job Create a jenkins job. On job configuration page, scroll down to Source Code Management . Select Git . In Credentials , add the owner credentials of GitLab repository. This will be Username and Password . Select the appropriate branch (generally it is main ). Scroll down to Build Triggers . Check Build when a change is pushed to GitLab . There will also be a GitLab webhook URL . This is needed in GitLab. This URL will be called as Webhook URL . Click on Advanced in the same option, then scroll down and generate a secret token. This token is also needed. This token will be called as Secret Token . Scroll down to Post-build Actions and select Publish build status to GitLab . Click on Apply and Save . Now whenever there will be a push (or whatever build trigger option is set in jenkins and gitlab webhook), specified jenkins job will be triggered.","title":"Integrating GitLab with Jenkins"},{"location":"jenkins_gitlab_integration/#integrating-gitlab-with-jenkins","text":"This documentation will cover how to create an integration between jenkins and GitLab. This will allow users to trigger jenkins job when a merge request or a push is detected in GitLab.","title":"Integrating GitLab with Jenkins"},{"location":"jenkins_gitlab_integration/#pre-requisites","text":"GitLab plugin Git plugin GitLab repository with owner's credentials","title":"Pre-requisites"},{"location":"jenkins_gitlab_integration/#configuring-jenkins-system","text":"First jenkins needs to be configured. Go to Dashboard > Manage Jenkins > Configure System Scroll down to Gitlab section Check Enable authentication for '/project' end-point Enter a Connection name . Enter Gitlab host URL as https://gitlab.com/ . In case there is a different domain name, then enter there instead of above url. In Credentials , click on Add then click on Jenkins . In Kind , select GitLab API token . In API token , enter the gitlab personal access token (this will be obtained below while configuring GitLab). Click on Advanced . Click on Test Connection . If everything goes right, it should print success .","title":"Configuring Jenkins System"},{"location":"jenkins_gitlab_integration/#configuring-gitlab","text":"Click on profile avatar in the top right. Click on Edit profile . Click on Access Tokens . Create a new personal access token and copy it (this is the GitLab API token used in above section Configuring Jenkins System ). Go to repository settings. On left-side pane, select Webhooks . Enter GitLab webhook URL (this is explained below in next section). Enter Secret Token (this is explained in the below section). Check desirable trigger options. Click Add webhook .","title":"Configuring GitLab"},{"location":"jenkins_gitlab_integration/#configuring-jenkins-job","text":"Create a jenkins job. On job configuration page, scroll down to Source Code Management . Select Git . In Credentials , add the owner credentials of GitLab repository. This will be Username and Password . Select the appropriate branch (generally it is main ). Scroll down to Build Triggers . Check Build when a change is pushed to GitLab . There will also be a GitLab webhook URL . This is needed in GitLab. This URL will be called as Webhook URL . Click on Advanced in the same option, then scroll down and generate a secret token. This token is also needed. This token will be called as Secret Token . Scroll down to Post-build Actions and select Publish build status to GitLab . Click on Apply and Save . Now whenever there will be a push (or whatever build trigger option is set in jenkins and gitlab webhook), specified jenkins job will be triggered.","title":"Configuring Jenkins Job"},{"location":"runner_specs/","text":"Specifications of compute instances in Cloud-V This document contains the specifications of the compute instances available for users to run builds in Cloud-V. The term \"Compute Instance\", can also be safely interchanged with the terms \"Build Executor\" and \"Runner\". Name String Architecture ISA String Cores Memory Compute Instance Type J-x86-1 (or) J-QMU-1 x86_64 N/A 4 8GiB Hardware with application-level emulator J-TESTVM-1 x86_64 N/A 4 8GiB Hardware J-RASP4-1 aarch64 ARMv8-A 4 4GiB Hardware J-QMS-1 riscv64 See Ext 1 at bottom 2 2GiB QEMU System emulator J-VF1-1 riscv64 rv64imafdc 2 8GiB Hardware J-VF1-2 riscv64 rv64imafdc 2 8GiB Hardware J-VF1-3 riscv64 rv64imafdc 2 8GiB Hardware J-VF2-1 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-2 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-3 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-4 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-5 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-6 riscv64 rv64imafdc 4 8GiB Hardware J-HF-1 riscv64 rv64imafdc 4 8GiB Hardware J-K230-1 riscv64 rv64imafdcvxthead 1 512MiB Hardware Ext1: rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"Compute Instance Specifications"},{"location":"runner_specs/#specifications-of-compute-instances-in-cloud-v","text":"This document contains the specifications of the compute instances available for users to run builds in Cloud-V. The term \"Compute Instance\", can also be safely interchanged with the terms \"Build Executor\" and \"Runner\". Name String Architecture ISA String Cores Memory Compute Instance Type J-x86-1 (or) J-QMU-1 x86_64 N/A 4 8GiB Hardware with application-level emulator J-TESTVM-1 x86_64 N/A 4 8GiB Hardware J-RASP4-1 aarch64 ARMv8-A 4 4GiB Hardware J-QMS-1 riscv64 See Ext 1 at bottom 2 2GiB QEMU System emulator J-VF1-1 riscv64 rv64imafdc 2 8GiB Hardware J-VF1-2 riscv64 rv64imafdc 2 8GiB Hardware J-VF1-3 riscv64 rv64imafdc 2 8GiB Hardware J-VF2-1 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-2 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-3 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-4 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-5 riscv64 rv64imafdc 4 8GiB Hardware J-VF2-6 riscv64 rv64imafdc 4 8GiB Hardware J-HF-1 riscv64 rv64imafdc 4 8GiB Hardware J-K230-1 riscv64 rv64imafdcvxthead 1 512MiB Hardware Ext1: rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sstc Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"Specifications of compute instances in Cloud-V"},{"location":"tooling_J-HF-1/","text":"Tools on J-HF-1 node This compute instance is Sifive's HiFive Unleased board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 20.04.6 (Focal Fossa) Tool Version Installed from Git 2.25.1 apt OpenJDK 11.0.20.1 apt GCC 10.5.0 apt Python3 3.8.10 apt OpenSSL 1.1.1f apt Ruby 2.7.0p0 apt Go 1.14.3 apt rustc 1.41.0 apt Flex 2.6.4 apt Ninja 1.10.0 apt Bison 3.5.1 apt autoconf 2.69 apt gperf 3.1 apt cmake 3.16.3 apt make 4.2.1 apt automake 1.16.1 apt gfortran 9.4.0 apt openssh-server 8.2p1 apt","title":"J-HF-1"},{"location":"tooling_J-HF-1/#tools-on-j-hf-1-node","text":"This compute instance is Sifive's HiFive Unleased board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 20.04.6 (Focal Fossa) Tool Version Installed from Git 2.25.1 apt OpenJDK 11.0.20.1 apt GCC 10.5.0 apt Python3 3.8.10 apt OpenSSL 1.1.1f apt Ruby 2.7.0p0 apt Go 1.14.3 apt rustc 1.41.0 apt Flex 2.6.4 apt Ninja 1.10.0 apt Bison 3.5.1 apt autoconf 2.69 apt gperf 3.1 apt cmake 3.16.3 apt make 4.2.1 apt automake 1.16.1 apt gfortran 9.4.0 apt openssh-server 8.2p1 apt","title":"Tools on J-HF-1 node"},{"location":"tooling_J-K230-1/","text":"Tools on J-K230-1 node This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.40.1 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.6 apt OpenSSL 3.0.10 apt Ruby 3.1.2p20 apt Go 1.21.1 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.27.4 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.3p1 apt vim 9.0 apt vim 3.3a apt","title":"J-K230-1"},{"location":"tooling_J-K230-1/#tools-on-j-k230-1-node","text":"This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.40.1 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.6 apt OpenSSL 3.0.10 apt Ruby 3.1.2p20 apt Go 1.21.1 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.27.4 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.3p1 apt vim 9.0 apt vim 3.3a apt","title":"Tools on J-K230-1 node"},{"location":"tooling_J-QMS-1/","text":"Tools on J-QMS-1 node This is QEMU system compute instance with 64-bit RISC-V Linux and it has all the packages ONLY for RISC-V architecture Operating System: Ubuntu 22.04.4 LTS (Jammy Jellyfish) QEMU Linux Version: 7.2.90 (v9.0.0-rc0-68-g853546f812) Tool Version Installed from pip 22.0.2 apt Git 2.34.1 apt OpenJDK 19.0.1 apt GCC 11.4.0 apt Python3 3.10.12 apt OpenSSL 3.0.2 apt Ruby 3.0.2p107 apt Go 1.18.8 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.10.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt make 4.3 apt cmake 3.22.1 apt","title":"J-QMS-1"},{"location":"tooling_J-QMS-1/#tools-on-j-qms-1-node","text":"This is QEMU system compute instance with 64-bit RISC-V Linux and it has all the packages ONLY for RISC-V architecture Operating System: Ubuntu 22.04.4 LTS (Jammy Jellyfish) QEMU Linux Version: 7.2.90 (v9.0.0-rc0-68-g853546f812) Tool Version Installed from pip 22.0.2 apt Git 2.34.1 apt OpenJDK 19.0.1 apt GCC 11.4.0 apt Python3 3.10.12 apt OpenSSL 3.0.2 apt Ruby 3.0.2p107 apt Go 1.18.8 apt rustc 1.75.0 apt Flex 2.6.4 apt Ninja 1.10.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt make 4.3 apt cmake 3.22.1 apt","title":"Tools on J-QMS-1 node"},{"location":"tooling_J-QMU-1J-VM-1/","text":"Tools on J-x86-1 or J-QMU-1 node Tools which are mentioned for x86 architecture are able to run on J-x86-1 . Tools which are mentioned for RISC-V architecture are able to run on J-QMU-1 . The packages which are supported for QEMU User mode can be used by normal commands once they are loaded. Here PACKAGE_NAME is the package which you want to run on QEMU user mode. Operating System: Debian 11 (bullseye) QEMU User Mode Version: Different Versions (see the table below) Tooling available for J-x86-1 The tools available for J-x86-1 is for use on x86 architecture and these tools do not support execution on RISC-V architecture Tool Versions Installed from Host Architecture Environment Modules Support Git 2.3.0.2 source x86 N/A OpenJDK 19.0.1 apt x86 N/A GCC 10.4.0, 12.2.0 apt x86 Yes Python3 3.8.15, 3.9.2 source x86 Yes Go 1.18.8 apt x86 N/A rustc 1.65.0 source x86 N/A Flex 2.6.4 apt x86 N/A Ninja 1.10.1-1 apt x86 N/A Bison 3.7.5 apt x86 N/A autoconf 2.69 apt x86 N/A gperf 2.2.4 apt x86 N/A spike 1.1.1-dev source x86 Yes Verilator 4.038 apt x86 N/A Sail (riscv_sim_RV64, riscv_sim_RV32) 0.5 source x86 Yes cmake 3.18.4 apt x86 N/A make 4.3 apt x86 N/A ARM EABI GNU toolchain 13.2.Rel1 source x86 Yes qemu-system-arm 8.2.2 source x86 Yes SCons 4.7.0 source x86 Yes Tooling available for J-QMU-1 The tools available for J-QMU-1 is for use on RISC-V architecture and these tools do not support execution on x86 architecture Tool Versions Installed from Host Architecture Environment Modules Support Python3 3.8.15 source RISC-V Yes zlib 1.2.13 source RISC-V N/A OpenSSL 1.1.1r source RISC-V Yes Ruby (without IRB) 3.2.0dev source RISC-V Yes rustc 1.65.0 source RISC-V N/A Flex 2.6.4 source RISC-V yes Ninja 1.12.0.git source RISC-V Yes Bison 3.8.2, 2.3 source RISC-V Yes clang 16.0.0 source RISC-V (cross compiler) Yes riscv-pk 1.0.0-91-g573c858 source RISC-V Yes QEMU User mode and RISC-V GNU Cross compilers From now on RISC-V cross-compilers can only be loaded with their respective QEMU User mode on Cloud-V. This is configured so that there is no confusion between toolchain version and qemu user mode being used because both of these will be \"generally\" taken from the latest releases of nightly builds. Loading a certain RISC-V toolchain using environment modules will automatically load the respective qemu usermode version unless otherwise specified. The loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-glibc/<release-date> And the loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-elf/<release-date> Following table provides relevant information about version of the toolchain and the respective QEMU User mode version (where the release date is mentioned in pattern MMDDYYYY ). Release date GNU Toolchain version (elf and glibc) QEMU Version 03012024 13.2.0 8.2.1 02022024 13.2.0 8.2.1 02022024 13.2.0 8.1.1 Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"J-x86-1 or J-QMU-1"},{"location":"tooling_J-QMU-1J-VM-1/#tools-on-j-x86-1-or-j-qmu-1-node","text":"Tools which are mentioned for x86 architecture are able to run on J-x86-1 . Tools which are mentioned for RISC-V architecture are able to run on J-QMU-1 . The packages which are supported for QEMU User mode can be used by normal commands once they are loaded. Here PACKAGE_NAME is the package which you want to run on QEMU user mode. Operating System: Debian 11 (bullseye) QEMU User Mode Version: Different Versions (see the table below)","title":"Tools on J-x86-1 or J-QMU-1 node"},{"location":"tooling_J-QMU-1J-VM-1/#tooling-available-for-j-x86-1","text":"The tools available for J-x86-1 is for use on x86 architecture and these tools do not support execution on RISC-V architecture Tool Versions Installed from Host Architecture Environment Modules Support Git 2.3.0.2 source x86 N/A OpenJDK 19.0.1 apt x86 N/A GCC 10.4.0, 12.2.0 apt x86 Yes Python3 3.8.15, 3.9.2 source x86 Yes Go 1.18.8 apt x86 N/A rustc 1.65.0 source x86 N/A Flex 2.6.4 apt x86 N/A Ninja 1.10.1-1 apt x86 N/A Bison 3.7.5 apt x86 N/A autoconf 2.69 apt x86 N/A gperf 2.2.4 apt x86 N/A spike 1.1.1-dev source x86 Yes Verilator 4.038 apt x86 N/A Sail (riscv_sim_RV64, riscv_sim_RV32) 0.5 source x86 Yes cmake 3.18.4 apt x86 N/A make 4.3 apt x86 N/A ARM EABI GNU toolchain 13.2.Rel1 source x86 Yes qemu-system-arm 8.2.2 source x86 Yes SCons 4.7.0 source x86 Yes","title":"Tooling available for J-x86-1"},{"location":"tooling_J-QMU-1J-VM-1/#tooling-available-for-j-qmu-1","text":"The tools available for J-QMU-1 is for use on RISC-V architecture and these tools do not support execution on x86 architecture Tool Versions Installed from Host Architecture Environment Modules Support Python3 3.8.15 source RISC-V Yes zlib 1.2.13 source RISC-V N/A OpenSSL 1.1.1r source RISC-V Yes Ruby (without IRB) 3.2.0dev source RISC-V Yes rustc 1.65.0 source RISC-V N/A Flex 2.6.4 source RISC-V yes Ninja 1.12.0.git source RISC-V Yes Bison 3.8.2, 2.3 source RISC-V Yes clang 16.0.0 source RISC-V (cross compiler) Yes riscv-pk 1.0.0-91-g573c858 source RISC-V Yes","title":"Tooling available for J-QMU-1"},{"location":"tooling_J-QMU-1J-VM-1/#qemu-user-mode-and-risc-v-gnu-cross-compilers","text":"From now on RISC-V cross-compilers can only be loaded with their respective QEMU User mode on Cloud-V. This is configured so that there is no confusion between toolchain version and qemu user mode being used because both of these will be \"generally\" taken from the latest releases of nightly builds. Loading a certain RISC-V toolchain using environment modules will automatically load the respective qemu usermode version unless otherwise specified. The loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-glibc/<release-date> And the loading pattern for RISC-V 64-bit GNU Glibc toolchain will be as follows: module load riscv64-gnu-elf/<release-date> Following table provides relevant information about version of the toolchain and the respective QEMU User mode version (where the release date is mentioned in pattern MMDDYYYY ). Release date GNU Toolchain version (elf and glibc) QEMU Version 03012024 13.2.0 8.2.1 02022024 13.2.0 8.2.1 02022024 13.2.0 8.1.1 Note: The J-QMU-1 and J-x86-1 are one and the same runner. The purpose of creating two separate executors for same hardware is that J-x86-1 is supposed to be specifically for x86 architecture whereas J-QMU-1 is specifically for the users who want to cross compile source code for riscv64 architecture and then use qemu-usermode to execute them. Nevertheless, the tooling available for J-x86-1 can also be used for J-QMU-1","title":"QEMU User mode and RISC-V GNU Cross compilers"},{"location":"tooling_J-VF1-x/","text":"Tools on J-VF1-x node This compute instance is Starfive's VisionFive 1 board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 23.04 (Lunar Lobster) Tool Version Installed from Git 2.39.2 apt OpenJDK 21-ea apt GCC 13.1.0 apt Python3 3.11.4 apt OpenSSL 3.0.8 apt Ruby 3.1.2p20 apt Go 1.20.3 apt rustc 1.67.1 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.25.1 apt make 4.3 apt automake 1.16.5 apt gfortran 13.1.0 apt openssh-server 9.0p1 apt","title":"J-VF1-x"},{"location":"tooling_J-VF1-x/#tools-on-j-vf1-x-node","text":"This compute instance is Starfive's VisionFive 1 board and it has available packages ONLY for RISC-V architecture. Operating System: Ubuntu 23.04 (Lunar Lobster) Tool Version Installed from Git 2.39.2 apt OpenJDK 21-ea apt GCC 13.1.0 apt Python3 3.11.4 apt OpenSSL 3.0.8 apt Ruby 3.1.2p20 apt Go 1.20.3 apt rustc 1.67.1 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.25.1 apt make 4.3 apt automake 1.16.5 apt gfortran 13.1.0 apt openssh-server 9.0p1 apt","title":"Tools on J-VF1-x node"},{"location":"tooling_J-VF2-x/","text":"Tools on J-VF2-x node This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.43.0 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.7 apt OpenSSL 3.1.5 apt Ruby 3.1.2p20 apt Go 1.22.0 apt rustc 1.70.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.28.3 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.6p1 apt vim 9.1 apt","title":"J-VF2-x"},{"location":"tooling_J-VF2-x/#tools-on-j-vf2-x-node","text":"This compute instance is Starfive's VisionFive 2 board and it has available packages ONLY for RISC-V architecture. Operating System: Debian 12 (Bookworm) Tool Version Installed from Git 2.43.0 apt OpenJDK 21.0.2 apt GCC 13.2.0 apt Python3 3.11.7 apt OpenSSL 3.1.5 apt Ruby 3.1.2p20 apt Go 1.22.0 apt rustc 1.70.0 apt Flex 2.6.4 apt Ninja 1.11.1 apt Bison 3.8.2 apt autoconf 2.71 apt gperf 3.1 apt cmake 3.28.3 apt make 4.3 apt automake 1.16.5 apt gfortran 13.2.0 apt openssh-server 9.6p1 apt vim 9.1 apt","title":"Tools on J-VF2-x node"}]}
\ No newline at end of file
diff --git a/docs/sitemap.xml.gz b/docs/sitemap.xml.gz
index 1e35ca1ec9cfc7e80e565c789e43d77262f597f1..bd53aefe15fe0d96dccd5d8cd8f2219fbf666c31 100644
GIT binary patch
delta 11
Scmb=gXO-{f;8-`2wF&?fuLFDl

delta 11
Scmb=gXO-{f;Lw`LS_J?Sp91&*

diff --git a/mkdocs_src/docs/runner_specs.md b/mkdocs_src/docs/runner_specs.md
index 2b7e93e..6c7e78c 100644
--- a/mkdocs_src/docs/runner_specs.md
+++ b/mkdocs_src/docs/runner_specs.md
@@ -6,7 +6,7 @@ This document contains the specifications of the compute instances available for
 | ---- | ------- | -------------- | ------------ | ------------------ | ---- |
 | J-x86-1 (or) J-QMU-1 | x86_64 | N/A | 4 | 8GiB | Hardware with application-level emulator |
 | J-TESTVM-1 | x86_64 | N/A | 4 | 8GiB | Hardware |
-| J-RASP4-1 | aarch64 | 4 | 4GiB | Hardware | ARMv8-A |
+| J-RASP4-1 | aarch64 | ARMv8-A | 4 | 4GiB | Hardware |
 | J-QMS-1 | riscv64 | See Ext 1 at bottom | 2 | 2GiB | QEMU System emulator |
 | J-VF1-1 | riscv64 | rv64imafdc | 2 | 8GiB | Hardware |
 | J-VF1-2 | riscv64 | rv64imafdc | 2 | 8GiB | Hardware |