Build a Simple CI/CD pipeline with GitLab-Hosted Runners Learning Path ready for review

Author: mohamed-ismail99

content/learning-paths/cross-platform/GitLab-Managed-Runners/Create CICD Pipeline.md

@@ -0,0 +1,90 @@
+---
+title: "Create and Test a New Simple CI/CD Pipeline"
+weight: 15
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## How to Create a CI/CD Pipeline with Gitlab-hosted Runners?
+
+To create the pipeline we only need to create a new **`.gitlab-ci.yml`** file in our Project and define it's stages. Nothing else is needed since Gtilab-hosted runners are readily avilable to any Project and doesn't need to be created or instantiated by the Gitlab users.
+
+Once we run our pipeline with the correct **`tags`** Gitlab will create everything that we need and yep it is as simple as that.
+
+## How to Create .gitlab-ci.yml file in a Gitlab Project?
+
+1. Start by going to the main project page where we will need to Create the CI/CD pipeline.
+
+2. We can choose to create **`.gitlab-ci.yml`** file by using one of the 2 options circled in red in the image below. 
+![CI-CD-New #center](_images/CI-CD-New.png)
+
+Option1: We can Click on **`Set up CI/CD`** button/link and follow the wizad to create an empty **`.gitlab-ci.yml`** file.
+
+Option2: Click on the "+" button. From the popup menu click on **`New File`** option and name the file **`.gitlab-ci.yml`** and then click on **`Commit Changes`** button on the top right hand side like in the image below (Add any message as your commit message).
+![New-YML #center](_images/New-YML.png)
+
+3. A page like the one in the image below will be visible with our **`.gitlab-ci.yml`** file. From here, we will need to Click on the **`Edit`** button. A menu will pop up, We will click on **`Edit in pipeline Editor`** which will allow us to add our CD/CD script.
+![Editor-YML #center](_images/Editor-YML.png)
+
+4. In the pipeline editor, just copy and paste the following YML script and click on commit changes (Add any relevent message as your commit update message).
+```YML
+# This file is a template, and might need editing before it works on your project.
+# This is a sample GitLab CI/CD configuration file that should run without any modifications.
+# It demonstrates a basic 3 stage CI/CD pipeline. Instead of real tests or scripts,
+# it uses echo commands to simulate the pipeline execution.
+#
+# A pipeline is composed of independent jobs that run scripts, grouped into stages.
+# Stages run in sequential order, but jobs within stages run in parallel.
+#
+# For more information, see: https://docs.gitlab.com/ee/ci/yaml/#stages
+#
+# You can copy and paste this template into a new `.gitlab-ci.yml` file.
+# You should not add this template to an existing `.gitlab-ci.yml` file by using the `include:` keyword.
+#
+# To contribute improvements to CI/CD templates, please follow the Development guide at:
+# https://docs.gitlab.com/development/cicd/templates/
+# This specific template is located at:
+# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Getting-Started.gitlab-ci.yml
+
+stages:          # List of stages for jobs, and their order of execution
+  - build
+  - test
+  - deploy
+
+build-job:       # This job runs in the build stage, which runs first.
+  stage: build
+  tags:
+    - saas-linux-small-arm64    #Instruct Gitlab to use it's own Hosted runners that use Linux on Arm64 instance of size small.
+  script:
+    - echo "Compiling the code..."
+    - echo "Compile complete."
+
+unit-test-job:   # This job runs in the test stage.
+  stage: test    # It only starts when the job in the build stage completes successfully.
+  tags:
+    - saas-linux-small-arm64    #Instruct Gitlab to use it's own Hosted runners that use Linux on Arm64 instance of size small.
+  script:
+    - echo "Running unit tests... This will take about 60 seconds."
+    - sleep 60
+    - echo "Code coverage is 90%"
+
+lint-test-job:   # This job also runs in the test stage.
+  stage: test    # It can run at the same time as unit-test-job (in parallel).
+  tags:
+    - saas-linux-small-arm64    #Instruct Gitlab to use it's own Hosted runners that use Linux on Arm64 instance of size small.
+  script:
+    - echo "Linting code... This will take about 10 seconds."
+    - sleep 10
+    - echo "No lint issues found."
+
+deploy-job:      # This job runs in the deploy stage.
+  stage: deploy  # It only runs when *both* jobs in the test stage complete successfully.
+  tags:
+    - saas-linux-small-arm64    #Instruct Gitlab to use it's own Hosted runners that use Linux on Arm64 instance of size small.
+  environment: production
+  script:
+    - echo "Deploying application..."
+    - echo "Application successfully deployed."
+```
+5. Once you commit the file updates, Gitlab will check the scripts for errors and will try to execute the pipeline directly. 

content/learning-paths/cross-platform/GitLab-Managed-Runners/Create a new project in Gitlab.md

@@ -0,0 +1,37 @@
+---
+title: "Create a New Project/Repo in GitLab"
+weight: 10
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Where Should We Start?
+
+Start by logging into your GitLab account or create a new one in the [Gitlab](https://gitlab.com/) main page.
+
+We will need to a new project/repo that will contain all our project files including our **`CI/CD`** pipeline configuration file. 
+
+We can also choose to use any previously created projects in our Gitlab account. Simply open your previously created project. If that is the case then skip the rest of the steps in the current page and move to the next steps in this tutorial.
+
+## Create a New Project in Gitlab
+
+1. From the Home page, Click on the **`Projects`** icon from the menu on the left hand side panel as the image below.  
+
+2. Click on the **`New Project`** button on the top right hand side as the image below.
+![Gitlab-Projects #center](_images/Gitlab-Projects.png)
+
+3. We will get a new screen like the image below with multiple options. You can choose any of the 2 options highlighted in red from the image below.
+
+{{% notice Note %}}
+If we chose option 2 then we will need to choose **`GitLab CI/CD components`** option from the list of templates.
+{{%/notice%}}
+
+![New-Project #center](_images/New-Project.png)
+
+4. Regardles of which option we choose, We will get a screen like the image below where we need to fill-in fields highlighted in red. The first field is the **`Project Name`** which we will name it **`CI-CD Runner`**. In the second field we need to choose any option from the **`Project Url`** list then click on the  **`Create Project`** button at the end of the page.
+![Project-Info #center](_images/Project-Info.png) 
+
+##### **If we did everything correctly then we should get a screen like the one in the image below.**
+![Project-Done #center](_images/Project-Done.png)
+

content/learning-paths/cross-platform/GitLab-Managed-Runners/Important Information.md

@@ -0,0 +1,51 @@
+---
+title: "Important Information"
+weight: 5
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## What is a GitLab runner?
+A GitLab Runner works with GitLab CI/CD to run jobs in a pipeline. It acts as an agent and executes the jobs you define in your GitLab CI/CD configuration. Some key points to note about GitLab Runner:
+
+1. GitLab offers multiple types of runners - You can use GitLab-hosted runners, self-managed runners, or a combination of both. GitLab manages GitLab-hosted runners, while you install and manage self-managed runners on your own infrastructure.
+
+2. Each runner is configured as an Executor - When you register a runner, you choose an executor, which determines the environment in which the job runs. Executors can be Docker, Shell, Kubernetes, etc.
+
+3. Multi-architecture support: GitLab runners support multiple architectures including - **`x86/amd64`** and **`arm64`**.
+
+## What is Google Axion?
+Axion is Google's first Arm-based server processor, built using the Armv9 Neoverse V2 CPU. The VM instances are part of the **`C4A`** family of compute instances. To learn more about Google Axion refer to this [page](http://cloud.google.com/products/axion/) .
+
+{{% notice Note %}}
+All The information provided in the next section are from GitLab official Pages and it's provided here for convenience and can be changed by Gitlab at anytime. Please refer to the [Gitlab Documentation](https://docs.gitlab.com/ci/runners/hosted_runners/) for more details and for the latest updates.
+{{% /notice %}}
+
+## GitLab-Hosted Runners Facts
+
+1. Each of your jobs runs in a newly provisioned VM, which is dedicated to the specific job.
+
+2. The storage is shared by the operating system, the container image with pre-installed software, and a copy of your cloned repository. This means that the available free disk space for your jobs to use is reduced.
+
+3. Untagged jobs run on the **`small`** Linux x86-64 runner.
+
+4. Jobs handled by hosted runners on GitLab.com time out after 3 hours, regardless of the timeout configured in a project.
+
+5. The virtual machine where your job runs has **`sudo`** access with no password.
+
+6. Firewall rules only allow outbound communication from the ephemeral VM to the public internet.
+
+7. Inbound communication from the public internet to the ephemeral VM is not allowed.
+
+8. Firewall rules do not permit communication between VMs.
+
+9. The only internal communication allowed to the ephemeral VMs is from the runner manager.
+
+10. Ephemeral runner VMs serve a single job and are deleted right after the job execution.
+
+11. In addition to isolating runners on the network, each ephemeral runner VM only serves a single job and is deleted straight after the job execution. In the following example, three jobs are executed in a project’s pipeline. Each of these jobs runs in a dedicated ephemeral VM.
+
+12. GitLab sends the command to remove the ephemeral runner VM to the Google Compute API immediately after the CI job completes. The [Google Compute Engine hypervisor](https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext) takes over the task of securely deleting the virtual machine and associated data.
+
+13. The hosted runners share a distributed cache stored in a Google Cloud Storage (GCS) bucket. Cache contents not updated in the last 14 days are automatically removed, based on the [object lifecycle management policy](https://cloud.google.com/storage/docs/lifecycle). The maximum size of an uploaded cache artifact can be 5 GB after the cache becomes a compressed archive.

content/learning-paths/cross-platform/GitLab-Managed-Runners/Pipeline Script explanation and test results.md

@@ -0,0 +1,56 @@
+---
+title: "Pipeline Script Explanation and Test Results"
+weight: 20
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Pipeline Script explanation:
+
+The Pipeline script has multiple sections where each section instructs the pipeline operator on what todo or use and how each Stage looks like.
+
+### First Section: Stages
+
+In this section we are describing how many squentional stages will our pipeline have and what are their names (ex. **`Build, Test and Deploy`**). If we would like all the stages or jobs to run simultinously then we simply don't define this section.
+
+### Second Section: Build-Job part of the Build stage
+
+In this section we are defining the Build-Job as part of the Build stage. This stage will run on Gitlab-Hosted runner that uses Linux OS on Arm64 instance of size small.
+
+{{% notice Important Note %}}
+Gitlab offers 3 Arm64 based Instances that use Linux as their OS.
+
+- saas-linux-small-arm64
+- saas-linux-medium-arm64
+- saas-linux-large-arm64
+
+For more information about all Arm and other avilable Gitlab-hosted runners check [Gitlab-Hosted Runners](https://docs.gitlab.com/ci/runners/hosted_runners/linux/) page.
+
+{{%/notice%}}
+
+### Other Sections: 
+
+The rest of the other sections follow the same patthern. You will notice that the **`Test`** stage for example has 2 Jobs in it (unit-test-job and lint-test-job). The **`Deploy`** stage here has only 1 Job called **`deploy-job`**.
+As you get to learn more YML scripting you will be able to add a lot more complex functionality to your pipelines.
+
+{{%notice Note%}}
+Gitlab offers a lot of documentions on how to create pipeline that fits different needs and also offer common templates for them as well. You can access then from [Use CI/CD to build your application](https://docs.gitlab.com/topics/build_your_application/) page.
+{{%/notice%}}
+
+## How to run your pipeline for testing and to check the results:
+
+From the left hand side panel, Navigate to **`Build`** then to **`Pipeline`** then click on **`New pipeline`** button on the top right hand side just like the image below. In the new window click on **`New pipeline`** button again and your pipeline will start to execute.
+![New-Pipeline #center](_images/New-Pipeline.png)
+
+To check the status of your pipeline and to check the output of any of it's Jobs simply click on any of the **`Jobs`** as the image below (with red rectangle around them).
+![pipeline-execution #center](_images/Pipeline-execution.png)
+
+## Gitlab Helpful tools
+
+If you navigate to your pipeline editor from before you will notice that there are more tabs in that page other than the **`Edit`** tab. ![visual-pipeline #center](_images/Visual-pipeline.png)
+
+### The other Tabs are:
+
+1. Visualize: which can visulaize your pipeline for you as you edit it's componenets which can be very helpful especially for complex pipelines.
+2. Validate: which can validate your pipeline script as you are editting them and saving from time to time so that you can catch any issues with you code early on.