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

Introduce CI workflow with GitHub actions #1381

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Dewb
Copy link
Contributor

@Dewb Dewb commented Dec 29, 2020

Hi! Congrats on the 2.1.16 release, and thanks for providing a way for musicians to collaborate while distancing, it's definitely made 2020 a little easier.

I know that managing build and release pipelines across multiple platforms can be time-consuming, and I've been poking at some possible directions to automate some of the process. This PR is an initial suggestion for some automated build infrastructure. There's definitely more that could be done here, but the current state seems like a good starting point for discussion.

What merging this PR in its current state would accomplish:

  • Future PRs would get "build checks" to confirm each new commit builds on all three platforms (Windows, macOS, Linux)
    image
  • The artifacts from these builds will be downloadable from the Actions tab, so people could test PRs on different platforms before merging the PR
    image
  • Changes to the master branch will also produce builds for all three platforms in the Actions tab

What this does not yet do, but could with a little work/discussion:

  • Build the Windows installer (Need to capture and automate which tools/steps are required)
  • Compile the VST project on Windows (Linux works, but there are compilation errors in the Windows build for some reason)
  • Compile the AU project on macOS (compilation errors)
  • Post prerelease-tagged installers for all platforms on the Releases page when new PRs are merged

What this could be further extended to do in the future:

  • Build the binary dependencies too (portaudio, libogg, etc.), to make it easier to adopt new toolchains/compilers (e.g. a newer version of Visual Studio)
  • Test against newer versions of Qt
  • Make it easier to add support for additional platforms/architectures (M1 Macs?)

@@ -81,7 +81,7 @@ cp $qtLibDir/libQt5XcbQpa.so.* packageFiles/
cp $qtLibDir/libicui18n.so.* packageFiles/
cp $qtLibDir/libicuuc.so.* packageFiles/
cp $qtLibDir/libicudata.so.* packageFiles/
cp $qtLibDir/qt5/plugins/platforms/libqxcb.so packageFiles/platforms
cp $qtDir/plugins/platforms/libqxcb.so packageFiles/platforms
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This path may be dependent on the Qt version, I had to change it to build with 5.9.

@elieserdejesus
Copy link
Owner

Hi, the big problem to compile JamTaba using CI is build Qt statically. We need Qt static builds for VST and AU plugins.

The Qt static builds are not officially tested, so is always complicated find the Qt static compilable version. I tested a lot of versions and have 99% of compilation errors. It`s a very time consuming task find a static compilable version.

Sometimes a Qt version compile statically in Windows but fails in Mac 😢

Another approach is try to find a pre compiled Qt (static and working in Windows & Mac) and download this Qt version using the CI scripts. But again it`s a very time consuming task.

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

Successfully merging this pull request may close these issues.

None yet

2 participants