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.
jlc488
added a commit
that referenced
this pull request
Sep 5, 2026
* feat(site-kit): 제품이 가족 밖 언어를 가질 수 있게 (D-018, D-019)
`LOCALES`는 devslab.kr이 마케팅하는 언어 목록이지 모든 제품의 목록이
아니다. BookLinq는 인도 살롱에 팔고, 그 어시스턴트는 이미 타밀·텔루구·
벵골·마라티·구자라티·칸나다로 답한다. 그 6개를 가족 목록에 넣으면
AskLinq와 devslab.kr의 피커에 번역 없는 항목 6개가 생기고, 안 넣으면
BookLinq 웹이 제품이 하는 일에 대해 거짓말을 한다.
그래서 가족이 메커니즘을 갖고 제품이 자기 명사를 댄다.
`defineLocaleRegistry({ extra })`가 가족 14개 + 제품 언어로 레지스트리를
만들고, 로케일을 다루는 헬퍼가 전부 그것을 받는다 — validateCatalogs ·
buildMetadata · buildSitemap · localizedPath · localizedUrl · LocaleMenu ·
SiteHeader. 안 넘기면 가족 레지스트리라 기존 소비자는 무변경이다.
추가 로케일은 국기 아트워크를 싣지 않는다. `flagCountry`로 이 패키지가
이미 벤더링한 나라를 지목하고, 새 `FLAGS_BY_COUNTRY`가 나라로 색인한다.
국기는 나라를 가리키지 언어를 가리키지 않으므로 인도 로케일 7개가
정당하게 `in` 하나를 공유한다. 국기 데이터는 라이선스가 있고 생성되며
여기서 스캔되므로 제품 레포로 복제될 자리가 아니다.
## 같이 고친 버그 둘
**select 변형이 SSR에서 아무 옵션도 선택하지 않았다.** `<select>`에
`value`를 걸었는데 그건 DOM 프로퍼티일 뿐 대응하는 콘텐츠 속성이 없다.
서버가 문자열을 내보내면 브라우저는 그 속성을 무시하고 `option[0]`을
고른다 — **모든 방문자가 모든 언어에서 첫 로케일을 자기 현재 언어로
봤고**, 컨트롤을 건드리면 거기로 바뀌었다. BookLinq 배포 워커에서
발견했고 유닛·SSR 테스트는 전부 초록이었다. 이제 `<option selected>`.
**`localeAttributes`가 방향을 아랍어인지로 판정했다.**
`canonical === "ar" ? "rtl" : "ltr"`는 아랍어가 가족의 유일한 RTL 언어인
동안에만 참이었다. 우르두어나 히브리어를 추가한 제품은 모든 테스트가
초록인 채로 좌횡서로 렌더됐을 것이다. 방향은 이제 정의에서 읽는다.
## 검증
i18n 14 · solid 15 · SSR 4 · contracts 9 전부 통과, `pnpm run check`
초록(토큰·CSS·아이콘·문서 동기화·소비자 사본). SSR 회귀 테스트가
마크업에 직접 어설션한다 — `selected` 정확히 하나, `<select>`에
`value` 없음.
문서: 결정로그 D-018·D-019, README 양어 짝.
* fix(site-kit): 국기 생성기가 체크아웃의 줄바꿈에 휘둘리지 않게
앞 커밋이 CI를 빨갛게 만들었다: `flags out of date` — Linux에서만.
원인은 생성기가 **읽는 것**이 플랫폼마다 달랐던 것이다. `core.autocrlf`가
켜진 Windows 체크아웃은 `flags/*.svg`를 CRLF로 돌려주고, `JSON.stringify`가
그 CR을 `\r\n` 이스케이프로 성실히 보존한다. 그래서 내가 Windows에서
재생성한 flags.mjs에는 `\r\n` 이스케이프가 715개 들어갔고(HEAD~1은 0개),
Linux CI가 LF로 읽어 만든 것과 달라졌다. `--check`가 정확히 이걸 잡는
가드인데, 내 로컬에서는 방금 내가 만든 CRLF 버전과 비교하니 통과했다.
부수 피해도 있었다. 그 이스케이프는 그냥 커밋 노이즈가 아니라 **브라우저로
나가는 SVG 본문 안의 실제 캐리지 리턴**이었다 — 발행 데이터가 2.8KB 늘었다
(113,712 → 112,282바이트로 회복).
두 군데를 고친다. 생성기가 읽은 텍스트의 줄바꿈을 정규화하고(생성기는
읽는 것이 바이트 안정적일 때만 재현 가능하다), `.gitattributes`가 이 레포의
텍스트를 모든 플랫폼에서 LF로 고정한다.
검증: 이번엔 CI가 실제로 돌리는 게이트를 그대로 돌렸다 —
verify:source:stage1-2 · stage3-4 · site-kit:i18n · site-kit:ui ·
site-kit:seo · `pnpm run verify` 전부 exit 0. 재생성된 flag body가
HEAD~1(Linux 생성본)과 일치하는 것도 확인했다.
* fix(release): 버전 PR이 읽을 CHANGELOG를 실제로 생성한다
#34가 릴리스 트리거를 태그에서 main push로 바꾼 뒤 처음으로
"미소비 changeset 있음 → 버전 PR 생성" 경로가 실행됐고, 거기서 죽었다:
ENOENT: open 'packages/dds-css/CHANGELOG.md'
`.changeset/config.json`이 `"changelog": false`라 `changeset version`은
CHANGELOG를 쓰지 않는데, changesets/action은 PR 본문을 만들려고 bump된
패키지마다 그 파일을 읽는다. 0.4.0·0.4.1 릴리스 PR은 #34 이전에 손으로
만들어졌고 0.4.1 발행 run은 "미소비 changeset 없음 → publish" 경로였기
때문에 이 조합이 한 번도 돌아본 적이 없었다.
기본 생성기(`@changesets/cli/changelog`, cli에 동봉 — 새 의존성 없음)를
켠다. 로컬 드라이런: `changeset version`이 fixed 그룹 5개를 0.5.0으로
올리고 패키지마다 CHANGELOG.md를 만들며, site-kit 항목이 D-018/D-019
changeset 본문을 그대로 싣는 것을 확인한 뒤 트리를 되돌렸다.
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" 후 통과.