fix: Fix toolbox categories tests

[RoboErikG]

This fixes the the toolbox categories tests except for dragging out the four empty statement blocks, which is fixed by RaspberryPiFoundation/blockly-samples#2580

Tests will continue to fail until the latest version of samples is published.

The basics

• I validated my changes

The details

Resolves

Fixes#8953 and half of #9217

Proposed Changes

Fixes and re-enables the toolbox categories test.

Reason for Changes

Tests were broken.

Test Coverage

Documentation

Additional Information

[cpcallen]

N.B. that:

• this PR was merged rather than squashed, and
• the merge commit (7e47bf4) did not follow the conventional commits convention, and
• one of the constituent commits (55bd1af) also did not follow the conventional commits convention.

This may result in some problems with the automatically-generated release notes next time we release.

Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we do make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made.

But AIUI Ci is supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb: do we no longer check constituent commits?

[maribethb]

This won’t affect release notes and won’t have any negative impact. For core, release notes are generated based on the labels that are added to PRs by the conventional label action. This PR was labeled correctly because the labels are based on the PR title. We select the version number for a release manually in core so this also does not impact that process. I believe the lint action only checks the PR title unless there is only one commit. If there is one commit it will check that that commit does follow conventional commits. In samples, it’s a little different because the version numbers are determined automatically. But even in that case it’s difficult to break things because if you merge a PR, as long as the constituent commits were titled correctly, the release would be fine. If however everything were labeled as “fix” except the one commit that should be “feat” or breaking change, then the version number could be incorrect if there were no other correctly labeled feat or breaking change commits. TLDR: it’s fine, this does not impact anything.

…

