Follow-up from #24
The vdsm integration tests CI job (`.github/workflows/vdsm.yml`) currently runs with `continue-on-error: true` so it's not a blocking required check. This is deliberate — the job is new and needs a track record before we gate merges on it.
Promotion criteria
After 5+ consecutive green runs on `main`:
- Remove `continue-on-error: true` from `.github/workflows/vdsm.yml`
- Add `vdsm integration tests` to the branch protection required-checks list for `main`
- Close this issue
How to check the run history
```bash
gh run list -R cmeans/mcp-synology --workflow vdsm.yml --branch main --limit 10 \
--json conclusion,headBranch,event,createdAt \
--jq '.[] | select(.event == "push") | "(.createdAt[:10]) (.conclusion)"'
```
Count consecutive `success` entries from newest. When `\u2265 5`, promote.
Why not automate the promotion
Branch protection changes are high-blast-radius and benefit from a human decision — confirming the runs were genuinely representative (not just "a repeat of the cache-hit path on trivial PRs"), and making a conscious call to start gating merges.
Follow-up from #24
The vdsm integration tests CI job (`.github/workflows/vdsm.yml`) currently runs with `continue-on-error: true` so it's not a blocking required check. This is deliberate — the job is new and needs a track record before we gate merges on it.
Promotion criteria
After 5+ consecutive green runs on `main`:
How to check the run history
```bash
gh run list -R cmeans/mcp-synology --workflow vdsm.yml --branch main --limit 10 \
--json conclusion,headBranch,event,createdAt \
--jq '.[] | select(.event == "push") | "(.createdAt[:10]) (.conclusion)"'
```
Count consecutive `success` entries from newest. When `\u2265 5`, promote.
Why not automate the promotion
Branch protection changes are high-blast-radius and benefit from a human decision — confirming the runs were genuinely representative (not just "a repeat of the cache-hit path on trivial PRs"), and making a conscious call to start gating merges.