Any notes at all are considered breaking
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 38/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- javascript
- 領域
- release
調査の方向性
lib/analyze-commit.js のリンクされた条件から始め、次に conventional-changelog-angular の writer-opts.js で notes がどのように生成されるかを比較します。通常の notes とネストされた feat の例を含む squash 済みコミットについて release analysis を再現します。通常の notes では breaking release が発生しなくなり、実際に breaking な notes では引き続き発生すれば完了です。
索引モデルが issue の本文から書いたものです。
説明
We maintain a custom conventional changelog link that we would like to use with semantic-release, but any time we've tried this, any time we merge a PR it's treated as a breaking change because of this line right here:
(!breaking || (commit.notes && commit.notes.length > 0)) &&
It treats any commit note at all as a breaking change. I'm pretty sure this is because the angular conventional discards all notes unless they are a breaking change https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog-angular/writer-opts.js#L31-L34 (I checked a few other conventional changelogs and did not see them using the notes field at all).
This breaks our conventional changelog because we maintain detailed notes for each of the commits inside of a squashed commit. We use this in other places to analyze the squashed commits to determine what the correct release type is. For example, if a commit looks like this:
fix: Something small
* feat: Add a feat
Then the correct release for that squashed commit would be a feat. Semantic release has this concept itself when multiple commits are released at once, we do the same thing just at a PR level.
That problematic line above means that any PR that is squashed is treated as a breaking change though, which means we end up having to maintain a separate set of release rules which defeats the whole purpose of creating a conventional-changelog for our org.
IMO that line should be changed to scan for BREAKING CHANGE in the notes instead of default treating the presence of a note s a breaking change.
- 主要言語
- JavaScript
- スター
- 447
- フォーク
- 82
- 平均マージ
- 7時間 53分
- マージ済み PR（30日）
- 9
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
semantic-release/commit-analyzer のほかの issue
-
released on @beta
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
semantic-release/commit-analyzer#921 · コメント 8 件 · リアクション 7 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 42/100
semantic-release/commit-analyzer#805 · コメント 6 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
semantic-release/commit-analyzer#802 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Unexpected major release because commit description includes a line starting with "Breaking change"オープン
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
semantic-release/commit-analyzer#776 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Exclamation mark (!) after type/scope completely ignores commit対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンreleased on @beta
難易度 3/5 1〜2日 初心者へのやさしさ 55/100
semantic-release/commit-analyzer#759 · コメント 13 件 · リアクション 6 件 ·
メンテナーはふだん 1 日以内に返信
semantic-release/commit-analyzer の issue をすべて見る
似ている issue
-
[scanner] check:spelling skips blog/ — posts and author metadata are never spell-checked対応中かも @hivecommons-hive が今日担当しました。 オープンagent/scanner bug hive/covered-by-pr hive/hosted-available-lke648397-260827-5n31
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
cncf/endusers#1452 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Edit: HTVKey.vnオープンchannels:edit check:passed
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
メンテナーはふだん 6 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
-
beginner bug
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
hiero-ledger/hiero-sdk-js#4517 ·
メンテナーはふだん 1 日以内に返信
-
`timer` rule rejects dates the engine accepts対応中かも @MFA-G が今日担当しました。 オープンbug ready
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
camunda/bpmnlint-plugin-camunda-compat#281 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信