Anyone successfully building plugins in GitHub actions?

[dannytaurus]

I'm investigating the possibility of building plugins using GitHub actions.

I've read a few posts in this forum and looked through @Christoph-Hart 's code at https://github.com/christophhart/vcsl_hise/blob/master/build.sh

Just so I'm clear - to build a plugin in a GitHub action, I'll need both the full HISE source code and a compiled version of HISE?

Or do I just need to git clone the source code in the GitHub workflow?

[aaronventure]

@dannytaurus As long as you don't need to compile scriptnode networks first or do anything funny with hardcoded networks, you can do it.

You need the HISE binary to initiate the calls and the build order, create the JUCE project and generate all the code.

You need the HISE source because it contains the JUCE source, which is what's actually used to build your plugin.

So pull the repo, build HISE, pull your project, build your project.

If you need to install IPP first, check this https://github.com/sudara/pamplejuce/blob/main/.github/workflows/build_and_test.yml , though this uses Cmake.

HISE is a bit funny here. The annoyance is how it uses the appdata folder, which makes having multiple HISE builds annoying or sometimes impossible. It should store its preferences and stuff right next to the binary, I don't think anyone building from source ever moves the binary. This would make it possible to add the HISE repo as a git submodule, effectively letting you lock projects to a certain commit, which would be great as HISE starts making more and more breaking changes (a welcome development).

Now every project can have its own HISE build, which would definitely be a good change rather than having to rebuild it with different flags for every project, because you have to manage and keep track of which flags you're using for which project, and hopping projects becomes silly. In fact, I'll tag the boss here, and hopefully get his take here @Christoph-Hart

If that were to happen, you'd just pull your repo, initialize submodules, build the HISE submodule, call the binary to build the project, without having to worry about breaking changes or manually updating your build script every time you validate a new HISE commit as safe.

[Christoph Hart]

@aaronventure which preference in the app data folder files mess with your build pipeline? There‘s a special export_ci mode which tries to sandbox most settings like IPP or current project and I had never any issues with this, but then I didn‘t have to use varying settings across projects too much

1. pull the latest HISE build (or the one you want to use for your release)
2. compile the CI build - you can just run the scripts in the tools folder that are executed on every commit as they will spit out a semi-optimized HISE binary that you can use for exporting your plugins.
3. pull your project and run your build file.

If you are using hardcoded networks, just make sure that anything in the AdditionalSourceCode folder is under version control, then you shouldn‘t need to compile the dll before loading your project in HISE.