What
- Deleted
.github/workflows/release.yml.
release-components.yml now also triggers on changes to itself (.github/workflows/release-components.yml in its paths).
Why
release.yml only existed because npm trusted publishing for @swr-data-lab/components was bound to that filename (see its TODO). With the publisher moved to release-components.yml, the old workflow would have failed on every components/** push. The self-trigger makes workflow edits run on merge.
Known trade-off
The merge ran release components, which published @swr-data-lab/components@4.0.1 (tag components-v4.0.1) with no changes to components: https://github.com/SWRdata/components/actions/runs/36775958165
semantic-release counted the fix(components-map): … commit from #554 toward components, because it analyzes every commit since the last tag regardless of path. Fixed going forward in #561.
What
.github/workflows/release.yml.release-components.ymlnow also triggers on changes to itself (.github/workflows/release-components.ymlin itspaths).Why
release.ymlonly existed because npm trusted publishing for@swr-data-lab/componentswas bound to that filename (see its TODO). With the publisher moved torelease-components.yml, the old workflow would have failed on everycomponents/**push. The self-trigger makes workflow edits run on merge.Known trade-off
The merge ran
release components, which published@swr-data-lab/components@4.0.1(tagcomponents-v4.0.1) with no changes tocomponents: https://github.com/SWRdata/components/actions/runs/36775958165semantic-release counted the
fix(components-map): …commit from #554 towardcomponents, because it analyzes every commit since the last tag regardless of path. Fixed going forward in #561.