Feature/lab3

.github/workflows/lab3.yml

@@ -0,0 +1,37 @@
+name: Lab 3 CI
+
+on:
+  push:
+    branches:
+      - feature/lab3
+  workflow_dispatch:
+
+jobs:
+  hello:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Print basic info
+        run: |
+          echo "Triggered by: $GITHUB_EVENT_NAME"
+          echo "Branch: $GITHUB_REF"
+          echo "Commit: $GITHUB_SHA"
+          date
+          ls -la
+
+      - name: System information
+        run: |
+          echo "=== OS / Kernel ==="
+          uname -a
+          echo
+          echo "=== CPU ==="
+          nproc
+          lscpu | head -n 30 || true
+          echo
+          echo "=== Memory ==="
+          free -h || true
+          echo
+          echo "=== Disk ==="
+          df -h

labs/submission1.md

@@ -0,0 +1,27 @@
+# Lab 1 — Submission
+
+## Task 1 — SSH Commit Signing
+
+### Benefits of signed commits
+Signed commits provide cryptographic proof that a commit was created by a trusted author and was not modified after being created. This ensures the integrity of the codebase and protects against malicious or accidental tampering with commit history. Commit signing also establishes clear authorship, which is critical in collaborative and distributed teams. In CI/CD pipelines, signed commits increase trust in automated processes by guaranteeing that only verified code is built and deployed. From a security perspective, commit signing helps prevent supply chain attacks. Overall, signed commits improve transparency, accountability, and trust in the development workflow.
+
+### Evidence
+- Screenshot showing the “Verified” badge on a signed commit in GitHub.
+- SSH-based commit signing is configured using an ed25519 SSH key. Commits are created with `git commit -S`, and GitHub successfully verifies them as signed.
+
+### Why is commit signing important in DevOps workflows?
+In DevOps workflows, commit signing is important because it ensures that only authenticated and trusted changes enter the codebase. It helps teams maintain a secure and auditable development process, especially when multiple contributors and automated systems are involved. Signed commits integrate well with CI/CD pipelines by adding an additional layer of trust before builds and deployments. This practice reduces the risk of unauthorized code changes and improves overall security posture.
+
+---
+
+## Task 2 — PR Template & Checklist
+
+### Evidence
+- Screenshot showing that the pull request description is automatically populated from `.github/pull_request_template.md`.
+- The PR template file `.github/pull_request_template.md` is located on the `main` branch of the forked repository.
+
+### How PR templates improve collaboration
+PR templates standardize the information provided by contributors, making pull requests easier and faster to review. They ensure that the purpose of the change, the list of modifications, and verification steps are always documented. Checklists reduce the chance of missing important steps such as documentation updates or security checks. This leads to more consistent reviews, better communication between team members, and higher overall code quality. As a result, PR templates streamline collaboration and reduce friction in team workflows.
+
+### Challenges
+None.

labs/submission2.md

