ci: run the lint jobs on ubuntu instead of macos - #743
Open
jamesnrokt wants to merge 2 commits into
Open
Conversation
Lint Checks and Kotlin Lint Checks are the last two jobs on macos-latest, which carries a 10x billing multiplier. Nothing they run needs macOS: Android Lint, ktlint and publishMavenPublicationToMavenLocal are all platform-independent, and there is no darwin/xcode/brew reference anywhere in the build. The macOS runner is a leftover. It arrived in 2021 when the emulator job needed macOS for hardware-accelerated Android emulation, before GitHub's Linux runners exposed KVM. The emulator jobs have since moved to ubuntu-latest with explicit KVM enablement, so the reason no longer applies to anything in this workflow. kit-compatibility-test already runs publishMavenPublicationToMavenLocal plus kit builds on ubuntu-latest, which is a heavier Gradle workload than lint, so the required toolchain is demonstrably fine on Linux in this repo. ubuntu-latest also has more memory than macos-latest (16 GB vs 14 GB). Secondary benefit: these jobs now share the Linux Gradle User Home cache written on main, rather than needing their own macOS/arm64 entries. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PR SummaryLow Risk Overview Gradle steps are unchanged—Android Lint, ktlint, and Reviewed by Cursor Bugbot for commit 63fe6f9. Bugbot is set up for automated code reviews on this repo. Configure here. |
|
This was referenced Jul 30, 2026
jamesnrokt
added a commit
that referenced
this pull request
Jul 30, 2026
…746) * ci: remove hardcoded secrets check from PR workflow Trunk already runs trufflehog at the PR level (trufflehog@3.90.6 in .trunk/trunk.yaml), alongside a custom mparticle-api-key-check rule, so this job was duplicating secret scanning that Trunk Check already covers. The job was also intermittently red -- 3 failures in 70 recent runs, always in ~5s. It failed on #742 while passing on #743 and #744 with identical config. The cause is in the reusable workflow, which resolves and downloads "latest" trufflehog at runtime by curling the GitHub releases API and grepping the response; that step breaks when the API rate-limits. Trunk pins its trufflehog version and has no runtime download, so it does not share this failure mode. Nothing in the workflow depends on the removed job; no other job referenced it via needs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci: enable trufflehog-git to scan the commits a PR adds The already-enabled trufflehog linter runs `trufflehog filesystem` against changed files in the working tree, so it cannot see a secret that was committed and then removed in a later commit on the same branch -- the file no longer exists to scan. trufflehog-git closes that gap. It runs `trufflehog git --since-commit ${upstream-ref}`, walking only the commits the PR adds, so it stays fast (~1.7s) and does not resurface historical findings. Demonstrated with a private key committed then removed on a branch: filesystem scan -> missed it (only the pre-existing daily.yml FP) git-history scan -> PrivateKey <- probe-key.pem @ f48c6617 Both linters keep Trunk's default --only-verified, so this widens scan scope, not the reporting threshold. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
BrandonStalnaker
approved these changes
Jul 30, 2026
denischilik
approved these changes
Jul 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
Lint ChecksandKotlin Lint Checksare the last two jobs onmacos-latest, which GitHub bills at a 10× multiplier. On the most recent full run they accounted for ~12.7 minutes of wall time — roughly 127 billed minutes, the most expensive thing in the suite for the cheapest work in it.The runner is a leftover.
git log -Straces it to the 2021 Actions migration (b198d1e), wheremacos-latestwas picked for the emulator job, because macOS was then the only runner with hardware-accelerated Android emulation. The emulator jobs have since moved toubuntu-latestwith explicit KVM enablement, so the one workload that genuinely needed macOS no longer uses it — the lint jobs just inherited the runner.Nothing they run is platform-specific: Android Lint, ktlint and
publishMavenPublicationToMavenLocal. There is nodarwin,xcode,breworos.namereference anywhere in the build.What changed
lint-checksandkotlin-lint-checks:runs-on: macos-latest→ubuntu-latest.Validation
kit-compatibility-testalready runspublishMavenPublicationToMavenLocalplus kit release builds onubuntu-latestand passes — a heavier Gradle workload than lint, on the same toolchain — so the toolchain is proven on Linux in this repo.ubuntu-latestalso has more memory thanmacos-latest(16 GB vs 14 GB).I cannot prove this locally, having no Linux runner, so CI on this PR is the real test. If either job fails for a genuinely platform-specific reason, close this PR and leave the runner alone.
Independent of #742, which also touches
pull-request.yml; the two edit different lines and I verified they merge cleanly in either order.