Feature/lab4

.github/pull_request_template.md

@@ -0,0 +1,13 @@
+## Goal
+<!-- What does this PR accomplish? 1 sentence. -->
+
+## Changes
+- 
+
+## Testing
+<!-- How did you verify it? -->
+
+## Checklist
+- [ ] Title is a clear sentence (≤ 70 chars)
+- [ ] Commits are signed (`git log --show-signature`)
+- [ ] `submissions/labN.md` updated

labs/lab1.md

@@ -91,9 +91,20 @@ git config --global commit.gpgsign true
 git config --global tag.gpgsign true
 ```
 
-Tell the platform your SSH key is a **signing key**:
-- GitHub: Settings → SSH and GPG keys → **New SSH key**, key type **Signing Key**
-- GitLab: Profile → SSH Keys → tick "Usage type: Authentication & signing"
+Now register the key on the platform. GitHub treats **Authentication** and **Signing** as *separate* roles for the same key, so you add it under both:
+
+- **Authentication Key** — lets you `clone` / `fetch` / `push` over SSH (`git@github.com:…`). If you cloned over HTTPS, or have never seen `ssh -T git@github.com` greet you by name, you don't have one configured yet — add it now or the `upstream` SSH remote will fail in Lab 2.
+- **Signing Key** — gives your commits the **Verified** badge.
+
+- 🐙 GitHub: Settings → SSH and GPG keys → **New SSH key** → add the **same** `~/.ssh/id_ed25519.pub` **twice**, once with Key type **Authentication Key** and once with **Signing Key**.
+- 🦊 GitLab: Profile → SSH Keys → a single key with **Usage type: Authentication & signing** covers both.
+
+Confirm authentication works before moving on:
+
+```bash
+ssh -T git@github.com
+# expect: Hi YOUR_USERNAME! You've successfully authenticated...
+```
 
 ### 1.4: Make a Signed Commit
 
@@ -303,7 +314,8 @@ In `submissions/lab1.md`:
 ## Common Pitfalls
 
 - 🪤 **PR template doesn't auto-populate** — make sure the template is on `main` *before* opening the PR
-- 🪤 **Commits show "Unverified"** — the SSH key must be added as a *Signing Key* on GitHub (not just an authentication key)
+- 🪤 **Commits show "Unverified"** — the key must also be added as a **Signing Key** on GitHub; an Authentication Key alone won't verify commits (they're separate roles — see §1.3)
+- 🪤 **`git@github.com: Permission denied (publickey)` on clone/fetch/push** — the *reverse* gap: your key is registered for signing but not as an **Authentication Key**. Add it as Authentication too (§1.3) and confirm with `ssh -T git@github.com`. Quick unblock for the *public* upstream: `git remote set-url upstream https://github.com/inno-devops-labs/DevOps-Intro.git`
 - 🪤 **`git push` rejected on `main`** — that's the bonus rule working as designed; push to `feature/lab1` instead
 - 🪤 **`gpg.format=ssh` ignored** — confirm Git ≥ 2.34: `git --version`
 - 🪤 **Pushed to the wrong branch** — `git switch feature/lab1` before `git push`

labs/lab2.md

@@ -223,6 +223,7 @@ git bisect reset
 
 ## Common Pitfalls
 
+- 🪤 **`git@github.com: Permission denied (publickey)` on `git fetch upstream`** — *not* a remote-config bug (the error is at the SSH layer, before Git reads the repo). Your key isn't registered for **authentication** on GitHub — and a **Signing Key** (Lab 1) does *not* count for auth, they're separate roles. Add the same `~/.ssh/id_ed25519.pub` as an **Authentication Key** (Lab 1 §1.3), verify with `ssh -T git@github.com`, then re-run. To unblock right now, the public upstream fetches over HTTPS with no key: `git remote set-url upstream https://github.com/inno-devops-labs/DevOps-Intro.git`
 - 🪤 **`reset --hard` without committing first** — your *uncommitted* edits really *are* gone (reflog only saves committed work). Always check `git status` first
 - 🪤 **`tag -v` says "no signature"** — you used `git tag NAME` instead of `git tag -a -s NAME -m "..."`
 - 🪤 **Rebase conflicts** — resolve, then `git rebase --continue`. Never `git rebase --skip` unless you know what you're skipping

labs/lab3.md

@@ -160,6 +160,23 @@ Tips:
 - GitLab: `parallel:matrix:`
 - Set `fail-fast: false` (GH) or equivalent so a single bad cell doesn't cancel the others — you want to *see* which combo broke
 
+> ⚠️ **The matrix renames your checks — update branch protection (1.6) or your PR blocks forever.** A matrixed `test` job reports as `test (1.23)` and `test (1.24)`; the old required check named `test` will sit at *"Expected — Waiting for status to be reported"* indefinitely, even though every real check is green. Two fixes:
+>
+> 1. **Quick:** in the branch-protection rule, replace `vet`/`test` with the matrixed names (`vet (1.23)`, `vet (1.24)`, `test (1.23)`, `test (1.24)`).
+> 2. **Robust (recommended):** add one aggregation job and require *only* it — then the matrix can change freely without touching protection settings:
+>
+> ```yaml
+> ci-ok:
+>   if: always()
+>   needs: [vet, test, lint]
+>   runs-on: ubuntu-24.04
+>   steps:
+>     - run: |
+>         test "${{ contains(needs.*.result, 'failure') || contains(needs.*.result, 'cancelled') }}" = "false"
+> ```
+>
+> The `if: always()` matters — without it, a failed `needs` job *skips* `ci-ok`, and a skipped required check lets the PR through on some configurations.
+
 ### 2.3: Skip docs-only changes
 
 Edit your trigger so the pipeline runs **only** when something in `app/` or your CI config itself changes. README edits should not burn 4 minutes of CI time.
