Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI for release builds #4490

Open
rom1v opened this issue Dec 3, 2023 · 4 comments
Open

CI for release builds #4490

rom1v opened this issue Dec 3, 2023 · 4 comments

Comments

@rom1v
Copy link
Collaborator

rom1v commented Dec 3, 2023

Since the beginning, I wanted a single script to build and release everything, so from a Linux machine I can execute ./release.sh and produce all the binaries to publish.

But it is too restrictive: although the Windows release can be cross-compiled from Linux, it's not the same for macOS.

I'm considering (for a long time) to write one script per target (release_windows.sh, release_macos.sh, release_deb.sh…), that will be run on CI (e.g. GitHub actions) on different platforms (release_macos.sh will be run on a macOS VM for example). This CI will produce the release binaries for all platforms.

I started to refactor a bit the cross-compilation script in 67f356f, and I plan to integrate scrcpy-deps directly in the scrcpy repo (done by #4713), with scripts to build minimal binaries of the FFmpeg libs for Windows and macOS (for Linux, scrcpy will depend on the FFmpeg from the distribution).

In practice, there are 2 parts to build:

  • scrcpy-server, which requires the Android SDK, and which is common to every platform
  • the scrcpy client, one per platform/architecture

I don't want every CI job to build its own scrcpy-server (it is unnecessary, it would produce different binaries for each target, and it would make them all require the Android SDK). So I would like a separate job just for the server. But in the end, scrcpy-server must be included in the final release for each target (in scrcpy-win64.zip, in scrpy-win32.zip, in scrcpy-ubuntu23.10.deb, etc…) which are produced by the CI.

What is the correct way to achieve this kind of job dependency (each one must depend on the output of the job which produces scrcpy-server)? (I'm am very inexperienced in CI)

Thank you for your help and suggestions 🙂

Refs #2256 (comment) 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)

@yume-chan
Copy link
Contributor

yume-chan commented Dec 3, 2023

Job dependency and sharing files is relatively easy, GitHub has a documentation page on it: https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#passing-data-between-jobs-in-a-workflow.

@rom1v
Copy link
Collaborator Author

rom1v commented Mar 2, 2024

I plan to integrate scrcpy-deps directly in the scrcpy repo

Done by #4713 (and also builds the other dependencies).

@morellexf13
Copy link

what's left to build macOS binaries?

I plan to integrate scrcpy-deps directly in the scrcpy repo

Done by #4713 (and also builds the other dependencies).

@LeeBinder
Copy link

LeeBinder commented Mar 6, 2024

@morellexf13 stand-alone native Mac (Intel) APP at the bottom of this comment of mine 😉 (corrected 2024-03-07 10:45)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants