Checkpoint Lab — Wikis, Snippets, Discussions, Service Desk, Notifications, and Collaboration Utilities

1. Checkpoint mission and preflight

Your disposable project is becoming a real delivery workspace. Before Chapter 07 introduces merge requests in depth, design how information will move through the project without becoming fragmented or noisy.

• Mandatory: GitLab.com Free or equivalent Free project you own.
• Do not require: Premium/Ultimate group wiki, live customer email, Dedicated Service Desk, Self-Managed administrator access, cloud/Kubernetes, or paid compute.
• Safety: all names, emails, support content, snippets, and runbooks are synthetic. Never use a real secret.
• Evidence: create ch06-checkpoint/ locally; do not commit evidence containing personal email headers or private project data to a public repository.

2. Write the information-placement policy first

Create this small policy before the artifacts:

3. Classify five sample artifacts before implementation

Write your choice and one-sentence rationale for each:

1. “How to roll back the service safely” → project wiki unless release-coupled.
2. “Eight-line command that prints synthetic health state” → private project snippet.
3. “Should retry backoff be exponential?” → issue now; MR thread in Chapter 07 when discussing an actual code change.
4. “Customer cannot sign in” → Service Desk fixture/live Service Desk only in a safe supported setup.
5. “Please review this item today” → explicit assignee/reviewer plus narrow notification/To-Do signal, not a wiki page.

If your answer differs, justify it using durability, audience, sensitivity, required review, and operational dependency—not preference.

4. Make predictions before changing state

5. Implement the Free-safe collaboration surfaces

Create the synthetic wiki page, snippet, and issue from Lessons 1–2. Keep the commands narrow:

REPO="GROUP/collab-sandbox"
PROJECT_ID="123456"
mkdir -p ch06-checkpoint

# Baseline main-repository identity.
git fetch origin
DEFAULT_BRANCH="$(glab repo view -R "$REPO" --output json --jq '.default_branch')"
BEFORE_SHA="$(git rev-parse "origin/$DEFAULT_BRANCH")"
printf 'default_branch=%s
before_sha=%s
' "$DEFAULT_BRANCH" "$BEFORE_SHA"   | tee ch06-checkpoint/repo-before.txt

# Create the wiki page in UI: Plan -> Wiki -> New page.
# Title: CH06 Collaboration Runbook
# Content: synthetic rollback/triage guidance only.

cat > /tmp/ch06-health.sh <<'EOF'
#!/usr/bin/env bash
printf 'synthetic-health=ok
'
EOF
glab snippet create -R "$REPO"   --title "CH06 checkpoint health example"   --visibility private   /tmp/ch06-health.sh

# Create one synthetic issue through glab.
glab issue create -R "$REPO"   --title "[CH06 LAB] Decide retry documentation location"   --description "Synthetic collaboration checkpoint; no production data."

6. Verify predictions independently

Use at least two evidence surfaces for each prediction:

# Wiki inventory (hosted collaboration state).
glab api "projects/$PROJECT_ID/wikis" --paginate   --jq '.[] | select(.title=="CH06 Collaboration Runbook") | {slug,title,format}'   | tee ch06-checkpoint/wiki.json

# Main Git state should remain unchanged by the wiki operation.
git fetch origin
AFTER_SHA="$(git rev-parse "origin/$DEFAULT_BRANCH")"
printf 'after_sha=%s
' "$AFTER_SHA" | tee ch06-checkpoint/repo-after.txt
[ "$BEFORE_SHA" = "$AFTER_SHA" ] && echo "main_repo_unchanged_by_wiki=yes"

# Snippet state.
glab api "projects/$PROJECT_ID/snippets" --paginate   --jq '.[] | select(.title=="CH06 checkpoint health example") | {id,title,visibility,web_url}'   | tee ch06-checkpoint/snippet.json

# Synthetic issue state.
glab issue list -R "$REPO" --all --output json   --jq '[.[] | select(.title=="[CH06 LAB] Decide retry documentation location") | {iid,title,state}]'   | tee ch06-checkpoint/issue.json

7. Verify notification and To-Do behavior without spamming users

Record your personal project notification level in a local note. If you have a safe second training identity, you may optionally mention it in the synthetic issue and confirm that the account receives the expected To-Do/notification. Otherwise use your own account’s manual Mark as To-Do action and inspect:

glab api "todos?state=pending&project_id=$PROJECT_ID" --paginate   --jq '.[] | {id,action,target_type,state,created_at}'   | tee ch06-checkpoint/todos-pending.json

Then mark only your synthetic To-Do done in the UI and re-query. Verify that the issue remains open. That proves attention state and work-item state are separate.

8. Service Desk fixture and privacy review

Create a fixture, not a real ticket:

