Closed
Description
In #2464 I had re-activated prettier after it had been disabled in #2307.
I don't know if the dry-run option was really relevant. But it disabled the automation and didn't surface the errors. I don't think that was what we wanted.
I'm not sure if the dry-run option was necessary. It looks to me that the failure should be caught by handle-commit-failure anyway?
If it was, then we could change the action to run prettier on commits to main (instead of on PRs).
Alternatively, we could give up on automated formatting and just use dry-run, but surfacing errors (which authors then need to fix).
Or there are other ideas.
Metadata
Metadata
Assignees
Type
Projects
Status
Activity
pkra commentedon Mar 17, 2025
In light of https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised (though we luckily don't use tj-actions/changed) perhaps we should reconsider using a third party action.
pkra commentedon Mar 25, 2025
Aside: I keep seeing "random" small changes like 39412c3 in #2489
I don't know if prettier is at fault or if CI may run different versions.
In any case, it might be worth figuring out a solution that only runs prettier on files with changes.
pkra commentedon Mar 26, 2025
Discussed at editors' meeting today https://www.w3.org/2025/03/26-aria-editors-minutes.html#475b
pkra commentedon Mar 26, 2025
We want to explore formatting after merge. While there is a chance of introducing merge conflicts, it seems fairly unlikely that formatting will add unexpected merge conflicts - the expectation is that formatting only affects lines that were changed.
@daniel-montalvo I realized it would cause unnecessary respec builds from main. How much of a concern is that?
daniel-montalvo commentedon May 21, 2025
Partially addressed in #2536
Still pending is how to handle forks more properly. We are now just throwing an error, which is not very helpful.
6 remaining items