@@ -0,0 +1,203 @@
+# Lab 2 Submission
+
+## Task 1 --- Git Object Model Exploration
+
+### Commands
+
+``` sh
+echo "Test content" > test.txt
+git add test.txt
+git commit -m "Add test file"
+git log --oneline -1
+git cat-file -p HEAD
+git cat-file -p edfdd8ae877cc522b0ead2e18c764afa356a252b
+git cat-file -p 2eec599a1130d2ff231309bb776d1989b97c6ab2
+```
+
+### Outputs
+
+**Commit object:**
+
+    tree edfdd8ae877cc522b0ead2e18c764afa356a252b
+    Add test file
+
+**Tree object (excerpt):**
+
+    100644 blob 2eec599a1130d2ff231309bb776d1989b97c6ab2    test.txt
+
+**Blob object:**
+
+    Test content
+
+### Explanation
+
+-   **Blob:** stores raw file content.
+-   **Tree:** directory snapshot mapping names → blobs/trees.
+-   **Commit:** metadata + pointer to root tree (repo snapshot).
+
+**Storage model:** Git stores file data as blobs, directory structure as
+trees, and commits reference trees to represent full project snapshots.
+
+
+
+
+
+
+
+
+## Task 2 — Reset and Reflog Recovery
+
+### Commands + key outputs
+
+Initial history:
+```sh
+git log --oneline -5
+c92cc02 (HEAD -> git-reset-practice) Third commit
+6b137ff Second commit
+da62d38 First commit
+````
+
+Soft reset (move HEAD back, keep index + working tree):
+
+```sh
+git reset --soft HEAD~1
+git log --oneline -5
+6b137ff (HEAD -> git-reset-practice) Second commit
+da62d38 First commit
+
+git status
+Changes to be committed:
+  modified: file.txt
+```
+
+Hard reset (move HEAD back, discard index + working tree changes):
+
+```sh
+git reset --hard HEAD~1
+git log --oneline -5
+da62d38 (HEAD -> git-reset-practice) First commit
+
+git status
+nothing to commit, working tree clean
+```
+
+Reflog + recovery:
+
+```sh
+git reflog -10
+c92cc02 HEAD@{2}: commit: Third commit
+...
+
+git reset --hard c92cc02
+git log --oneline -5
+c92cc02 (HEAD -> git-reset-practice) Third commit
+6b137ff Second commit
+da62d38 First commit
+```
+
+### Explanation
+
+* `git reset --soft`: история (HEAD) откатывается, но изменения остаются в **index (staged)** и рабочей директории.
+* `git reset --hard`: история откатывается и изменения удаляются из **index** и **working tree**.
+* `git reflog` показывает прошлые положения HEAD, поэтому можно восстановиться, сделав `git reset --hard <hash>` на нужное состояние.
+
+
+
+
+
+## Task 3 — Visualize Commit History
+
+Graph:
+```sh
+git log --oneline --graph --all --decorate
+* dae0f56 (side-branch) Side branch commit
+* d580171 (HEAD -> feature/lab2) docs: add task2
+| * c92cc02 (git-reset-practice) Third commit
+| * 6b137ff Second commit
+| * da62d38 First commit
+|/  
+* 0bb29fa docs: add task1
+* ed0929f Add test file
+````
+
+Commit messages (from the graph): `Side branch commit`, `docs: add task2`, `Third commit`, `Second commit`, `First commit`, `docs: add task1`, `Add test file`.
+
+Reflection: `--graph --all` makes it clear where branches diverge and which commits belong to each branch.
+
+
+
+
+
+
+## Task 4 — Tagging Commits
+
+Commands:
+```sh
+git tag v1.0.0
+git show --oneline --no-patch v1.0.0
+git push origin v1.0.0
+````
+
+Tag info:
+
+```
+e7e523d docs: add task3
+```
+
+Why tags matter: tags mark release points, enable versioning, and are commonly used by CI/CD pipelines and release notes.
+
+
+
+
+## Task 5 — switch vs checkout vs restore
+
+### git switch (modern branch switching)
+```sh
+git switch -c cmd-compare
+git switch -
+````
+
+Switch cleanly toggles between branches.
+
+### git checkout (legacy)
+
+```sh
+git checkout -b cmd-compare-2
+git switch -
+```
+
+Checkout can create/switch branches but is overloaded.
+
+### git restore (file operations)
+
+Working tree restore attempt:
+
+```sh
+echo "scratch" >> demo.txt
+git restore demo.txt
+```
+
+Result: failed because the file was untracked.
+
+Index restore:
+
+```sh
+echo "scratch2" >> demo.txt
+git add demo.txt
+git restore --staged demo.txt
+```
+
+### When to use each
+
+* `git switch` — switching branches (clear intent).
+* `git restore` — restoring files or index state.
+* `git checkout` — legacy multi-purpose command.
+
+
+
+
+
+## GitHub Community
+
+Starring repositories helps bookmark useful projects and signals community trust and popularity.  
+Following developers supports networking, learning from others, and professional growth.

labs/submission3.md

@@ -0,0 +1,58 @@
+# Lab 3 — CI/CD (GitHub Actions)
+
+## Platform
+GitHub Actions
+
+---
+
+## Task 1 — First GitHub Actions Workflow
+
+### Workflow file
+- `.github/workflows/lab3.yml`
+
+### Evidence
+- Run link: https://github.com/vozamhcak/DevOps-Intro/actions/runs/22237239314
+
+### What triggered the run?
+- The workflow was triggered by a `push` to the `feature/lab3` branch.
+
+### Key concepts
+- **Workflow**: YAML configuration stored in `.github/workflows/`
+- **Jobs**: logical groups of steps executed on a runner
+- **Steps**: individual commands or actions inside a job
+- **Runner**: virtual machine that executes jobs (`ubuntu-latest`)
+- **Trigger**: event that starts workflow execution (`push`)
+
+### Notes / analysis
+- The workflow checks out the repository using `actions/checkout`.
+- It prints GitHub environment variables and basic system info.
+- Logs are accessible via the GitHub Actions UI (Actions → workflow run → job logs).
+
+
+
+---
+
+## Task 2 — Manual Trigger + System Information
+
+### Workflow changes
+- Added `workflow_dispatch` trigger to enable manual runs.
+- Extended workflow with a step that gathers runner system information.
+
+### Evidence (automatic run after changes)
+- Run link: https://github.com/vozamhcak/DevOps-Intro/actions/runs/22237477623
+
+### System information (excerpt from logs)
+Example data collected from runner:
+- OS: Ubuntu (GitHub-hosted runner)
+- CPU: multiple cores (nproc + lscpu output)
+- Memory: reported via `free -h`
+- Disk: reported via `df -h`
+
+### Manual vs automatic triggers
+- Automatic trigger: executed on push to `feature/lab3`.
+- Manual trigger: enabled via `workflow_dispatch` in workflow YAML.
+
+### Runner environment analysis
+- GitHub-hosted runners provide Linux-based ephemeral environments.
+- Each workflow run executes in a clean VM.
+- Useful for reproducible CI pipelines and testing.

test.txt

@@ -0,0 +1 @@
+Test content