Build a binary and test it on Mac/Windows/Linux

[jgaehring]

We've only been running the development environment up until now, but we need to work through the steps to build a distributable binary and make sure it works on any and all intended platforms.

Just trying out the npm run build script, I got the error:

src/main.ts:2:17 - error TS2307: Cannot find module './App.vue' or its corresponding type declarations.

2| import App from './App.vue';
                  ~~~~~~~~~~~

This should be fixable by adding the .vue extension to the tsconfig.json, or using a shims-vue.d.ts file for something TypeScript calls "ambient modules", although the latter might only be relevant to the IDE, not Vite. See also Vite's Typescript docs and Vue's TypeScript docs.

Similarly, running npm run tauri build errors out rightaway with:

       Error You must change the bundle identifier in `tauri.conf.json > tauri > bundle > identifier`. The default value `com.tauri.dev` is not allowed as it must be unique across applications.

I guess that's to be expected, and we can probably use something like "org.runrig.ews" or some other identifier in reverse domain name notation, with an appropriate subdomain for this application. See the Tauri BundleConfig docs.

[jgaehring]

Just trying out the npm run build script, I got the error:

src/main.ts:2:17 - error TS2307: Cannot find module './App.vue' or its corresponding type declarations.

2| import App from './App.vue';
                  ~~~~~~~~~~~

This was far easier to fix. I just needed to use the vue-tsc command instead of tsc in the npm build script (see f762d6f).

Similarly, running npm run tauri build errors out rightaway with:

       Error You must change the bundle identifier in `tauri.conf.json > tauri > bundle > identifier`. The default value `com.tauri.dev` is not allowed as it must be unique across applications.

I'm changed it to "org.runrig.ews", and it worked just fine (see 7e4c78f).

I successfully built .deb and .AppImage binaries for Linux, but as noted in the Tauri docs on [Cross-Platform Compilation]():

Tauri relies heavily on native libraries and toolchains, so meaningful cross-compilation is not possible at the current moment. The next best option is to compile utilizing a CI/CD pipeline hosted on something like GitHub Actions, Azure Pipelines, GitLab, or other options. The pipeline can run the compilation for each platform simultaneously making the compilation and release process much easier.

For an easy setup, we currently provide Tauri Action, a GitHub Action that runs on all the supported platforms, compiles your software, generates the necessary artifacts, and uploads them to a new GitHub release.

So I'll need to keep testing and read further along in those docs to see what will work best and whether it deems prioritizing at the moment. I'm pretty happy with how well the Linux build process worked, at least, so if I might just punt on the other platforms until there's an explicit need.

[jgaehring]

One snafu so far, it looks like I didn't actually fix #24 like I thought. Running the .AppImage and doing anything that tries to write to the file system crashes the whole app. I neglected to read the docs on Embedding Additional Files. Womp. :confused:

Looking through the documentation and what all is required to code-sign for MacOS and Window, I'm just going to use the Tauri Action to bundle the Linux release for now, though it should be easily adaptable for those platforms later on if the certificate stuff is all squared away. :roll_eyes:

I configured the GHA to run only on the main branch and only when it's also tagged with valid a semver value (see 0d9c77d). The glob pattern syntax that GH uses is a little idiosyncratic, so I'm having trouble testing if the pattern that tests the tag actually works w/o pushing a tag, but here's hoping. :crossed_fingers: I opened a draft PR for this, but will hold off until I get #24 proper resolved. If that goes well, it should automatically post the binaries to our releases. :crossed_fingers: :crossed_fingers:

[jgaehring]

The glob pattern syntax that GH uses is a little idiosyncratic, so I'm having trouble testing if the pattern that tests the tag actually works w/o pushing a tag, but here's hoping. 🤞

I actually did figure out a way to test it, and it seems like the glob pattern I used did work:

https://github.com/runrig-coop/early-warning-system/actions/runs/8395613478/job/22995253855

And the binaries for 1.0.0-alpha.1 have been successfully added to our releases. Because that doesn't incorporate my latest changes that fix #24, I don't expect it will actually work. I have finally gotten the file system stuff resolved on my local machine, so when I push the 1.0.0-alpha.2 tag, we can try testing those binaries on other Linux devices.

There is one hitch: I haven't gotten the .AppImage binaries to work with the file system, only the .deb. That's good enough for me, for now, but it would be nice to work out at some point or another.