feat: reproducible builds (linux)

[DistractionRectangle]

Goal

Ideally, running make build on a local dev machine reproduces the build process and artifacts as closely as possible to the github release workflow. Some ci/cd specific build steps are to be expected (setting version, changing API endpoints to check for updates, etc), however, as it stands the github workflow actually contains extra build steps which are required to build the linux artifacts.

Put a different way, the github release should be able to run make build and produce the official stable release with minimal github release specific pre/post processing steps.

Tasklist

• Refactor tauri.conf.json

Tauri doesn't have an escape hatch to opt out of bundling dependencies of bundled resources/files of appimages. It's a sane default for appimages, but there are valid reasons to want to opt out of this behavior.

The workaround for this is to not bundle files which pull in undesired dependencies with tauri - remove them from the resources/files objects and manually bundle them in a post build step. However, as written, all platforms share a singular tauri.conf.json configuration, and modifying the bundle.resources object has implications for non linux platforms.

Tauri supports refactoring platform specific configuration out of tauri.conf.json in to platform specific files, which tauri will automatically pickup and merge with the base tauri.conf.json. This let's us fold a simplified version of this part of the github workflow into tauri.linux.json.conf without changing the configuration of the other builds.

• Add yarn post-processing target

Or something like that.

As touched upon above, appimages require a post tauri build process to bundle additional files which we want to avoid shipping the associated dependencies for. This is also a good jumping off point to trigger bundling of flatpaks if we do pursue that, as they consume the deb package produced by tauri build and tauri doesn't natively build them

While this issue is linux centric, this can be extended with run-script-os to support the other platforms if that's needed/desirable.

• Shim linuxdeploy version without tainting system cache

The fix in #5463 in fine inside a devcontainer or github runner, but on local dev machines it taints the system .cache and silently changes tauri builds.

A more elegant solution would be a small utility or wrapper script which moves XDG_CACHE_HOME to <project root>/.cache and pulls in our desired version of linuxdeploy as part of the build process.

Out of scope

No response

[freelerobot]

Not sure if @hiento09 or @Minh141120 have suggestions here, thank you

[Minh141120]

Hi @DistractionRectangle,

Thanks for flagging this. I think this is a solid direction and definitely worth pursuing. The idea of aligning the local make build process more closely with the GitHub release workflow makes a lot of sense and would go a long way toward simplifying both development and maintenance.

In parallel, we're also actively working on a Flathub submission to streamline distribution for Linux users and avoid many of the issues we've been running into.

Really appreciate your continued support and contributions. It’s been a huge help!