mtg: validate Release notes in frontend CI
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 67/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- node.js, typescript
- Domain
- ci-cd, internationalization, testing
Research direction
Start by reading the existing scan:* scripts, the release-notes module, and the frontend CI script invoked by pnpm run ci. Add validation through the module's public functions and cover each error case, including reporting all errors at once, with vitest. Done means the Node entry point reports each offending file, exits non-zero for invalid fragments, and pnpm run ci passes for valid release notes.
Written by the indexing model from the issue text.
Description
Parent
#175
What to build
A developer who commits a broken Release note gets a failing frontend CI instead of a broken "What's new" page.
The Release notes module validates raw fragments (path + content) and reports every error at once, not just the first: an unknown kind, a missing or empty de or en, malformed YAML, and a released version folder without release.yaml. A small Node entry point, bundled with esbuild like the existing scan:* scripts, runs this validation over the release-notes directory and exits non-zero with all errors listed. The frontend CI script runs it. The release command (separate ticket) will reuse the same entry point.
Acceptance criteria
- Validation reports an unknown kind, a missing or empty
de/en, malformed YAML and a release folder withoutrelease.yaml - All errors are reported in one run, each naming the offending file
- A Node entry point validates the release-notes directory and exits non-zero on any error
-
pnpm run ciruns it and fails on an invalid fragment, passes on valid ones - vitest tests, through the module's public functions, cover each error case and the "all errors at once" behaviour
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 1
- Avg merge
- 11h 20m
- Merged PRs (30d)
- 31
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
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 myOmikron/code
-
ready-for-agent
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
wayfinder:task
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
wayfinder:task
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
myOmikron/code#102 · 2 comments ·
Maintainers usually reply within 1 day
-
ready-for-agent
Difficulty 4/5 3-5 days Newbie friendliness 52/100
Maintainers usually reply within 1 day
-
ready-for-agent
Difficulty 3/5 1-2 days Newbie friendliness 66/100
Maintainers usually reply within 1 day
Similar issues
-
frontend
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
ranxianglei/billion-context#4172 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
awslabs/threat-composer#362 ·
Maintainers usually reply within 1 day
-
Area/Cloud Needs Triage Type/Bug
Difficulty 1/5 1-3 hours Newbie friendliness 86/100
wso2/product-integrator#2847 ·
Maintainers usually reply within 1 day