What problem does this solve?
docs/learn/index.html hardcodes repository statistics that were correct when the page was
written and have drifted since. The page currently advertises:
| Statistic |
Page says |
Actual |
| Azure scan rules |
39 |
66 |
| CLI remediation playbooks |
39 |
66 |
| High-severity checks |
22 |
38 |
| Hero terminal ("dynamic checks") |
39 |
66 |
| Severity card (HIGH / MEDIUM / LOW) |
22 / 13 / 4 |
38 / 23 / 4 |
| "Coverage by category" chart |
omits Supply Chain and Kubernetes, Identity undercounted at 4 |
9 categories, Identity 15 |
README.md carries the same drift in four more places: the Misconfiguration Scanner and
Remediation Playbooks rows of the feature table, and both the Scanner Engine and
Azure CLI Playbooks nodes of the Mermaid architecture diagram (all reading 51).
Two problems follow from this:
- The Learn page understates the project. New contributors and evaluators land on it and
see roughly half the coverage OpenShield actually ships.
- It will drift again. Every scanner-rule PR that merges to
dev makes the numbers more
wrong, and nothing in CI notices. Manual correction is not sustainable at the rate rules
are being added.
Describe the solution
Two parts:
1. Correct the current numbers in docs/learn/index.html — the headline counts, the
pipeline step, the section title, the intro paragraph, the hero terminal, the severity card
and the category chart all repeat the same figures and must be updated together. README.md
needs the same treatment for its four stale counts.
2. Add a GitHub Actions workflow that keeps them correct. On every push to dev:
- Derive the counts from the codebase rather than from a checked-in constant:
- rule count from
scanner/rules/ (files that declare a RULE_ID)
- playbook count from
playbooks/cli/*.sh
- severity counts from each rule's
SEVERITY value
- Rewrite the statistics in
docs/learn/index.html and README.md
- Commit and push only when something actually changed, tagged
[skip ci] so the workflow
cannot retrigger itself
The update script must be idempotent: running it on an already-current page produces no diff.
Alternatives considered
- Keep updating the page by hand. Rejected — this issue exists precisely because that
failed. The numbers went stale within a few release cycles.
- A CI check that fails the build when the numbers are stale, rather than auto-committing.
Lower blast radius and no bot commits on dev, but it pushes the chore onto every
contributor whose PR happens to change a count. Worth revisiting if the auto-commit
approach turns out to conflict with branch protection on dev.
- Render the statistics client-side from a generated JSON file. Cleaner separation, but
the Learn page is deliberately a single static HTML file with no build step, and adding one
is out of proportion to the problem.
Additional context
What problem does this solve?
docs/learn/index.htmlhardcodes repository statistics that were correct when the page waswritten and have drifted since. The page currently advertises:
README.mdcarries the same drift in four more places: the Misconfiguration Scanner andRemediation Playbooks rows of the feature table, and both the
Scanner EngineandAzure CLI Playbooksnodes of the Mermaid architecture diagram (all reading 51).Two problems follow from this:
see roughly half the coverage OpenShield actually ships.
devmakes the numbers morewrong, and nothing in CI notices. Manual correction is not sustainable at the rate rules
are being added.
Describe the solution
Two parts:
1. Correct the current numbers in
docs/learn/index.html— the headline counts, thepipeline step, the section title, the intro paragraph, the hero terminal, the severity card
and the category chart all repeat the same figures and must be updated together.
README.mdneeds the same treatment for its four stale counts.
2. Add a GitHub Actions workflow that keeps them correct. On every push to
dev:scanner/rules/(files that declare aRULE_ID)playbooks/cli/*.shSEVERITYvaluedocs/learn/index.htmlandREADME.md[skip ci]so the workflowcannot retrigger itself
The update script must be idempotent: running it on an already-current page produces no diff.
Alternatives considered
failed. The numbers went stale within a few release cycles.
Lower blast radius and no bot commits on
dev, but it pushes the chore onto everycontributor whose PR happens to change a count. Worth revisiting if the auto-commit
approach turns out to conflict with branch protection on
dev.the Learn page is deliberately a single static HTML file with no build step, and adding one
is out of proportion to the problem.
Additional context
docs/learn/index.html,README.md.github/workflows/update-learn-page.yml,.github/scripts/update_learn_page.py