[FR]: use different workflows for test and release

[zsliu98]

Hi! I have just seen your post on the JUCE forum. And I think it might be a good time to make some changes to workflows.

This is related to #46. Pros and Cons of using different workflows are:

Pros:

• we have more flexibility to choose different plugin formats when building it locally / for the test / for the release
  • especially for AAX, since I have to download it back to sign on my local computer :(
• we don't need a fat binary for the test
• we don't need code-signing for the test

All of these Pros can shorten the test workflow execution time. And by removing the code-signing for the test, anyone can download & run the test without modification. They can then take care of code-signing when they are ready for the release.

Cons:

• if we change the building process (e.g., change the compiler), we have to copy-paste it for each workflow

[sudara]

I think you are saying that "most of the time I push to CI, I don't need a code signed, packaged release with all formats" and proposing that we push more of the logic to the release path (right now, tagging a version and pushing commit).

I like the idea on the surface.

Would the main benefit be shorted time spent in CI?

anyone can download & run the test without modification

This is a big benefit — right now when people start a new template, the builds are instantly red until they configure code signing. Code signing is trivial time-wise in CI, but not developer-time-wise....

Maybe this would be a good use of CMakePresets.json — I want to add configurability without people having to constantly edit CMakeLists.txt and have trouble merging in.

Couple questions I have:

• Reusable workflows. I think these exist now? Maybe this could take a lot of logic out of the main workflow file.
• Could Pamplejuce become more of a dependency somehow?
• Someone submitted a PR to make all the CMake in Pamplejuce functions/macros https://github.com/sudara/cmake-includes/pull/2 — It was too big of a breaking change, but the intentions were sound (making Pamplejuce more of a dependency than spaghetti-config)

[zsliu98]

Would the main benefit be shorted time spent in CI?

Yes. I want the action to be finished ASAP. For people using private repos, this would reduce the cost of billing hours. I set plugin formats to the env variable and let CMake read that.

if (DEFINED ENV{PLUGIN_OS_FORMAT})
    set(FORMATS "$ENV{PLUGIN_OS_FORMAT}")
else ()
    set(FORMATS AU VST3 Standalone)
endif ()

Reusable workflows. I think these exist now? Maybe this could take a lot of logic out of the main workflow file.

Reusable workflows seem to be useful. However, as we cannot pass env variables directly, we have to use with to provide each of them. I am not sure whether it is worthy.

Could Pamplejuce become more of a dependency somehow? Someone submitted a PR to make all the CMake in Pamplejuce functions/macros

I think some plugins would have to modify a part of Pamplejuce, especially the workflow files. Therefore, I don't think dependency is a good idea. For example, I have to download signed AAX and package it with AU & VST3 to one installer in the release workflow.

BTW if we make all the CMake in Pamplejuce functions/macros, we may also have to use scripts to generate distribution.xml and Innoscript so that they can suit any target formats. I have done this already.

https://github.com/ZL-Audio/ZLEqualizer/blob/main/packaging/packager_macOS.py

https://github.com/ZL-Audio/ZLEqualizer/blob/main/packaging/packager_Windows.py