MIL-003: Shared quality checks
Metadata
Version History
| Date |
Status |
Author |
Reviewer |
Change |
Commit |
| 2026-10-10 |
Deprecated |
Jens Tirsvad Nielsen |
S01 |
Target date 2026-11-14 confirmed on 2026-10-10 by S01 (stand-in for S05) |
ea06eaa |
| 2026-10-10 |
Accepted |
Jens Tirsvad Nielsen |
S01 |
Task 1 verified: workflow_call and uses work from the same repository, the same organization and another organization (RC-033) |
b3f006f |
Purpose
Decide whether a software engineer can run the same quality checks on any
TirSystem project through a shared workflow.
Deliverable
A reusable quality-check workflow for Python and shell, used by at least one
other repository, and a guide for reading its results.
Go / No-Go Criteria
| # |
Criterion (objectively checkable) |
Go |
No-Go |
| 1 |
The instance supports reusable workflows (workflow_call), verified and recorded |
Verified |
Unsupported (re-plan as a copied template) |
| 2 |
One other repository runs the workflow and its status check appears on pull requests |
Appears |
Does not run |
| 3 |
A failing check shows the tool, file and message in the log |
Verified with a seeded failure |
Cause not visible |
| 4 |
Inputs and defaults are documented |
Documented |
Missing |
Dependencies
| Depends on |
Reason |
| MIL-002 |
Uses the onboarding guide and runner list |
Traceability
| Business Case objective / KPI / user story |
Reference |
| O4 |
BC-001 |
Ownership
| Role |
Stakeholder ID (SA) |
| Owner |
S05 |
| Approving reviewer |
S01 |
Target Date
2026-11-14 — confirmed on 2026-10-10 by S01, standing in for S05 (ADR-0002); the Business Case sets no deadline.
Tasks
| # |
Task |
Summary |
Needs its own Use Case/User Story? |
Reference |
| 1 |
Verify reusable workflow support |
Check whether this Gitea version supports workflow_call and cross-repository uses; if not, choose a copied template instead. Verified on 2026-10-10: supported, so no copied template is needed (see Verification results). |
No |
Verification results |
| 2 |
Define the quality-check contract |
Decide the inputs (language, tool versions, working directory) and what a pass and a fail mean. Start with Python and shell. This is something an engineer does, so it needs a use case first. |
Yes |
Use case candidate: run project quality checks |
| 3 |
Implement the reusable quality workflow |
Create the workflow in the canonical location with pinned tool versions and least-privilege permissions. |
No |
|
| 4 |
Adopt it in one other repository |
Onboard a real project and fix the gaps in the guide that appear. |
No |
|
| 5 |
Write the guide for reading results |
Explain status checks, logs and typical fixes so an engineer can make a failing check pass. |
No |
|
Verification results
Task 1 was run on 2026-10-10 on the instance (Gitea 1.27.3) with a throwaway
branch, verify-reusable-workflows, in TirSystem/github-action. The called
workflow declared on: workflow_call with one input and printed it; the
callers used jobs.<job_id>.uses. All branches were deleted afterwards.
| Call |
Caller |
Result |
uses: ./.gitea/workflows/reuse-callee.yml |
TirSystem/github-action (same repository) |
Called job ran; input received |
uses: TirSystem/github-action/.gitea/workflows/reuse-callee.yml@<branch> |
TirSystem/github-action |
Called job ran; input received |
| the same, from another repository of the organization |
TirSystem/sqa-qc-checklists |
Called job ran; gitea.repository was the caller |
| the same, from a repository of another organization |
TirSystem-BashScript/RepoFoundry |
Called job ran; gitea.repository was the caller |
What the test did not cover: a provider repository that is private (the
provider here is public), passing secrets to a called workflow
(secrets: or secrets: inherit), and a reference by tag instead of a
branch. The quality checks of this milestone need none of the secrets; a
private provider and tag references are for the release milestone (MIL-004).