@@ -179,6 +196,8 @@ Capture wall-clock times from the CI UI for three scenarios:
 
 > 💡 To get a clean baseline, temporarily disable each optimization with a commit, take a screenshot of the run time, then restore.
 
+> 🧪 **Expect the cache rows to be boring — that's the finding, not a failure.** QuickNotes has **zero third-party dependencies** (look at `app/go.mod` — no `require` block, no `go.sum`), so the module cache has nothing to store and total wall-clock barely moves with `cache: true` vs `cache: false`. Most of your 60–80 s is runner provisioning, checkout, and the Go toolchain download — none of which `setup-go`'s cache touches. Report what you measured and *explain why* (that's design question **f** in disguise). To see where caching *would* pay, compare the **per-step** durations (`setup-go`, `go test`) instead of job totals, and note which step a real dependency-heavy project would save on.
+
 ### 2.5: Document
 
 In `submissions/lab3.md`:
@@ -284,6 +303,8 @@ Answer in 4-6 sentences:
 - 🪤 **Forgot `working-directory` (or `cd app`) for Go commands** — Go modules live in `app/`, not the repo root; commands run from the root will fail with "no Go files"
 - 🪤 **`fail-fast: true` (the GH Actions default) in a matrix** — one fail cancels the others; you can't see *which* combo broke
 - 🪤 **Branch protection set on someone else's fork's `main`** — you can only protect *your* fork's `main`. The upstream course repo has its own protection
+- 🪤 **PR stuck on "Expected — Waiting for status to be reported" after adding the matrix** — the matrix renamed `test` → `test (1.23)`/`test (1.24)`, but branch protection still requires the old `test` context, which will never report again. Update the required-check names or switch to the `ci-ok` aggregation job (see §2.2)
+- 🪤 **"Caching didn't speed anything up"** — on a zero-dependency module that's the *correct* result, not a mistake (see §2.4); don't pad the timing table with numbers you didn't observe
 - 🪤 **`golangci-lint` version not pinned** — "latest" pulls a new release tomorrow that may flag your code with new rules. Pin `v2.5.0` exactly
 - 🪤 **GitLab CI: incorrect anchor syntax** (`<<: *name`) — GitLab is strict; use the in-platform CI Lint tool (`Project → CI/CD → Editor → Validate`)
 - 🪤 **Cache hits expire after 7 days of inactivity on GH** — that's expected; the cache key is what protects you against poisoning

submissions/lab1.md

@@ -0,0 +1,93 @@
+# Lab 1 submission
+
+## Task 1
+Request:
+```
+curl -s http://localhost:8080/health | python3 -m json.tool
+```
+
+Answer:
+```
+{
+    "notes": 5,
+    "status": "ok"
+}
+```
+
+Request:
+```
+curl -s http://localhost:8080/notes  | python3 -m json.tool
+```
+
+Answer:
+```
+[
+    {
+        "id": 2,
+        "title": "Read app/main.go first",
+        "body": "Start by understanding the entry point \u2014 env vars, signal handling, graceful shutdown.",
+        "created_at": "2026-01-15T10:05:00Z"
+    },
+    {
+        "id": 3,
+        "title": "DevOps mantra",
+        "body": "If it hurts, do it more often.",
+        "created_at": "2026-01-15T10:10:00Z"
+    },
+    {
+        "id": 4,
+        "title": "Endpoint cheat-sheet",
+        "body": "GET /notes  GET /notes/{id}  POST /notes  DELETE /notes/{id}  GET /health  GET /metrics",
+        "created_at": "2026-01-15T10:15:00Z"
+    },
+    {
+        "id": 1,
+        "title": "Welcome to QuickNotes",
+        "body": "This is the project you'll containerize, deploy, monitor, and harden across all 10 labs.",
+        "created_at": "2026-01-15T10:00:00Z"
+    }
+]
+```
+
+Request:
+```
+curl -s -X POST http://localhost:8080/notes \
+  -H 'Content-Type: application/json' \
+  -d '{"title":"hello","body":"first POST"}' | python3 -m json.tool
+```
+
+Answer:
+```
+{
+    "id": 5,
+    "title": "hello",
+    "body": "first POST",
+    "created_at": "2026-06-05T10:51:13.503497Z"
+},
+```
+
+```
+git log --show-signature -1
+
+commit 843a27f3ade36ea41d723f168fb3f8c9c1f7b70c (HEAD -> feature/lab1, origin/feature/lab1)
+Good "git" signature for 15dnau@gmail.com with ED25519 key SHA256:k0n7/mx/uRX52s/zu9pxaN+h/IKnBJzcnuybJgthVkM
+Author: Dmitrii <15dnau@gmail.com>
+Date:   Fri Jun 5 14:03:50 2026 +0300
+
+    docs(lab1): start submission
+
+    Signed-off-by: Dmitrii <15dnau@gmail.com>
+```
+
+### Verified commit
+
+![Verified commit](verified.png "Verified commit")
+
+When we work with Github we trust that commit made by Dmitrii was actually made by Dmitrii. However Git itself does not verify commit's author. Anyone can set any name and make a commit, therefore we want commits to be verified.
+
+### GitHub Community
+Why starring repositories matters in open source
+For a project, stars are a signal of trust and relevance. Moreover, starring is something like bookmarking a repository.
+
+How following developers helps in team projects and professional growth
+Following your colleagues on GitHub gives you a low-noise feed of their activity