Repository navigation
[build-tools] Look up ffmpeg on PATH instead of running it - #4582
Merged
Merged
Conversation
gwdp
force-pushed
the
gwdp/ffmpeg-path-check
branch
2 times, most recently
from
October 8, 2026 23:34
d2c88e7 to
c9860c6
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4582 +/- ##
==========================================
+ Coverage 73.92% 73.92% +0.01%
==========================================
Files 1012 1012
Lines 49330 49346 +16
Branches 10650 10656 +6
==========================================
+ Hits 36460 36476 +16
Misses 11878 11878
Partials 992 992 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
gwdp
force-pushed
the
gwdp/ffmpeg-path-check
branch
from
October 8, 2026 23:54
c9860c6 to
dd6102c
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
gwdp
marked this pull request as ready for review
October 9, 2026 00:05
The first run of the preinstalled ffmpeg-full on macos-tahoe-26.6-xcode-27.1 takes about 13 s while it loads its libraries, and the ffmpeg setup waited for that `ffmpeg -version`. Find ffmpeg on PATH the way device-session tools do, and run it once in the background so its first real use does not pay the cold start. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
gwdp
force-pushed
the
gwdp/ffmpeg-path-check
branch
from
October 9, 2026 18:20
dd6102c to
0e2fdfb
Compare
|
✅ Thank you for adding the changelog entry! |
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
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.
Why
Follow-up to #4577. That PR made the Appium step wait for the ffmpeg setup before Appium starts, so iOS recording works on images without ffmpeg. Images that already ship ffmpeg should not pay for that setup.
The setup checks for ffmpeg by running
ffmpeg -versionand waits for it. Onmacos-tahoe-26.6-xcode-27.1, which ships Homebrewffmpeg-full, the first run on a fresh VM took 12.8 s in one probe and 23.7 s in another while the binary loads its 83 libraries. Later runs take 0.06 s. The Android session host waits for the same check.How
ffmpegon the step'sPATHwithout running it: the first entry that is an executable file. An empty entry means the current directory, as it does forspawn. Device-session tools, such as XCUITest's screen recording, resolve ffmpeg the same way.PATH, or after an install, runffmpeg -versiononce in the background and do not wait for it. The binary then loads while Appium installs, so the first recording does not pay the cold start. A failed warm-up is ignored.LLM Authorship
ffmpeg -versionfrom the session setup on the Xcode 27.1 image, and chose thePATHlookup with a background warm-up. Claude Code wrote the change.PATHentries were skipped. They now resolve to the current directory, and a test covers it.ffmpegthat cannot start passes the lookup. This is a known tradeoff, explained in the review thread.Test Plan
EAS workflow on
macos-tahoe-26.6-xcode-27.1: the firstffmpeg -versiontook 12.76 s, and the next two took 0.06 s and 0.07 s.EAS workflow on the same image: a background
ffmpeg -versionstarted with the Appium install took 23.7 s and finished before the Appium install did (36.1 s).build-toolsunit tests insrc/steps: 1337 passed. The ffmpeg tests buildPATHin Jest's in-memory file system. They cover an executable onPATH, a file that is not executable, a directory namedffmpeg, an emptyPATHentry, the Homebrew and apt installs, and warm-ups that reject or throw.The same lookup on a real macOS file system found
/opt/homebrew/bin/ffmpeg, which is a relative symlink into the Homebrew Cellar. The in-memory file system cannot test symlinks, because it checks the link's own mode.yarn build,tsc,oxlint, andoxfmtare clean.EAS workflow on the session runner classes: this branch's built
build-toolsran next to the deployed worker's dist, and calledensureFfmpegInstalledOnceAsync. The control ran the deployed version.ffmpeg -versionmacos-tahoe-26.6-xcode-27.1, deployed (control)macos-tahoe-26.6-xcode-27.1, this branchmacos-tahoe-26.5-xcode-26.6, this branch (Homebrew install)ubuntu-26.04-jdk-17-ndk-r27b-sdk-58, this branchNot run: a hosted session with this branch deployed.
Generated with T3 Code, using Claude Code.