Provide a GitLab CI self-observation and work-scope handoff recipe with durable, explicit completeness
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Read the GitLab adapter work in #34 and #47, the observer availability issue #32, and the work-scope projection proposal in #54 first. Then identify the CLI/config and CI integration entry points once the adapter exists. Done means a checked GitLab fake-transport recipe and disposable pilot cover the listed failure cases, preserve verified history, and document capabilities, cadence, cost, and publication behavior.
Written by the indexing model from the issue text.
Description
Problem
Released v0.1.9 documents self-observation through a reusable GitHub Actions workflow. The GitLab adapter is already accepted/planned in #34 and #47; a GitLab CI consumer still needs a supported execution and handoff contract.
Uploading a temporary CI artifact alone is insufficient for durable history or reliable developer intake. A failed collection, expired artifact or a moving "latest" pointer can otherwise look like an empty queue.
Requested integration surface
After the existing GitLab adapter lands, provide a documented CLI/config example and CI include or recipe for self-hosted GitLab:
- Bind endpoint, numeric project identity, exact input refs and scoped read credential. Do not assume
CI_JOB_TOKENcan read every required API on every instance; document capability probes and required read scopes. Keep history/publication writers separate from repository readers. - A protected, non-gating observation job produces a verified bundle and a separately versioned work-scope artifact with five typed action queues. MR pipelines may produce candidate-local reports without protected writer secrets; they cannot replace the canonical default-branch scope.
- Scheduled refresh plus post-merge/event refresh should be supported with bounded request/time budgets, caching, serialization and a stated freshness interval. Collection must still publish its partial/unavailable status after a test or API failure. Do not make observation a prerequisite of the checks it reads.
- Persist immutable history in a private durable store; publish convenience "latest" only after complete validation. Bind it to bundle/scope digests, policy version, observation/expiry and repository revision. Do not commit observation output to the observed branch or create a pipeline feedback loop.
- Expose a compact Markdown view and machine-readable role/queue slices. Include total inventory coverage, overflow/cursor and excluded/blocked reasons.
- Consumer startup verifies digest/schema/freshness/repository binding and rechecks the selected item's current head, ownership, reviews and dependencies. Missing/stale scope emits one correlated recovery record; it does not instruct every developer to scan the entire project.
- Quota/pagination/authorization failures remain explicit. An observed empty queue, a blocked queue and unavailable input are different results. Keep the last verified history without advertising it as fresh.
Acceptance
- A checked example runs against a GitLab fake transport and a declared disposable/private pilot with explicit capability results.
- Positive/negative cases include unavailable issues/reviews/jobs, pagination truncation, rate limit, expired artifacts, wrong digest/project/head, concurrent publication and history-write failure.
- No automatic claims, issues, comments, merges or deployment are performed by the planner.
- Failure to collect cannot produce a fresh empty queue or overwrite valid history with a success claim.
- Run cost and cadence are documented; canonical publication never depends on successful project verification or triggers itself recursively.
Related: #34/#47 for the adapter and Instruments, #32 for observer availability. This is the consumer CI/handoff layer, not another GitLab adapter request.
Work-scope projection proposal: https://github.com/drevendev/Devostasis/issues/54
- Dominant language
- Python
- Stars
- 4
- Forks
- 1
- Avg merge
- 2m
- Merged PRs (30d)
- 2
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from drevendev/Devostasis
-
Difficulty 1/5 Under an hour Newbie friendliness 65/100
drevendev/Devostasis#25 ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
drevendev/Devostasis#86 · 3 comments ·
Maintainers usually reply within 2 days
-
Documentation delivery: a version-aware entry point for reports, work scopes and offline analysisOpen
Difficulty 5/5 Over a week Newbie friendliness 35/100
drevendev/Devostasis#85 ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 53/100
drevendev/Devostasis#84 · 1 comment ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
drevendev/Devostasis#83 · 3 comments ·
Maintainers usually reply within 2 days
All issues in drevendev/Devostasis
Similar issues
-
type-bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
push_gh-pages fails on master branch on forksPossibly taken A pull request linked to this issue is open or already merged. Opengood first issue infrastructure
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
kuznia-rdzeni/coreblocks#1135 ·
-
good first issue server
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
documentation priority: high
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
a-lex-s/mealie-telegram-bot#54 ·
Maintainers usually reply within 1 day