chore(skills): add release-widget skill - #2370
Conversation
This comment has been minimized.
This comment has been minimized.
fbe06a0 to
7773a8b
Compare
This comment has been minimized.
This comment has been minimized.
74a8e99 to
cce0a0d
Compare
This comment has been minimized.
This comment has been minimized.
| - **Running `rui-package-info` / `rui-bump-version` without `cd`-ing into the widget/module dir first** — they read `process.cwd()`, not a path argument. | ||
| - **Treating `appNumber` presence via grep instead of reading the schema** — a module-wrapped widget's package.json simply omits the `marketplace.appNumber` key; check for `null`/undefined/`-1` via `rui-package-info`, don't grep for the string `"appNumber"` (unreliable — the field can exist with value `-1` too, which also means "not independently published"). | ||
| - **Publishing before the asset gate passes** — this is the exact mistake pattern that caused the 409 double-trigger risk. Never call `gh release edit --draft=false` without first confirming both MPK and READMEOSS assets are attached. | ||
| - **Escalating a 409 without checking run history first** — many past "failures" are actually the second of two triggers for an already-successful publish. Always check `gh run list` history for the tag before treating a 409 as a real incident. |
There was a problem hiding this comment.
many past "failures" are actually the second of two triggers for an already-successful publish
How would this happen?
|
|
||
| Find the run matching this tag/branch. | ||
|
|
||
| - `conclusion: success` → the workflow succeeded, but that only means the API call didn't error — it's not proof the version is live. There's no packaged helper to query the Marketplace programmatically (`createDraft`/`publishDraft` are write-only, no idempotency or read-back check), so confirm manually: ask the user to open Marketplace → package page → Manage Versions, and check `<version>` is listed. Don't declare the release done until they confirm. |
There was a problem hiding this comment.
There is marketplace-mcp that we can use for this.
This comment has been minimized.
This comment has been minimized.
|
|
||
| ```bash | ||
| cd $RELEASE_PATH | ||
| pnpm exec rui-bump-version <version> |
There was a problem hiding this comment.
Maybe we can use global pnpm exec rui-bump-version <npm-package-name> <version>. And this script should check if the package is releasable by its own, and should give an error if not. Bump should be from the containing package.
Possibly extracting changelogs can use the same principle, by package name. This gives less room for error. maybe the same guard for usage on releasable packages only
| await bumpXml(path, version); | ||
| } catch { | ||
| xmlBumped = false; // modules have no package.xml | ||
| if (info.mxpackage.type === "module") { |
There was a problem hiding this comment.
Charts widgets is a widget but still has dependencies.
Automates widget/module release pipeline: version bump, GitHub draft release, OSS clearance SBOM, Marketplace publish. Sharing for team feedback before promoting out of private trial.
50fbf1e to
1ac50b0
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| hasUnreleasedLogs(): boolean { | ||
| return this.changelog.content[0].sections.length !== 0; | ||
| const [unreleased] = this.changelog.content; | ||
| // Module changelogs usually carry their entries under subcomponents | ||
| // (per wrapped widget), with no module level sections at all. | ||
| return unreleased.sections.length !== 0 || unreleased.subcomponents.length !== 0; | ||
| } |
There was a problem hiding this comment.
This never happens, subcomponents entries added during release. So it is never a case where there is an unreleased section with subcomponents.
| const dependencyPath = await resolvePackagePath(dependencyName); | ||
|
|
||
| await bumpPackage(dependencyPath, version); | ||
| bumpedPackages.push(shortName(dependencyName)); |
There was a problem hiding this comment.
Why do we strip @mendix here? If we get package name with @mendix, we should also return back the same format.
| } | ||
|
|
||
| function resolveVersion(bumpType: string, previousVersion: string): string { | ||
| const version = getNewVersion(bumpType, previousVersion); |
There was a problem hiding this comment.
Looks like getNewVersion already does what Version class is capable of. We should use Version math instead of using manual math done in getNewVersion.
|
|
||
| `appName` is the Marketplace display name (e.g. `Maps`). The draft release is titled `<appName> v<version>`, which is what the OSS helpers match SBOM/READMEOSS filenames against — they derive it from the tag themselves. | ||
|
|
||
| - `appNumber` is a positive number → **standalone release** (a widget, or a module published directly). Keep this `info`, Phase 2 and 3 reuse it — no re-fetching. |
There was a problem hiding this comment.
appNumber is not used in Phase 2 as far as I can tell.
| - `appNumber` is a positive number → **standalone release** (a widget, or a module published directly). Keep this `info`, Phase 2 and 3 reuse it — no re-fetching. | ||
| - `appNumber` is `null`/absent/`-1` → widget is module-wrapped, not published on its own. Find the owning module: | ||
| ```bash | ||
| grep -l "\"@mendix/<widget>\"" packages/modules/*/package.json |
There was a problem hiding this comment.
Will fail for charts widget, this doesn't live in modules folder.
|
|
||
| ```bash | ||
| echo "== SBOM jar =="; ls "${SBOM_GENERATOR_JAR:-$HOME/SBOM_Generator.jar}" 2>&1 | ||
| echo "== rui helpers =="; pnpm exec which rui-package-info 2>&1 | tail -1 |
There was a problem hiding this comment.
Why do we need to check for that?
|
|
||
| If the SBOM jar is missing, say what's missing and how to fix it (where to get `SBOM_Generator.jar`, or point `SBOM_GENERATOR_JAR` at it) — don't proceed past a missing prereq. | ||
|
|
||
| If a helper doesn't resolve (`Command "rui-package-info" not found`), the bins aren't linked yet — `pnpm install` at the repo root, then re-check. Don't work around it by calling `ts-node bin/<helper>.ts` all run. |
There was a problem hiding this comment.
This is a misconfigured local setup, no need to check for it.
| It refuses to run and exits non-zero when: | ||
|
|
||
| - `<npm-package-name>` isn't independently releasable (no positive `marketplace.appNumber`) — Phase 0 pointed at the wrong package, go back and recheck. | ||
| - the argument is neither a bump type nor an `x.y.z` version. |
There was a problem hiding this comment.
We should not make it possible to pass bump type, only version in the first place.
Summary
Test plan