@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.