Trunk

We're making it easier for you to triage test results in your PRs. Here's a sneak peak 👀

Maintaining code quality in open-source repos is more challenging because of the diverse backgrounds of contributors and the lack of formal processes. This lack of shared understanding is frustrating for the contributors and maintainers alike. Code Quality helps you codify the unwritten norms and rules into a single tool and config, so you can lint and enforce standards for every file in your repo.

"Flaky tests are poison 🧪. You can have the best tests in the world, the most sophisticated testing that finds the craziest bugs no one would think of, but if developers can’t trust the results 99% of the time, it doesn’t matter." - Roy Williams from Meta Flaky tests ruin your team's trust in tests, we can help. Join our waitlist today, link in the comments👇

Context switching for knowledge workers like software engineers was shown to cost 23 minutes and 15 seconds of productivity per context switch. How much does debugging flaky tests cost for your team? Find out here: https://lnkd.in/eJTnDinK

Thanks to everyone at Monorepo World for coming to David's talk about building scalable and fast merge queues! If you're curious about merge queues and how they can scale to handle hundreds of PRs, catch it here: https://lnkd.in/ey5A59XP

David is live @MonorepoWorld right now talking about all things merge queue. Tune in online: https://lnkd.in/ey5A59XP

Came across a post on dealing with flaky tests with Playwright. It's got some interesting takes that are worth discussing. TL;DR: The author, Andrey Enin, suggests strategic use of timeouts to combat flakiness in UI tests. Key points: ⦾  Even with Playwright's auto-waiting, some UI elements (animations, canvas, etc.) can still cause issues. Sometimes a tiny pause (like 300ms) before interacting with these elements can work wonders. ⦾  JS Application behavior that is timing-dependent (like setTimeout) will be different in different environments - especially in CI where a machine is under different load than when running in a user's browser. ⦾  There's a pragmatic point worth noting: adding a single wait in one test is often simpler and more robust than developing a highly complicated (and potentially fragile) solution for determining a single element's state. As the Andrey puts it, "Here, a few seconds in one test is sacrificed in favor of relative reliability." There's also good stuff on explicit waits and retry strategies. What do you all think? How do you track and manage flaky tests in your projects? Link to the blog post is in the comments. Seems LinkedIn prefers posts without links.

Trunk Merge Queue prevents incompatible changes from breaking your main branch without sacrificing velocity, even for the busiest repos. Learn to merge your first pull request 👇 https://lnkd.in/gritcCcF

👉 New in Code Quality Plugins 1.6.3 🦉 squawk - A linter for your Postgres migrations. Use squawk to prevent unexpected downtime caused by database migrations and encourage best practices around Postgres schemas and SQL. See the full changelog: https://lnkd.in/exPikgpD

👉 Trunk 1.22.6 is released 🔧 Fixes - Fix a rare deadlock that could cause a linter execution to hang indefinitely. Changelog: https://lnkd.in/e9T-eBeC