diff --git a/changelog/2026-06-29-browser-extension-0-13-0.mdx b/changelog/2026-06-29-browser-extension-0-13-0.mdx index 3debfadb..ac51204e 100644 --- a/changelog/2026-06-29-browser-extension-0-13-0.mdx +++ b/changelog/2026-06-29-browser-extension-0-13-0.mdx @@ -1,9 +1,9 @@ --- -title: "Browser Extension : Performance and bug fixes" +title: "Browser Extension: Performance and bug fixes" description: "The Trunk browser extension 0.13.0 ships performance improvements and bug fixes." -date: "null" -category: "Browser Extension" -type: "update" +date: 2026-06-29 +category: Browser Extension +type: update --- **Version 0.13.0 of the Trunk browser extension is now available with performance improvements and bug fixes.** diff --git a/docs.json b/docs.json index 641ccd6e..37e3fce6 100644 --- a/docs.json +++ b/docs.json @@ -624,7 +624,7 @@ { "group": "June", "pages": [ - "changelog/2026-06-29-browser-extension-0-13-0.mdx", + "changelog/2026-06-29-browser-extension-0-13-0", "changelog/2026-06-18-merge-queue-stale-tab-refresh-fix", "changelog/2026-06-17-flaky-tests-browser-extension-failure-details", "changelog/2026-06-17-merge-queue-metrics-and-extension-updates", diff --git a/flaky-tests/get-started/ci-providers/github-actions.mdx b/flaky-tests/get-started/ci-providers/github-actions.mdx index 015edba4..9e69bef9 100644 --- a/flaky-tests/get-started/ci-providers/github-actions.mdx +++ b/flaky-tests/get-started/ci-providers/github-actions.mdx @@ -132,7 +132,7 @@ You can quarantine flaky tests by wrapping the test command or as a follow-up st -Using the Trunk Analytics Uploader Action in your GitHub Actions Workflow files, may need modifications to your workflow files to support quarantining. +Using the Trunk Analytics Uploader Action in your GitHub Actions Workflow files may need modifications to your workflow files to support quarantining. If you upload your test results as a second step after you run your tests, **you need to add** `continue-on-error: true` **on your test step so your CI** job will continue even on failures. diff --git a/flaky-tests/management/managing-detected-flaky-tests.mdx b/flaky-tests/management/managing-detected-flaky-tests.mdx index de08af61..4605812f 100644 --- a/flaky-tests/management/managing-detected-flaky-tests.mdx +++ b/flaky-tests/management/managing-detected-flaky-tests.mdx @@ -44,7 +44,7 @@ Creating Linear or Jira tickets for detected flaky tests helps to integrate flak ### Step 3: Broadcast flakes -It is important to keep the team informed on all status changes for flaky tests . This allows for fast follow-up when a test is marked as flaky. +It is important to keep the team informed on all status changes for flaky tests. This allows for fast follow-up when a test is marked as flaky. * Use the [built-in Slack or Microsoft Teams webhook integrations](../webhooks/) to transform webhook payloads into messages. * Trunk's built-in templates help you get started and test the connection. diff --git a/merge-queue/getting-started/configure-branch-protection.mdx b/merge-queue/getting-started/configure-branch-protection.mdx index 273291ef..1b7be8c4 100644 --- a/merge-queue/getting-started/configure-branch-protection.mdx +++ b/merge-queue/getting-started/configure-branch-protection.mdx @@ -42,7 +42,7 @@ When a pull request enters the queue, Trunk creates a draft pull request to test Things to look out for: * This mode also creates a `trunk-merge/` branch -* Trunk automatically closes the draft PRs and merge the original PRs +* Trunk automatically closes the draft PRs and merges the original PRs **When to use a different approach:** If you have expensive preview deployments, review-only workflows, or security scans that you don't want running during merge queue testing, consider Push-triggered mode instead. diff --git a/merge-queue/reference/common-problems.mdx b/merge-queue/reference/common-problems.mdx index 1d76332a..01d83496 100644 --- a/merge-queue/reference/common-problems.mdx +++ b/merge-queue/reference/common-problems.mdx @@ -136,7 +136,7 @@ og:title: "Trunk Merge Queue FAQ" - By default, both [dependabot](https://docs.github.com/en/code-security/dependabot/working-with-dependabot/managing-pull-requests-for-dependency-updates#changing-the-rebase-strategy-for-dependabot-pull-requests) and [renovate](https://docs.renovatebot.com/updating-rebasing/#updating-and-rebasing-branches) both will rebase their PRs whenever other PRs merge into their base branch. If that rebase happens when those PRs are in the queue, they will get kicked since they were updated. There are two ways to mitigate this: + By default, both [dependabot](https://docs.github.com/en/code-security/dependabot/working-with-dependabot/managing-pull-requests-for-dependency-updates#changing-the-rebase-strategy-for-dependabot-pull-requests) and [renovate](https://docs.renovatebot.com/updating-rebasing/#updating-and-rebasing-branches) will rebase their PRs whenever other PRs merge into their base branch. If that rebase happens when those PRs are in the queue, they will get kicked since they were updated. There are two ways to mitigate this: 1. Both dependabot and renovate can be configured to not automatically rebase, while renovate can specifically be configured to only rebase if there's a merge conflict ([dependabot](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#rebase-strategy), [renovate](https://docs.renovatebot.com/configuration-options/#rebasewhen)) 2. Their PRs can be manually merged, and anything currently in the merge queue will restart with those merged changes