Fix/Clean Up Development Builds

[nurse-the-code]

We recently updated the development builds to specify which CPU architecture is being used. It appears that resulted in two problems:

1. We have files from multiple fortnightly development builds in the same release section. (see the attached screen shot). After talking with @artoonie, it sounds like when creating a fortnightly build, we should delete the old fortnightly build files.
2. We stopped generating .sha512 files for the executable installers (.deb, .dmg, .exe) when we started generating the .golden.sha512 for the .zip files. Let's add those back in.

[nurse-the-code]

@artoonie partially fixed the first part by deleting the old build files. It looks like we still have old .zip and .tar.gz files from May 31st.

But the second part still does not appear to be fixed:

We stopped generating .sha512 files for the executable installers (.deb, .dmg, .exe) when we started generating the .golden.sha512 for the .zip files. Let's add those back in.

Finally, while most of the build files say 2 days ago (from the most recent fortnightly build), the header for some reason says "May 31" and the description text says that it is a build of changes "as of June 2nd". Can we fix that too?

[artoonie]

I have fixed both of those in PR #860

Note that there are additional files in the "Package", which is separate from the "Release": https://github.com/BrightSpots/rcv/actions/runs/9744047355

The package is 700mb and contains every cache file for every OS we support. I believe it was an intentional decision to not include these files in the release, since they're only useful for airgapped builds, but cannot be sure. @yezr do you recall why we decided to have some files in the "Package" not included in the "Release"?

Also -- we should document this in the wiki since I forgot about it!

[yezr]

I cannot remember why we would leave out the airgap caches. I think we were just scrambling to get it out for that certification and overlooked adding it to the official release?

[artoonie]

Alright, I've added all cache files back in. I personally find this much sloppier, since 99% of users don't need the cache files, and this makes it quite hard to find which files are important. I imagine a better naming scheme could help (e.g. all cache files begin with cache_?). Let me know what you think is needed here: https://github.com/BrightSpots/rcv/releases/tag/build-double-develop

[yezr]

So the cache files are always created and are part of the build Package? I imagine that for any user who needs an airgapped build that we would be personally involved. In that case, we can always provide them the cache and it wouldn't be required to be a part of the build artifacts.

To make the release a little cleaner, and maybe prevent confusion, I'm fine with not making those an explicit part of the release but leave them in the Package.

[nurse-the-code]

@artoonie I noticed that we don't have a current development build for arch64 Linux. Does https://github.com/BrightSpots/rcv/pull/860 fix this?

Not sure if we need a build for this platform. I am only asking because my main Linux machine is arch64.

[artoonie]

The linux build should be 64-bit -- does it not work on your linux box?

[nurse-the-code]

The linux build should be 64-bit -- does it not work on your linux box?

My main linux machine is a MacBook Air with linux installed. So it's ARM64/aarch64 rather than x86_64 (e.g. Intel, AMD).

Also, if I were to run Linux virtualized on my MacBook Pro, I would probably want to use an ARM64 build of linux (and RCTab) rather than trying to emulated x86_64.

[artoonie]

Ah, understood, thanks for the clarification -- and yes, I agree, we should build for aarch64.

It looks like it should be a feature coming soon to github actions, but is not a currently supported runner: https://github.com/orgs/community/discussions/19197#discussioncomment-9019461