R52 leaves Integrity permanently UNKNOWN for repositories verified only by external check apps
Maintainers usually reply within 9 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- github, python
- Domain
- ci-cd, observability
Research direction
Read the contracts cited in the issue (PV-CI-UNIT-004 R52 and PV-HIST-002 HIST-06/HIST-19), then compare the adapter’s check-suite sampling with GitHub’s GET /commits/{sha}/check-runs?filter=all surface. Decide whether that surface proves attempt completeness or whether parent-level passes need a visibly degraded path; document the contract decision and any history-lineage implications. Related issues #40 and #34 provide context.
Written by the indexing model from the issue text.
Description
Found while adopting PV-HIST-002 in 0.2.0.
What happens
The accepted history rule (PV-CI-UNIT-004 R52, PV-HIST-002 HIST-06 and HIST-19) says favorable evidence proves PASS_ONLY_OBSERVED only when the revision's whole verification history is observable, and that parent-level evidence cannot prove it: a GitHub check suite keeps its id when it is re-requested and shows only its latest outcome, so a passing suite may hide a failed earlier run. 0.2.0 implements that literally. A revision whose parents are check suites and whose visible outcome is a pass is UNKNOWN_HISTORY, and any revision in that state makes Integrity UNKNOWN, because T9 puts unknown history above every conservative branch.
For a repository whose verification comes only from external check apps (CircleCI, Buildkite, Travis and the like report through check suites; the adapter samples that surface exactly when no Actions run exists) that means:
- every passing revision is
UNKNOWN_HISTORY, and durable history cannot repair it, because no later bundle can observe the earlier attempts of a suite either; - Integrity is
UNKNOWNon every run for as long as the repository passes, and gets a band only when every revision in the window has failed.
On today's fleet no project is affected: every active revision in the 326 stored bundle directories is an attempt-complete Actions run. The first outside adopter (B7) is the likely first case, and a permanently UNKNOWN Integrity is the answer they would get.
Questions for the research side
- Is a permanent
UNKNOWNthe intended outcome for repositories that are verified only through parent-level surfaces? The alternative the contracts do not currently allow is a degraded path that counts parent-level passes with their provenance visible. - Would the check-runs surface count as attempt-level evidence?
GET /commits/{sha}/check-runs?filter=alllists every run of a suite, superseded ones included, each with its own id, so a re-requested failure stays visible. If it proves completeness, collecting it (roadmap C2, "external check apps alongside Actions") would give such repositories a real history instead ofUNKNOWN; that is a collection contract decision, and adopting it would version the history lineage (devostasis.ci-history.v2).
Related: #40 (which runs count as verification, and the vacuous UNINSTRUMENTED of a dormant repository with external CI), #34 (the durable-history adoption this follows from).
🤖 Generated with Claude Code
- Dominant language
- Python
- Stars
- 4
- Forks
- 1
- Avg merge
- 5d 12h
- Merged PRs (30d)
- 3
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 9 days
-
good first issue hacktoberfest help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 56/100
drevendev/Devostasis#78 ·
Maintainers usually reply within 9 days
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
drevendev/Devostasis#77 ·
Maintainers usually reply within 9 days
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
drevendev/Devostasis#76 ·
Maintainers usually reply within 9 days
-
Difficulty 3/5 1-2 days Newbie friendliness 25/100
drevendev/Devostasis#74 ·
Maintainers usually reply within 9 days
All issues in drevendev/Devostasis
Similar issues
-
Validate non-divisible effective batch sizes in the Unsloth LoRA backendPossibly taken @debesh-biswas claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
`rx.Model` event arguments emit `PydanticDeprecatedSince20` once per payload keyPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 1/5 Under an hour Newbie friendliness 88/100
reflex-dev/reflex#7634 · 1 comment ·
Maintainers usually reply within 2 days
-
documentation
Difficulty 1/5 1-3 hours Newbie friendliness 82/100
topoteretes/cognee#6239 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
ranaroussi/yfinance#3009 ·
Maintainers usually reply within 1 day
-
Test discovery aborts on GPU builds without cuStateVec: check_cuStateVec expects a failed result but set_config() now raises RuntimeErrorPossibly taken @dmeliksetian claimed this today. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Qiskit/qiskit-aer#2495 ·
Maintainers usually reply within 1 day