Add GitHub Actions workflow for release builds
Better late than never (#4490), I finally worked on a GitHub Actions workflow to build scrcpy releases.
I had to refactor the release.mk makefile to parallelize server and client build jobs. It is only run manually to build a release (not on push or pull request, I don't need it for now).
In the end, it produces a zip artifact containing:
scrcpy-server-XXXscrcpy-win32-XXX.zipscrcpy-win64-XXX.zipSHA256SUMS.txt
where XXX is the input name you give when you manually start the workflow (if empty, it uses the ref name, for example the branch or tag name).
To test it:
- fork the repo to your own account
- checkout the branch from this PR, and push it to your
masterbranch - enable GitHub Actions in your repo settings
- go to the Actions tab
- select "Build"
- select "Run workflow"
- keep
masterbranch, choose a version name (for examplev42) - click on Run workflow
For now, it generates the same targets as ./release.sh did locally (scrcpy-server, release win32, release win64).
The goal now is to add more jobs, especially:
- macOS releases
- .deb packages for Ubuntu and Debian recent versions (#4427)
Your help is welcome! :heart:
Now that scrcpy-server is generated separately once and for all, it will be easier to write the jobs for building the scrcpy client for different targets (Android SDK is not needed).
As an important constraint, the jobs MUST only reference "official" github actions (or dockers images), not actions/images from random users. Keep it as simple as possible.
Fixes #4490 Refs https://github.com/Genymobile/scrcpy/issues/2256#issuecomment-1218375121 and next comments (cc @dur-randir @LeeBinder @Coool) Refs #1709 (cc @dylanmtaylor) Refs #3721 (cc @qmfrederik) Refs #4427 (cc @hacksysteam) Refs #4489 (cc @Gary-Cod)
Awesome, great work, Romain. I'm recovering health-wise right now which might take a while so will be mostly offline for the near future :/
I've added macos build job + modified makefile in my fork at https://github.com/dur-randir/scrcpy/commit/6c4c2c33b34d028de4227f6e5c93b6ad57b610fe. The next question is, this generates unsigned binaries - e.g. you either have to provide a signing key (see https://docs.github.com/en/actions/use-cases-and-examples/deploying/installing-an-apple-certificate-on-macos-runners-for-xcode-development) or a user have to perform additional steps after download (like brew does automatically when installing from casks).
I've added macos build job + modified makefile in my fork at dur-randir@6c4c2c3. The next question is, this generates unsigned binaries - e.g. you either have to provide a signing key (see https://docs.github.com/en/actions/use-cases-and-examples/deploying/installing-an-apple-certificate-on-macos-runners-for-xcode-development) or a user have to perform additional steps after download (like brew does automatically when installing from casks).
amd64 aka x86_64 build actions config ? I can't see them there.
@dur-randir Thank you very much!
A few questions/remarks:
- Could
app/deps/ffmpeg-macos.shbe "merged" intoapp/defs/ffmpeg.shto avoid duplication (a common file for all platforms)? - It seems only FFmpeg is built for macOS, not the other dependencies (SDL and libusb)? (and an
adbbinary for macOS) - Is
macpackabsolutely necessary? Can we build a release without this tool?
I'll read about signing keys later.
Could app/deps/ffmpeg-macos.sh be "merged" into app/defs/ffmpeg.sh to avoid duplication (a common file for all platforms)?
Sure, I've done it separately because of I didn't know in advance what'd be needed to be changed. There's dievergence just in two places - additional args list for configure disable-debug..enable-videotoolbox and export PATH, which can be put under if $HOST in deps/common.
It seems only FFmpeg is built for macOS, not the other dependencies (SDL and libusb)? (and an adb binary for macOS)
They're taken from brew install in binary form.
Is macpack absolutely necessary? Can we build a release without this tool?
Yes and no. I've tried (again!) to make a fully static build (link ffmpeg + libusb + libsdl) but I don't know meson at all and it broke somewhere down the road while double-linking _sha_$whatever while I was trying to shove them all together and then I ceased trying. Without static linking with those dependencies, one must relocate all libraries to be searched by relative paths by DYLD (they're baked by absolute paths by default on macos). IIRC this can be done with native instruments, but they're non-recursive, so I've picked one tool that works recursively out-of-the box. Another one tool is https://github.com/auriamg/macdylibbundler which can be installed from brew. Or create this recursive hand-written loop for path change. Or ideally make a fully static build, but I've given up. If you know meson, maybe you can create a recipe for at least linux, so I can tweak it for macos?
Sure, I've done it separately because of I didn't know in advance what'd be needed to be changed.
:+1:
They're taken from
brew installin binary form.
OK :+1: In the end, I think we want to build them without depending on brew.
IIRC this can be done with native instruments, but they're non-recursive, so I've picked one tool that works recursively out-of-the box.
Indeed, the native tool seems to be install_name_tool (which is used by macpack).
For windows, the scrcpy builds have 6 dll (so these libs are linked dynamically):
avcodec-61.dllavformat-61.dllavutil-59.dllswresample-5.dlllibusb-1.0.dllSDL2.dll
I think the macOS build could do the same, there would be no need for finding dependencies recursively.
Here, i added for MacOS x86-64 thanks to @dur-randir db01900 artifacts One can use adhoc-sign for SIP disabled Systems, idk about others. Need to put scrcpy-server separately in same dir.
Awesome, you ROCK, @Genxster1998 - big THANK you 👍 !
These two script files come in handy 😉:
assign icon.png to scrcpy binary.zip
- Unpack them into the same dir as scrcpy, scrcpy-server etc.
- run 'assign icon.png to scrcpy binary' first (only 1x to assign an icon so it appears in the dock rather than the black terminal icon)
- run 'scrcpy-launcher' to launch scrcpy
@LeeBinder , you won't need a launcher to furnish path to scrcpy-server as it has been set default to executable_path already rather than /opt/... so no need envt. just adb,scrcpy,libs,server in same dir after patching binary for icon. i think *.dylib(s), adb and scrcpy-server can be moved to Frameworks in proper macOS app.
run 'scrcpy-launcher' to launch scrcpy
@Genxster1998 ideally, but it's not working (yet). Because when I simply double-click the scrcpy binary even if scrcpy-server IS present in the same directory, I get:
ERROR: Could not get local file path, using scrcpy-server from current directory
stat: No such file or directory
ERROR: 'scrcpy-server' does not exist or is not a regular file
ERROR: Server connection failed
Try it yourself, please.
Looks as if you need to add something in the compile/ build script so that scrcpy indeed DOES look in the same directory. Something is still missing.
Looks as if you need to add something in the compile/ build script so that scrcpy indeed DOES look in the same directory.
The option is portable: https://github.com/Genymobile/scrcpy/blob/665ccb32f5306ebd866dc0d99f4d08ed2aeb91c3/meson_options.txt#L4
(add -Dportable=true to the meson command)
However, the code to find the executable path is not implemented for macos:
https://github.com/Genymobile/scrcpy/blob/665ccb32f5306ebd866dc0d99f4d08ed2aeb91c3/app/src/sys/unix/file.c#L64-L67
@LeeBinder Thats true indeed , Launching app from launchpad or Finder is not working. I tried adding LSEnvironment dict keys in info.plist which is specifically made for same purpose. yet it still fails to acknowledge server path from there. btw it works with open -a scrcpy.app in terminal. @rom1v Yeah, it is compiling with portable boolean true for meson, i guess a static path could be assigned for MacOS GUI app in ../Resources or ../Libraries Directory. Anyway , a real gui mac app should have a config window/menu/ to assign params for stream size, window size etc or select device.
I see. Agreed, should eventually be in ../Resources (neither in ../Libraries nor in ../Frameworks because it's neither of those but a Android executable binary)
The scripts to build dependencies are currently specific to cross-compile Windows from Linux. I'll have to adapt them to also support native build (will be useful for macOS). Meanwhile, I can merge this PR.
See #5515.