feat(release): publish a GitHub release, and verify what a chart pins

[Mtze]

Stacked on #43 (which puts both charts at 2.3.0). GitHub retargets this to main when #43 merges.

Three gaps this closes

The release published without checking the images exist. A chart version is a promise about images - appVersion pins every IDE image, versions.cloud the operator and service, versions.landingPage the landing page. Nothing verified that promise, so a chart could go out naming tags nobody pushed, surfacing as ImagePullBackOff in whichever environment installed it next. release.yml now verifies every pinned image exists and is multi-arch before pushing anything, reading the IDE image list from EduIDE's build matrix at run time rather than from a copy kept here.

That check is not hypothetical: today's EduIDE v1.3.0 release build was still running when the chart bump was opened, and the only thing standing between that and a broken production deploy was remembering to look.

Nothing recorded what is current. The release train pushed a bare git tag for this repository and created proper GitHub releases only in the component repos. So answering "which chart version is current, and what does it pin?" meant reading a tag list or the registry. There is now a GitHub release per published chart version:

Charts published to `oci://ghcr.io/eduide/charts`:

- `eduide-cluster` 2.3.0
- `eduide` 2.3.0

## What this chart version pins

| Component | Version |
|---|---|
| IDE images (EduIDE) | 1.3.0 |
| Operator and service (EduIDE-Cloud) | 1.2.0 |
| Landing page | 1.2.2 |

Every image above was verified to exist and be multi-arch before the charts were pushed.

## Deploying it
...

followed by --generate-notes' commit and contributor list.

Nothing enforced the two charts being at one version. AGENTS.md says they are released together at the same version; they had drifted to 2.2.1 and 2.2.2 across a pair of unrelated fixes. One tag and one release cannot name two versions, so CI now checks it.

The release train

Left working, with its header and its failure message rewritten to say what it is: a lockstep release that moves all four repositories to one number, and not the ordinary path. Running it against a normal main fails its pre-check by design, which previously read like a bug.

This settles #44 in favour of per-repo versions.

The skill

.claude/skills/cut-a-release.md described the lockstep model as the only model, which is why it no longer matched anything anyone does. Rewritten around the real process - component release, chart release, deployment PR - with the ordering, the versions.ide override and when it must be removed, and a failure table.

Verification

actionlint clean on all three workflows. The lockstep check run by hand against main correctly reports 2.2.1 / 2.2.2, and against this branch 2.3.0 / 2.3.0.

The publish and release steps only run on push to main, so CI here exercises everything except the release path itself. Worth watching the first run after merge.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 745bf782-972d-49a3-ba31-a2e50c538fc2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Rendered diff across all environments

No change to any rendered manifest.

For a pure refactor this is the result you want.