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

pull the latest HISE build (or the one you want to use for your release)
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.
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.

aaronventure

@Christoph-Hart okay that's a build command, but I still have to use a single global build for the interface.

There's a bunch of stuff HISE stores in its app data folder. Like it's source code path, faust path, etc. It would be nice to be able to just go to the HISE submodule directory in the project directory and launch the version of HISE that I know will work for that specific project.

For example, I opened an older project now and dropShadowFromPath is broken in it. Now I gotta find the last commit where it worked.

d.healey

@aaronventure said in Anyone successfully building plugins in GitHub actions?:

Like it's source code path,

You can set this through the CLI at compile time. Doesn't have an option for the FAUST path though.

HISE Command Line Tool
----------------------

Usage: 

HISE COMMAND [FILE] [OPTIONS]

Commands: 

export: builds the project using the default settings
export_ci: builds the project using customized behaviour for automated builds
 - always use VisualStudio 2017 on Windows
 - don't copy the plugins to the plugin folders
 - use a relative path for the project file
 - ignore the global HISE path and use the HISE repository folder from the
   current HISE executable
full_exp -p:PATH: exports the project as Full Instrument Expansion (aka HISE Player Library)
 - you must supply the absolute path to the .XML file with the '-p:' argument.
compress_samples -p:PATH: collects all HLAC files into a hr1 archive
 - if an info.hxi file is found in the current work directory, it will embed it into the
   archive. You must supply a XML project file with the `-p:` argument that will be
   loaded during the export.
Arguments: 
FILE      The path to the project file (either .xml or .hip you want to export).
          In CI mode, this will be the relative path from the current project folder
          In standard mode, it must be an absolute path
-h:{TEXT} sets the HISE path. Use this if you don't have compiler settings set.
-ipp      enables Intel Performance Primitives for fast convolution.
-l        This can be used to compile a version that runs on legacy CPU models.
-t:{TEXT} sets the project type ('standalone' | 'instrument' | 'effect' | 'midi')
-p:{TEXT} sets the plugin type ('VST'  | 'AU'   | 'VST_AU' | 'AAX' |)
                                'ALL'  | 'VST2' | 'VST3'   | 'VST23AU' )
          (Leave empty for standalone export). Note that if you use the VST2, VST3,
           VST23AU it will override the project settings so you can export both versions).
           Note: The VST23AU flag will skip AU on Windows and build only VST2 and VST3.
-nolto    deactivates link time optimisation. The resulting binary is not as optimized
          but the build time is much shorter
-D:NAME=VALUE Adds a temporary preprocessor definition to the extra definitions.
              You can use multiple definitions by using this flag multiple times.
--test [PLUGIN_FILE]
Tests the given plugin

set_project_folder -p:PATH
Changes the current project folder.

set_hise_folder -p:PATH
Sets the location for the HISE source code folder.
get_project_folder
Returns the current project folder.

set_version -v:NEW_VERSION_STRING
Sets the project version number to the given string

clean [-p:PATH] [-all]
Cleans the Binaries folder of the given project.
-p:PATH - the path to the project folder.

create-win-installer [-a:x64|x86] [-noaax] [-vst2] [-vst3]
Creates a template install script for Inno Setup for the project
Add the -noaax flag to not include the AAX build
If you want to include VST2 and or VST3 plugins, specify the version.
If no VST flag is set, then the VST2 plugin is included as default

create-docs -p:PATH -h:PATH -s:PATH
Creates the HISE documentation files from the markdown files in the given directory (-p) to the given di.
to the HTML directory specified by -h (and optionally rebuilding the snippet examples from -s)
load -p:PATH

Loads the given file (either .xml file or .hip file) and returns the status code
You can call Engine.setCommandLineStatus(1) in the onInit callback to report an error

compile_networks -c:CONFIG
Compiles the DSP networks in the given project folder. Use the -c flag to specify the build
configuration ('Debug' or 'Release')

ustk

@aaronventure said in Anyone successfully building plugins in GitHub actions?:

There's a bunch of stuff HISE stores in its app data folder. Like it's source code path, faust path, etc. It would be nice to be able to just go to the HISE submodule directory in the project directory and launch the version of HISE that I know will work for that specific project.

Useful for custom Hise versions as well

d.healey

@ustk said in Anyone successfully building plugins in GitHub actions?:

Useful for custom Hise versions as well

There is only one version of HISE and he has many commit hashes.

Anyone successfully building plugins in GitHub actions?

24

1.9k

12.3k

106.9k