On Wed, Jul 16, 2025 at 8:30 AM Christopher Allen ***@***.***> wrote: *cpcallen* left a comment (RaspberryPiFoundation/blockly#9238) <#9238 (comment)> N.B. that: - this PR was merged rather than squashed, and - the merge commit (7e47bf4 <7e47bf4>) did not follow the conventional commits convention, and - one of the constituent commits (55bd1af <55bd1af>) also did not follow the conventional commits convention. This may result in some problems with the automatically-generated release notes next time we release. Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we *do* make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made. But AIUI Ci *is* supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb <https://github.com/maribethb>: do we no longer check constituent commits? — Reply to this email directly, view it on GitHub <#9238 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBNIBS6XQDPB6EAJAHLG5D3IZAWRAVCNFSM6AAAAACBPUNZECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZYGM3DCNRTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[RoboErikG]

This fixes the the toolbox categories tests except for dragging out the four empty statement blocks, which is fixed by RaspberryPiFoundation/blockly-samples#2580

Tests will continue to fail until the latest version of samples is published.

The basics

• I validated my changes

The details

Resolves

Fixes#8953 and half of #9217

Proposed Changes

Fixes and re-enables the toolbox categories test.

Reason for Changes

Tests were broken.

Test Coverage

Documentation

Additional Information

[cpcallen]

N.B. that:

• this PR was merged rather than squashed, and
• the merge commit (7e47bf4) did not follow the conventional commits convention, and
• one of the constituent commits (55bd1af) also did not follow the conventional commits convention.

This may result in some problems with the automatically-generated release notes next time we release.

Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we do make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made.

But AIUI Ci is supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb: do we no longer check constituent commits?

[maribethb]

This won’t affect release notes and won’t have any negative impact. For core, release notes are generated based on the labels that are added to PRs by the conventional label action. This PR was labeled correctly because the labels are based on the PR title. We select the version number for a release manually in core so this also does not impact that process. I believe the lint action only checks the PR title unless there is only one commit. If there is one commit it will check that that commit does follow conventional commits. In samples, it’s a little different because the version numbers are determined automatically. But even in that case it’s difficult to break things because if you merge a PR, as long as the constituent commits were titled correctly, the release would be fine. If however everything were labeled as “fix” except the one commit that should be “feat” or breaking change, then the version number could be incorrect if there were no other correctly labeled feat or breaking change commits. TLDR: it’s fine, this does not impact anything.

…

On Wed, Jul 16, 2025 at 8:30 AM Christopher Allen ***@***.***> wrote: *cpcallen* left a comment (RaspberryPiFoundation/blockly#9238) <#9238 (comment)> N.B. that: - this PR was merged rather than squashed, and - the merge commit (7e47bf4 <7e47bf4>) did not follow the conventional commits convention, and - one of the constituent commits (55bd1af <55bd1af>) also did not follow the conventional commits convention. This may result in some problems with the automatically-generated release notes next time we release. Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we *do* make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made. But AIUI Ci *is* supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb <https://github.com/maribethb>: do we no longer check constituent commits? — Reply to this email directly, view it on GitHub <#9238 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBNIBS6XQDPB6EAJAHLG5D3IZAWRAVCNFSM6AAAAACBPUNZECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZYGM3DCNRTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[RoboErikG]

This fixes the the toolbox categories tests except for dragging out the four empty statement blocks, which is fixed by RaspberryPiFoundation/blockly-samples#2580

Tests will continue to fail until the latest version of samples is published.

The basics

• I validated my changes

The details

Resolves

Fixes#8953 and half of #9217

Proposed Changes

Fixes and re-enables the toolbox categories test.

Reason for Changes

Tests were broken.

Test Coverage

Documentation

Additional Information

[cpcallen]

N.B. that:

• this PR was merged rather than squashed, and
• the merge commit (7e47bf4) did not follow the conventional commits convention, and
• one of the constituent commits (55bd1af) also did not follow the conventional commits convention.

This may result in some problems with the automatically-generated release notes next time we release.

Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we do make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made.

But AIUI Ci is supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb: do we no longer check constituent commits?

[maribethb]

This won’t affect release notes and won’t have any negative impact. For core, release notes are generated based on the labels that are added to PRs by the conventional label action. This PR was labeled correctly because the labels are based on the PR title. We select the version number for a release manually in core so this also does not impact that process. I believe the lint action only checks the PR title unless there is only one commit. If there is one commit it will check that that commit does follow conventional commits. In samples, it’s a little different because the version numbers are determined automatically. But even in that case it’s difficult to break things because if you merge a PR, as long as the constituent commits were titled correctly, the release would be fine. If however everything were labeled as “fix” except the one commit that should be “feat” or breaking change, then the version number could be incorrect if there were no other correctly labeled feat or breaking change commits. TLDR: it’s fine, this does not impact anything.

…

On Wed, Jul 16, 2025 at 8:30 AM Christopher Allen ***@***.***> wrote: *cpcallen* left a comment (RaspberryPiFoundation/blockly#9238) <#9238 (comment)> N.B. that: - this PR was merged rather than squashed, and - the merge commit (7e47bf4 <7e47bf4>) did not follow the conventional commits convention, and - one of the constituent commits (55bd1af <55bd1af>) also did not follow the conventional commits convention. This may result in some problems with the automatically-generated release notes next time we release. Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we *do* make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made. But AIUI Ci *is* supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb <https://github.com/maribethb>: do we no longer check constituent commits? — Reply to this email directly, view it on GitHub <#9238 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBNIBS6XQDPB6EAJAHLG5D3IZAWRAVCNFSM6AAAAACBPUNZECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZYGM3DCNRTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[RoboErikG]

This fixes the the toolbox categories tests except for dragging out the four empty statement blocks, which is fixed by RaspberryPiFoundation/blockly-samples#2580

Tests will continue to fail until the latest version of samples is published.

The basics

• I validated my changes

The details

Resolves

Fixes#8953 and half of #9217

Proposed Changes

Fixes and re-enables the toolbox categories test.

Reason for Changes

Tests were broken.

Test Coverage

Documentation

Additional Information

[cpcallen]

N.B. that:

• this PR was merged rather than squashed, and
• the merge commit (7e47bf4) did not follow the conventional commits convention, and
• one of the constituent commits (55bd1af) also did not follow the conventional commits convention.

This may result in some problems with the automatically-generated release notes next time we release.

Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we do make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made.

But AIUI Ci is supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb: do we no longer check constituent commits?

[maribethb]

This won’t affect release notes and won’t have any negative impact. For core, release notes are generated based on the labels that are added to PRs by the conventional label action. This PR was labeled correctly because the labels are based on the PR title. We select the version number for a release manually in core so this also does not impact that process. I believe the lint action only checks the PR title unless there is only one commit. If there is one commit it will check that that commit does follow conventional commits. In samples, it’s a little different because the version numbers are determined automatically. But even in that case it’s difficult to break things because if you merge a PR, as long as the constituent commits were titled correctly, the release would be fine. If however everything were labeled as “fix” except the one commit that should be “feat” or breaking change, then the version number could be incorrect if there were no other correctly labeled feat or breaking change commits. TLDR: it’s fine, this does not impact anything.

…

On Wed, Jul 16, 2025 at 8:30 AM Christopher Allen ***@***.***> wrote: *cpcallen* left a comment (RaspberryPiFoundation/blockly#9238) <#9238 (comment)> N.B. that: - this PR was merged rather than squashed, and - the merge commit (7e47bf4 <7e47bf4>) did not follow the conventional commits convention, and - one of the constituent commits (55bd1af <55bd1af>) also did not follow the conventional commits convention. This may result in some problems with the automatically-generated release notes next time we release. Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we *do* make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made. But AIUI Ci *is* supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb <https://github.com/maribethb>: do we no longer check constituent commits? — Reply to this email directly, view it on GitHub <#9238 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBNIBS6XQDPB6EAJAHLG5D3IZAWRAVCNFSM6AAAAACBPUNZECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZYGM3DCNRTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[RoboErikG]

This fixes the the toolbox categories tests except for dragging out the four empty statement blocks, which is fixed by RaspberryPiFoundation/blockly-samples#2580

Tests will continue to fail until the latest version of samples is published.

The basics

• I validated my changes

The details

Resolves

Fixes#8953 and half of #9217

Proposed Changes

Fixes and re-enables the toolbox categories test.

Reason for Changes

Tests were broken.

Test Coverage

Documentation

Additional Information

[cpcallen]

N.B. that:

• this PR was merged rather than squashed, and
• the merge commit (7e47bf4) did not follow the conventional commits convention, and
• one of the constituent commits (55bd1af) also did not follow the conventional commits convention.

This may result in some problems with the automatically-generated release notes next time we release.

Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we do make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made.

But AIUI Ci is supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb: do we no longer check constituent commits?

[maribethb]

This won’t affect release notes and won’t have any negative impact. For core, release notes are generated based on the labels that are added to PRs by the conventional label action. This PR was labeled correctly because the labels are based on the PR title. We select the version number for a release manually in core so this also does not impact that process. I believe the lint action only checks the PR title unless there is only one commit. If there is one commit it will check that that commit does follow conventional commits. In samples, it’s a little different because the version numbers are determined automatically. But even in that case it’s difficult to break things because if you merge a PR, as long as the constituent commits were titled correctly, the release would be fine. If however everything were labeled as “fix” except the one commit that should be “feat” or breaking change, then the version number could be incorrect if there were no other correctly labeled feat or breaking change commits. TLDR: it’s fine, this does not impact anything.

…

On Wed, Jul 16, 2025 at 8:30 AM Christopher Allen ***@***.***> wrote: *cpcallen* left a comment (RaspberryPiFoundation/blockly#9238) <#9238 (comment)> N.B. that: - this PR was merged rather than squashed, and - the merge commit (7e47bf4 <7e47bf4>) did not follow the conventional commits convention, and - one of the constituent commits (55bd1af <55bd1af>) also did not follow the conventional commits convention. This may result in some problems with the automatically-generated release notes next time we release. Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we *do* make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made. But AIUI Ci *is* supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb <https://github.com/maribethb>: do we no longer check constituent commits? — Reply to this email directly, view it on GitHub <#9238 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBNIBS6XQDPB6EAJAHLG5D3IZAWRAVCNFSM6AAAAACBPUNZECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZYGM3DCNRTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[RoboErikG]

This fixes the the toolbox categories tests except for dragging out the four empty statement blocks, which is fixed by RaspberryPiFoundation/blockly-samples#2580

Tests will continue to fail until the latest version of samples is published.

The basics

• I validated my changes

The details

Resolves

Fixes#8953 and half of #9217

Proposed Changes

Fixes and re-enables the toolbox categories test.

Reason for Changes

Tests were broken.

Test Coverage

Documentation

Additional Information

[cpcallen]

N.B. that:

• this PR was merged rather than squashed, and
• the merge commit (7e47bf4) did not follow the conventional commits convention, and
• one of the constituent commits (55bd1af) also did not follow the conventional commits convention.

This may result in some problems with the automatically-generated release notes next time we release.

Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we do make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made.

But AIUI Ci is supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb: do we no longer check constituent commits?

[maribethb]

This won’t affect release notes and won’t have any negative impact. For core, release notes are generated based on the labels that are added to PRs by the conventional label action. This PR was labeled correctly because the labels are based on the PR title. We select the version number for a release manually in core so this also does not impact that process. I believe the lint action only checks the PR title unless there is only one commit. If there is one commit it will check that that commit does follow conventional commits. In samples, it’s a little different because the version numbers are determined automatically. But even in that case it’s difficult to break things because if you merge a PR, as long as the constituent commits were titled correctly, the release would be fine. If however everything were labeled as “fix” except the one commit that should be “feat” or breaking change, then the version number could be incorrect if there were no other correctly labeled feat or breaking change commits. TLDR: it’s fine, this does not impact anything.

…

On Wed, Jul 16, 2025 at 8:30 AM Christopher Allen ***@***.***> wrote: *cpcallen* left a comment (RaspberryPiFoundation/blockly#9238) <#9238 (comment)> N.B. that: - this PR was merged rather than squashed, and - the merge commit (7e47bf4 <7e47bf4>) did not follow the conventional commits convention, and - one of the constituent commits (55bd1af <55bd1af>) also did not follow the conventional commits convention. This may result in some problems with the automatically-generated release notes next time we release. Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we *do* make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made. But AIUI Ci *is* supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb <https://github.com/maribethb>: do we no longer check constituent commits? — Reply to this email directly, view it on GitHub <#9238 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBNIBS6XQDPB6EAJAHLG5D3IZAWRAVCNFSM6AAAAACBPUNZECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZYGM3DCNRTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[RoboErikG]

This fixes the the toolbox categories tests except for dragging out the four empty statement blocks, which is fixed by RaspberryPiFoundation/blockly-samples#2580

Tests will continue to fail until the latest version of samples is published.

The basics

• I validated my changes

The details

Resolves

Fixes#8953 and half of #9217

Proposed Changes

Fixes and re-enables the toolbox categories test.

Reason for Changes

Tests were broken.

Test Coverage

Documentation

Additional Information

[cpcallen]

N.B. that:

• this PR was merged rather than squashed, and
• the merge commit (7e47bf4) did not follow the conventional commits convention, and
• one of the constituent commits (55bd1af) also did not follow the conventional commits convention.

This may result in some problems with the automatically-generated release notes next time we release.

Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we do make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made.

But AIUI Ci is supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb: do we no longer check constituent commits?

[maribethb]

This won’t affect release notes and won’t have any negative impact. For core, release notes are generated based on the labels that are added to PRs by the conventional label action. This PR was labeled correctly because the labels are based on the PR title. We select the version number for a release manually in core so this also does not impact that process. I believe the lint action only checks the PR title unless there is only one commit. If there is one commit it will check that that commit does follow conventional commits. In samples, it’s a little different because the version numbers are determined automatically. But even in that case it’s difficult to break things because if you merge a PR, as long as the constituent commits were titled correctly, the release would be fine. If however everything were labeled as “fix” except the one commit that should be “feat” or breaking change, then the version number could be incorrect if there were no other correctly labeled feat or breaking change commits. TLDR: it’s fine, this does not impact anything.

…

On Wed, Jul 16, 2025 at 8:30 AM Christopher Allen ***@***.***> wrote: *cpcallen* left a comment (RaspberryPiFoundation/blockly#9238) <#9238 (comment)> N.B. that: - this PR was merged rather than squashed, and - the merge commit (7e47bf4 <7e47bf4>) did not follow the conventional commits convention, and - one of the constituent commits (55bd1af <55bd1af>) also did not follow the conventional commits convention. This may result in some problems with the automatically-generated release notes next time we release. Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we *do* make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made. But AIUI Ci *is* supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb <https://github.com/maribethb>: do we no longer check constituent commits? — Reply to this email directly, view it on GitHub <#9238 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBNIBS6XQDPB6EAJAHLG5D3IZAWRAVCNFSM6AAAAACBPUNZECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZYGM3DCNRTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[RoboErikG]

This fixes the the toolbox categories tests except for dragging out the four empty statement blocks, which is fixed by RaspberryPiFoundation/blockly-samples#2580

Tests will continue to fail until the latest version of samples is published.

The basics

• I validated my changes

The details

Resolves

Fixes#8953 and half of #9217

Proposed Changes

Fixes and re-enables the toolbox categories test.

Reason for Changes

Tests were broken.

Test Coverage

Documentation

Additional Information

[cpcallen]

N.B. that:

• this PR was merged rather than squashed, and
• the merge commit (7e47bf4) did not follow the conventional commits convention, and
• one of the constituent commits (55bd1af) also did not follow the conventional commits convention.

This may result in some problems with the automatically-generated release notes next time we release.

Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we do make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made.

But AIUI Ci is supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb: do we no longer check constituent commits?

[maribethb]

This won’t affect release notes and won’t have any negative impact. For core, release notes are generated based on the labels that are added to PRs by the conventional label action. This PR was labeled correctly because the labels are based on the PR title. We select the version number for a release manually in core so this also does not impact that process. I believe the lint action only checks the PR title unless there is only one commit. If there is one commit it will check that that commit does follow conventional commits. In samples, it’s a little different because the version numbers are determined automatically. But even in that case it’s difficult to break things because if you merge a PR, as long as the constituent commits were titled correctly, the release would be fine. If however everything were labeled as “fix” except the one commit that should be “feat” or breaking change, then the version number could be incorrect if there were no other correctly labeled feat or breaking change commits. TLDR: it’s fine, this does not impact anything.

…

On Wed, Jul 16, 2025 at 8:30 AM Christopher Allen ***@***.***> wrote: *cpcallen* left a comment (RaspberryPiFoundation/blockly#9238) <#9238 (comment)> N.B. that: - this PR was merged rather than squashed, and - the merge commit (7e47bf4 <7e47bf4>) did not follow the conventional commits convention, and - one of the constituent commits (55bd1af <55bd1af>) also did not follow the conventional commits convention. This may result in some problems with the automatically-generated release notes next time we release. Making a merge commits instead of squashing is an easy mistake to make (as unfortunately GitHub remembers one's previous choice here, rather than remembering a per-PR selection, and we *do* make some merge commits deliberately during release). It is likewise easy to fail to notice that the merge commit is not conventional, since normally squash commits take the (hopefully conventional) PR title automatically. Unfortunately both of the above mistakes cannot be prevented by CI, since it can't check commit messages (or types) before the commit is made. But AIUI Ci *is* supposed to be checking both PR titles and the commit messages of the constituent commits, and I'm not quite sure why the unconventional commit in the PR branch was not flagged. @maribethb <https://github.com/maribethb>: do we no longer check constituent commits? — Reply to this email directly, view it on GitHub <#9238 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBNIBS6XQDPB6EAJAHLG5D3IZAWRAVCNFSM6AAAAACBPUNZECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZYGM3DCNRTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>