Wikis, Snippets, Discussions, Service Desk, Notifications, and Collaboration Utilities: Guided Hands-On Workflow and Core Operations

1. Scenario and preflight

You maintain a disposable project called collab-sandbox. A small team needs three things: a durable “rollback checklist,” a tiny diagnostic script that is useful but not part of the application, and a place to discuss a synthetic support request. The goal is to implement each artifact on the correct GitLab surface and prove its state independently.

• Mandatory path: GitLab.com Free or equivalent Free project you own for training.
• Role: Maintainer/Owner for project feature settings; a normal Developer role can be used for many content operations.
• Tools: Git, glab, and optionally jq. Use the authenticated host from Chapter 02.
• Data: synthetic names and content only. No customer email, token, production hostname, private key, or incident log.
• Service Desk: live email is optional. The mandatory lab uses a fixture unless you deliberately choose a training mailbox/project.

2. Capture the before state

Record the project identity and existing collaboration inventory before you mutate anything.

REPO="GROUP/collab-sandbox"
PROJECT_ID="123456"   # replace with your disposable project ID
mkdir -p ch06-evidence

glab auth status
glab repo view -R "$REPO" --output json   --jq '{path_with_namespace,visibility,default_branch}'   | tee ch06-evidence/project-before.json

glab api "projects/$PROJECT_ID/wikis" --paginate   | tee ch06-evidence/wikis-before.json
glab api "projects/$PROJECT_ID/snippets" --paginate   | tee ch06-evidence/snippets-before.json
glab api "todos?state=pending&project_id=$PROJECT_ID" --paginate   | tee ch06-evidence/todos-before.json

3. Create a small wiki page and prove the separate-history model

Use the UI path Plan → Wiki when available and create a page titled Rollback checklist with deliberately synthetic content:

# Rollback checklist

1. Identify the last known-good release.
2. Freeze promotion while evidence is collected.
3. Compare source SHA and artifact identity.
4. Restore the known-good deployment through the normal path.
5. Verify service health and record follow-up work.

Then verify with the API:

glab api "projects/$PROJECT_ID/wikis" --paginate   --jq '.[] | {slug,title,format}'

# Record the main repository SHA before and after the wiki edit.
git fetch origin
MAIN_SHA="$(git rev-parse origin/main)"   # use the actual default branch if different
printf 'main_sha=%s
' "$MAIN_SHA" | tee ch06-evidence/main-sha.txt

The wiki page appears in the wiki inventory, while the main repository SHA remains unchanged unless you independently pushed code. That is the causal proof that the page belongs to a separate Git repository.

If you need to demonstrate the Git nature directly, the GitLab UI exposes a wiki clone URL. Clone it only to a temporary directory, run git log --oneline, and delete the local clone afterward. Do not confuse that clone with the application repository.

4. Create a synthetic project snippet safely

Create one harmless diagnostic example. Use a private project snippet even if the training project is public; this keeps the exercise conservative.

cat > /tmp/ch06-diagnostic.sh <<'EOF'
#!/usr/bin/env bash
printf 'synthetic-health=ok
'
EOF

glab snippet create -R "$REPO"   --title "CH06 synthetic health check"   --description "Disposable training snippet; no credentials"   --visibility private   /tmp/ch06-diagnostic.sh

# Verify project snippets through REST.
glab api "projects/$PROJECT_ID/snippets" --paginate   --jq '.[] | select(.title=="CH06 synthetic health check") | {id,title,visibility,web_url}'   | tee ch06-evidence/snippet-created.json

5. Create one controlled collaboration thread

Use a synthetic issue such as [CH06 LAB] Verify rollback documentation. Add one comment that asks a question and start a thread if the UI offers it. Resolve the thread only after adding the answer to the durable wiki page if the answer belongs in the runbook.

This workflow demonstrates a useful rule: conversation can discover knowledge; documentation should retain knowledge. The thread keeps the review history, while the wiki holds the reusable procedure.

6. Tune personal notifications without flooding anyone

Open your own notification preferences or the project’s bell menu. Record the current project notification level before changing it. The current levels include Global, Watch, Participate, On mention, Disabled, and Custom. The project setting can override group/global behavior for your account.

For a training project, Participate or On mention is usually safer than Watch. Do not change another user’s preferences or mention a real team/group to generate evidence.

7. Inspect To-Dos as evidence, not as the team backlog

To-Dos are personal. Use the API to inspect rather than blindly clear them:

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

A To-Do can be caused by assignment, mention, review request, a manual “mark as To-Do,” or other supported actions. Its presence proves GitLab thinks your attention is needed; it is not a replacement for the project backlog from Chapter 05.

8. Simulate Service Desk safely

The mandatory path does not send email. Instead, create this local evidence fixture and explain the trust boundary:

cat > ch06-evidence/service-desk-fixture.json <<'EOF'
{
  "external_sender": "customer@example.invalid",
  "subject": "Synthetic login failure",
  "body_classification": "support request",
  "attachments": [],
  "expected_gitlab_object": "Service Desk ticket",
  "privacy_rule": "do not copy customer PII into public snippets/wiki",
  "reply_path": "public ticket comment -> Service Desk email"
}
EOF
cat ch06-evidence/service-desk-fixture.json

If you deliberately run the optional live GitLab.com path, use only a disposable project and an email address you control. On Self-Managed, incoming email must already be configured by the instance administrator. Do not change instance mail routing for this chapter.

9. Before/after verification and challenge

Verify the expected state from independent surfaces:

• UI: wiki page exists and has page history.
• REST: wiki list includes its slug/title.
• Git: application default-branch SHA did not change because of the wiki edit.
• REST: snippet inventory includes the synthetic snippet with private visibility.
• UI/API: the synthetic issue/thread contains only collaboration context; durable runbook steps live in the wiki.
• Notification preferences: record your personal project level; do not infer anyone else’s.
• To-Do API: explain each synthetic attention item rather than counting it as backlog work.

Challenge: You receive a five-line reproducible shell command from a support requester. It contains no secret. Should it live in Service Desk, a snippet, the wiki, or the application repository? Choose one based on whether it is transient evidence, reusable diagnostic material, durable operational documentation, or product source—and state what would make you move it later.

10. Cleanup without destroying useful evidence

Remove only the synthetic content you created. Delete the snippet through the UI or current glab/API command after first recording its ID and visibility. Delete the synthetic wiki page only if it has no value for later lessons; otherwise clearly label it training-only. Close the synthetic issue/thread if appropriate and remove /tmp/ch06-diagnostic.sh.

rm -f /tmp/ch06-diagnostic.sh

# Re-inventory after cleanup; exact counts depend on what you chose to retain.
glab api "projects/$PROJECT_ID/wikis" --paginate   --jq '.[] | {slug,title}' > ch06-evidence/wikis-after.json
glab api "projects/$PROJECT_ID/snippets" --paginate   --jq '.[] | {id,title,visibility}' > ch06-evidence/snippets-after.json

Knowledge check

Summary

You created a versioned wiki page and snippet, proved their boundaries, used comments/threads as context rather than documentation storage, treated notifications and To-Dos as personal signal routing, and modeled Service Desk without requiring live customer email. Every important state was inspected before and after mutation.

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