danielbate
commented
3 months ago @nedsalk any ideas on the validate changeset workflow? I've just reverted the revert commit, and introduced another changeset for my work.
Closed danielbate closed 3 months ago
danielbate
commented
3 months ago @nedsalk any ideas on the validate changeset workflow? I've just reverted the revert commit, and introduced another changeset for my work.
maschad
commented
3 months ago @nedsalk any ideas on the validate changeset workflow? I've just reverted the revert commit, and introduced another changeset for my work.
If the primary purpose of us using the changesets is to generate the changelogs for our releases , I think you can just consolidate this changeset as well as this changeset, into one changeset.
Then undo the deletion of this changeset
[!NOTE] Historically changesets have served a different purpose to describe the exact differences between two successive versions of a change such as the git commit message, but based on our release workflow I don't think this applies.
nedsalk
commented
3 months ago @danielbate I suggest you rename your PR to be the same as #2378 and remove all the changesets except that PR's because this PR is reintroducing the same work as #2378. I'm suggesting this because #2378 won't show up in the changelog because it was reverted so there won't be any chore: add browser testing infrastructure entry in the changelog unless you do it with this PR.
danielbate
commented
3 months ago Good points both 👍🏻 @nedsalk @maschad
github-actions[bot]
commented
3 months ago Coverage Report:
| Lines | Branches | Functions | Statements |
|---|---|---|---|
| 79.54%(-0.75%) | 71.37%(-0.43%) | 76.91%(-0.65%) | 79.62%(-0.75%) |
The majority of this work was introduced by @nedsalk in #2378, this PR will also resolve the flaky coverage import that is described in #2612. Investigation seems to point to flaky ESM bundling being the cause, which I believe to have been resolved here.