SDPT Lab 6 - Revizia istoricului

Rhobincu la 20 aprilie 2026 17:49

2026-04-20T17:49:47Z

Rhobincu: /* Phase 5: Continuous Deployment (CD) */

2026-04-19T17:27:43Z

Phase 5: Continuous Deployment (CD)

Rhobincu: /* Phase 5: Continuous Deployment (CD) */

2026-04-19T17:08:20Z

Phase 5: Continuous Deployment (CD)

Rhobincu la 19 aprilie 2026 17:05

2026-04-19T17:05:52Z

Afișare diferențe

Rhobincu: Pagină nouă: = Week 6 Lab Activity: Continuous Integration (CI) with GitLab = == Objective == Today, we automate everything. You will transition from compiling code on your laptop to architect...

2026-04-19T17:03:02Z

Pagină nouă: = Week 6 Lab Activity: Continuous Integration (CI) with GitLab = == Objective == Today, we automate everything. You will transition from compiling code on your laptop to architect...

Pagină nouă

= Week 6 Lab Activity: Continuous Integration (CI) with GitLab =

== Objective ==
Today, we automate everything. You will transition from compiling code on your laptop to architecting a professional CI pipeline. You will use your Docker image from last week to cross-compile your C++ code, run your Google Tests in QEMU, and configure GitLab to mechanically prevent broken code from ever reaching the <code>main</code> branch.

We will accomplish this in four phases:
# '''Repository Setup:''' Migrating your code to GitLab.
# '''The Build Stage:''' Writing your first CI job and generating Artifacts.
# '''The Test Stage:''' Consuming Artifacts and failing the pipeline on bad tests.
# '''Merge Checks:''' Enforcing quality control via Merge Requests.

----

== Phase 1: Repository Setup ==
To use GitLab CI, your code must live on a GitLab server.

'''1. Create a Project:'''
Log into GitLab and create a new blank project named <code>sdpt-smart-oven</code>. Uncheck "Initialize repository with a README".

'''2. Push Your Code:'''
Open your terminal on your laptop, navigate to your Week 5 project folder, and push your code to this new repository.
<syntaxhighlight lang="bash">
git init
git branch -m main
git remote add origin https://gitlab.com/<your-username>/sdpt-smart-oven.git
git add .
git commit -m "Initial commit: Oven Controller with CMake and Docker"
git push -u origin main
</syntaxhighlight>

----

== Phase 2: The Build Stage & Artifacts ==
We will now tell the GitLab Runner how to build our code using the Docker image you designed last week.

'''Your Challenge:'''
Create a file named exactly <code>.gitlab-ci.yml</code> in the root of your project. Write the YAML to meet these specifications:

# '''Image:''' Set the global <code>image:</code> to the Docker registry URL of the ARM image you built in Week 5 (or use a public equivalent provided by the instructor, e.g., <code>registry.gitlab.com/sdpt-course/arm-build-env:latest</code>).
# '''Stages:''' Define two stages: <code>build</code> and <code>test</code>.
# '''The Build Job:''' Create a job named <code>compile_firmware</code>.
#* Assign it to the <code>build</code> stage.
#* In the <code>script</code> section, create a build folder, run CMake for the <code>aarch64</code> compiler, and run <code>make</code>.
# '''Artifacts:''' Tell GitLab to save the <code>build/</code> directory as an artifact that expires in 1 hour. (If you forget this, your compiled binary will be deleted before the test stage starts!)

Commit and push this file. Go to your GitLab project -> '''Build''' -> '''Pipelines'''. You should see your pipeline running! Click on it to watch the live terminal output of the GitLab Runner.

----

== Phase 3: The Test Stage ==
Once your build job turns green, it's time to test the artifact.

'''Update your YAML:'''
Add a second job named <code>verify_logic</code> to your <code>.gitlab-ci.yml</code>:
# Assign it to the <code>test</code> stage.
# Use the <code>dependencies:</code> keyword to explicitly require the artifacts from <code>compile_firmware</code>.
# In the <code>script</code> section, navigate to the <code>build/</code> directory and execute your tests using QEMU (<code>qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./unit_tests</code>).

Push the updated YAML. Watch the pipeline. The Runner will download the compiled binary from the previous stage and execute your tests!

----

== Phase 4: Merge Checks and Failure (The DevOps Climax) ==
A pipeline is useless if developers can just bypass it. We will now configure GitLab to block bad code.

'''1. Protect the Main Branch:'''
In GitLab, go to '''Settings''' -> '''Merge Requests'''.
Scroll down to '''Merge checks''' and check the box that says: ''"Pipelines must succeed"''. Save changes.

'''2. Create a Feature Branch:'''
Back on your laptop terminal, create a new branch:
<syntaxhighlight lang="bash">
git checkout -b feature/broken-sensor
</syntaxhighlight>

