ci: release on every push to main through changesets/action - #34
Merged
Conversation
Until now release.yml only ran when someone pushed a `dds-v*` tag by hand. Nothing created that tag: two release commits (0.4.0 in #31, 0.4.1 in #33) sat on main while npm stayed at 0.3.0, and the landing that was waiting on site-kit 0.4.1 shipped behind a `<select>` instead of the flag picker. The workflow now runs on every push to main, passes the same verification gate as before, and hands off to changesets/action: with changeset files waiting it opens the "chore: release dds" version PR; with none waiting (the version PR just merged) it runs `changeset publish`, which publishes whatever is on main but not yet on npm and tags each package. Re-runs are safe because versions already on npm are skipped. Provenance and the NPM_TOKEN secret are unchanged. The README pair describes the flow.
verify:solid:release and verify:site-kit:release end with `npm publish --dry-run`, and npm refuses a dry-run of a version that is already published. That made CI on main red from the moment a release went out until the next version bump — exactly the state the new release workflow runs in on every push. The pack, the manifest and the fresh-consumer install are what these gates check; an "already published" answer from the registry is now logged and counted as passed, and every other dry-run failure still throws. verify:release never hit this because it runs npm offline.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
release.ymlwas triggered only by a hand-pusheddds-v*tag, and nothing created that tag — 0.4.0 (#31) and 0.4.1 (#33) sat onmainunpublished until the tag was pushed by hand today. This makes the release automatic, the way linq-kit does it: every push tomainruns the full verification gate, thenchangesets/actioneither opens the "chore: release dds" version PR (changesets waiting) or runschangeset publish(version PR just merged) — publishing only versions not yet on npm, so re-runs are safe. Provenance +NPM_TOKENunchanged; README pair updated.Owner check:
changesets/actionopens PRs withGITHUB_TOKEN, which needs Settings → Actions → General → "Allow GitHub Actions to create and approve pull requests" enabled (the API reports it is).요약
release.yml이 손으로 푸시한dds-v*태그에만 반응했고 그 태그를 만드는 곳이 없어서 0.4.0(#31)·0.4.1(#33)이 오늘 수동 태그 전까지main에만 있고 npm엔 없었다. linq-kit과 같은 방식으로 자동화:main푸시마다 전체 검증 게이트 →changesets/action이 changeset이 있으면 "chore: release dds" 버전 PR을 열고, 없으면(버전 PR 머지 직후)changeset publish로 npm에 없는 버전만 배포. provenance·NPM_TOKEN그대로, README 짝 갱신.오너 확인: Actions 설정의 "Allow GitHub Actions to create and approve pull requests"가 켜져 있어야 버전 PR이 열린다(API로는 켜져 있음).
Verification
Workflow-only change. Local
pnpm run verifyon Windows stops atsite-kit check→build-flags --checkbecausecore.autocrlf=truerewrites the flag SVGs with CRLF before the generator embeds them (unrelated to this change; CI on Linux is the gate for it).tscclean.Follow-up in the same PR
CI on this PR failed at
verify:solid:releasewith npm's "You cannot publish over the previously published versions: 0.4.1" — the release verifiers'npm publish --dry-runcannot run once a version is on npm, which makesmainred after every release until the next bump (and would fail the new release gate on every push). The two verifiers now treat that specific registry answer as passed (everything else still throws); verified locally on 0.4.1 — both print "already on npm; publish dry-run skipped" and pass.같은 PR의 후속
이 PR의 CI가
verify:solid:release에서 npm의 "이미 배포된 0.4.1 위에 배포할 수 없다"로 실패 — 릴리스 검증기의npm publish --dry-run은 버전이 npm에 올라간 뒤엔 돌 수 없어서, 릴리스 직후부터 다음 버전 범프까지main이 빨갛고 새 릴리스 게이트도 매 푸시마다 실패하게 된다. 두 검증기가 그 응답만 통과로 처리하도록 수정(다른 실패는 그대로 throw); 0.4.1로 로컬 실측 — 둘 다 "already on npm; publish dry-run skipped" 후 통과.