In trying to understand how the build process works, specifically around the building of self-contained apps on macOS, I have come to the possibly incorrect understanding that the building of apps and the release process are deeply intertwined with each other, and that there is a built-in assumption that the only place this happens is inside the core OpenRefine/OpenRefine repository via GitHub Actions. This design has presumably evolved organically, but a review of the snapshot_release.yml file reveals jobs called build, which seems to build the server code only, windows_installer, and mac_test_and_deploy which is some massive, sprawling uber task that doesn't just build a mac version.
Personally, I would have found it useful to be able to build a local version of the app (unsigned, un-notarized unless I explicitly provide credentials in the environment). Whilst having the current system presumably makes the release process easier for the maintainers, would splitting the "build app" and "deploy app to public release" logical actions into separate goals/commands make better engineering sense?
I'm imagining a scenario where the "do a full release" action would automatically run the "build app" actions as a pre-requisite to maintain the single command for authorised release managers, but where the terminally curious could simply build a local copy of the fully standalone app for testing. Does this chime with anyone else?
As you can probably tell from the vestiges in the "refine" script, what you're suggesting is basically how things used to work. Restoring it is probably mainly a matter of splitting the signing and notarization out from the dmg build (or making them optional if the relevant secrets aren't available).
Having said that, "./refine build" will generate a fully working app on your local machine and "./refine" will run it, building it first, if necessary. The only thing missing is the bundled JRE which doesn't seem to be hugely useful since you're going to have to have a working JDK on your machine anyway to do the build. Is there something that I'm missing that makes an unsigned, unnotarized app useful in the Mac ecosystem where such things are hugely discouraged?
If there's a build meister who would like to volunteer to fix this and other build related things like the following, it would be hugely appreciated. Hacking on Maven is one of my least favorite chores.
I guess the main driver for this was the need to review how the JRE was being bundled into the standalone app in an attempt to progress #6052 and so this may well be an edge case of no relevance to general users. It "smells" though, and protecting our future selves and others from spaghetti code and config is always a good thing.
Unfortunately, I have very little time to spare - even less than usual for this time of year - but I figured it was worth a conversation. If I do suddenly find time, I'll come back to it.
Thanks again for all that you serious developers do on this and other projects though.
This resonates. Separating "build the artifact" from "sign/notarize/publish" is generally good CI design, the build should be reproducible locally without any release credentials, and signing/deploy becomes an optional layer on top. The fact that mac_test_and_deploy does everything at once is a classic case of the release path and the build path being fused because it grew that way. Splitting them would help contributors test locally and actually makes the maintainers' pipeline cleaner too. Worth raising as an issue.