'''3. Sabotage the Code!'''
Open your <code>test_oven.cpp</code> file. Intentionally change a mathematical assertion so that it will fail (e.g., change <code>EXPECT_EQ(temp, 100);</code> to <code>EXPECT_EQ(temp, 999);</code>).

'''4. Push and Open a Merge Request:'''
Commit your broken test and push the branch to GitLab.
<syntaxhighlight lang="bash">
git commit -am "feat: updated sensor logic (with bugs)"
git push -u origin feature/broken-sensor
</syntaxhighlight>
In GitLab, open a '''Merge Request''' from your feature branch into <code>main</code>.

'''5. Observe the Block:'''
Wait for the pipeline to run. The Build stage will pass, but the Test stage will turn RED because Google Test caught your broken math.
Look at the Merge Request page. '''The Merge button is physically disabled!''' GitLab has successfully protected your production code from human error.

'''6. Fix and Merge:'''
Fix the test on your laptop, commit, and push again. The pipeline will automatically re-run, turn green, and unlock the Merge button. Click Merge!

----
=== Assignment Submission ===
Upload '''ONLY''' your finalized <code>.gitlab-ci.yml</code> to the Moodle VPL assignment. The automated grading server will analyze your YAML syntax to ensure you correctly configured the stages, artifacts, and QEMU execution.

@@ Linia 23: / Linia 23: @@
 git init
 git branch -m main
-git remote add origin https://gitlab.com/<your-username>/sdpt-smart-oven.git
+git remote add origin https://gitlab.cs.pub.ro/<your-username>/sdpt-smart-oven.git
 git add .
 git commit -m "Initial commit: Oven Controller with CMake and Docker"
@@ Linia 48: / Linia 48: @@
 docker exec -it my-local-runner gitlab-runner register
 </syntaxhighlight>
-* '''GitLab instance URL:''' <code>https://gitlab.com/</code>
+* '''GitLab instance URL:''' <code>https://gitlab.cs.pub.ro/</code>
 * '''Registration token:''' (Paste your token from step 1)
 * '''Description:''' My Laptop Runner

@@ Linia 113: / Linia 113: @@
 # <code>dependencies:</code> Pull from <code>compile_firmware</code>.
 # '''Rules:''' We want this to be an "On-Demand" job that requires a human to click a play button. Add a <code>rules:</code> section with <code>- when: manual</code>.
-# <code>script:</code> Simulate securely pushing the binary to a specific IP address using an environment variable (<code>$TARGET_IP</code>):
+# <code>script:</code> Simulate securely pushing the binary to a specific IP address using an environment variable (<code>$TARGET_IP</code>). Do not hardcode an IP here; we will inject it later!
 #* <code>echo "Connecting to Edge Device at $TARGET_IP..."</code>
 #* <code>echo "scp build/unit_tests admin@$TARGET_IP:/opt/smart-oven/bin/"</code>
@@ Linia 122: / Linia 122: @@
 # You will see the <code>release_ota_firmware</code> job run automatically.
 # The <code>deploy_to_edge_device</code> job will be paused (marked with a "Play" icon).
-# Click the Play icon, and GitLab will allow you to manually input a value for <code>TARGET_IP</code> before executing the push!
+# Click the Play icon. GitLab will take you to a new screen asking if you want to inject any environment variables.
 == Phase 6: Cleanup ==

@@ Linia 92: / Linia 92: @@
 == Phase 5: Continuous Deployment (CD) ==
-Once the code hits the <code>main</code> branch, we want to automatically package it for an Over-The-Air (OTA) firmware update.
+Once the code hits the <code>main</code> branch, we want to handle two different types of deployments: an automated OTA release (Pull), and an on-demand Edge deployment (Push).
-'''Your Challenge (Part 3):'''
+'''Your Challenge (Part 3): Automated OTA Release'''
-Add a final job named <code>release_ota_firmware</code>:
+Add a job named <code>release_ota_firmware</code>:
 # Stage: <code>deploy</code>
 # Tags: <code>local-embedded</code>
@@ Linia 102: / Linia 102: @@
 #* <code>mv build/unit_tests build/firmware_v1.bin</code>
 #* <code>echo "CRYPTOGRAPHIC_SIGNATURE_OK" >> build/firmware_v1.bin</code>
-# '''Rules:''' We ONLY want to release firmware from the main branch! Add a <code>rules:</code> section with <code>- if: '$CI_COMMIT_BRANCH == "main"'</code>.
+# '''Rules:''' We ONLY want to release firmware automatically from the main branch! Add a <code>rules:</code> section with <code>- if: '$CI_COMMIT_BRANCH == "main"'</code>.
 # '''Artifacts:''' Save <code>build/firmware_v1.bin</code> as an artifact that never expires.
-Push to main. You should see a 3-stage pipeline complete successfully. You can now download your final "signed" firmware directly from the GitLab UI!
+'''Your Challenge (Part 4): On-Demand Push Deployment'''
-----
+Add another job named <code>deploy_to_edge_device</code>:
 == Phase 6: Cleanup ==