cat > ch06-checkpoint/service-desk.json <<'EOF'
{
  "offering_assumption": "GitLab.com or Self-Managed only",
  "sender": "customer@example.invalid",
  "subject": "Synthetic sign-in failure",
  "customer_account_id": "REDACTED-SYNTHETIC",
  "attachment_policy": "none for this lab",
  "expected_object": "Service Desk ticket",
  "external_reply_channel": "email",
  "internal_rule": "promote technical work to normal issue/MR without exposing unnecessary customer data"
}
EOF

Review the fixture as if it were real: which fields are personal data, who should see them, what can be copied into an engineering issue, and what must remain in the support context?

9. Draw the final trust and information-flow diagram

flowchart TD
EXT[External requester] -->|email, optional/simulated| SD[Service Desk]
SD --> ISSUE[Trackable issue/work item]
ISSUE --> THREAD[Conversation / decision]
THREAD --> WIKI[Durable runbook]
ISSUE --> MR[Chapter 07 merge request]
MR --> THREAD
EXAMPLE[Small diagnostic] --> SNIP[Private project snippet]
THREAD --> TODO[Personal To-Do]
THREAD --> MAIL[Email notification]
WIKI -.separate Git history.-> WREPO[Wiki repository]
MR -.source change.-> MAIN[Main repository]

10. Evidence manifest and verification checklist

• Project path/visibility and default branch recorded.
• Wiki page visible in UI and API.
• Main repository SHA unchanged by wiki creation.
• Snippet ID/title/visibility captured; no secret-like data exists.
• Synthetic issue exists and durable outcome points to wiki when appropriate.
• Personal To-Do behavior demonstrated without changing issue state.
• Service Desk fixture labels offering/mail/privacy assumptions.
• No paid, Dedicated, Self-Managed admin, cloud, Kubernetes, or compute-heavy requirement.

python - <<'PY2'
from pathlib import Path
import hashlib, json, datetime
root=Path('ch06-checkpoint')
files=[]
for p in sorted(root.glob('*')):
    if p.is_file():
        files.append({
            'file':p.name,
            'bytes':p.stat().st_size,
            'sha256':hashlib.sha256(p.read_bytes()).hexdigest()
        })
out={
    'captured_at_utc':datetime.datetime.now(datetime.timezone.utc).isoformat(),
    'files':files
}
Path('ch06-checkpoint-manifest.json').write_text(json.dumps(out,indent=2)+'
')
PY2
cat ch06-checkpoint-manifest.json

11. Cleanup and rollback

Preserve the evidence packet outside any public repository if it contains personal settings. Then remove only resources with the CH06 synthetic names.

• Delete the synthetic private snippet after confirming its exact ID/title.
• Delete the training wiki page if you do not want it for later chapters; otherwise keep it clearly labeled synthetic.
• Close the synthetic issue or leave it for Chapter 07 only if it is clearly scoped to the training workflow.
• Mark/clear only your synthetic To-Do.
• Remove /tmp/ch06-health.sh.
• Do not delete the project/group, rewrite history, or change Self-Managed mail configuration.

rm -f /tmp/ch06-health.sh

# Final inventories for proof of targeted cleanup.
glab api "projects/$PROJECT_ID/wikis" --paginate   --jq '.[] | {slug,title}' > ch06-checkpoint/wikis-final.json
glab api "projects/$PROJECT_ID/snippets" --paginate   --jq '.[] | {id,title,visibility}' > ch06-checkpoint/snippets-final.json

12. What Chapter 06 adds to the production operating model

The GitLab operating model now has six layers: platform boundaries (Chapter 01), identities/credentials (02), project governance (03), namespace authorization (04), work planning (05), and collaboration/information architecture (06). A production team can now explain not only who can change what and which work exists, but where knowledge, conversation, external intake, and attention signals belong.

Chapter 07 will apply these collaboration rules to the highest-impact code-change object: the merge request. Threads, mentions, reviewers, issue references, and durable documentation will converge around a concrete proposed change.

Knowledge check

Checkpoint summary

You defined placement policy before content, classified five artifact types, implemented project wiki/snippet/thread/attention surfaces on a Free-compatible path, modeled Service Desk without unsafe mail dependencies, predicted and independently verified state changes, captured evidence, and cleaned up narrowly. The project is now ready for Chapter 07’s merge-request collaboration model.

Official references

• GitLab Docs — Wiki
• GitLab Docs — Group wikis
• GitLab Docs — Project wikis API
• GitLab Docs — Snippets
• GitLab Docs — Snippets API
• GitLab Docs — Project snippets API
• GitLab Docs — glab snippet create
• GitLab Docs — Comments and threads
• GitLab Docs — Service Desk
• GitLab Docs — Configure Service Desk
• GitLab Docs — Use Service Desk
• GitLab Docs — Notification emails
• GitLab Docs — To-Do List
• GitLab Docs — To-Do List API
• GitLab Docs — Project settings
• GitLab Docs — REST API pagination