Fixes Dev Tools not being able to be opened, among other subtle issue.
This is a frequently reported bug, and we try to apply this workaround
elsewhere, it's just that the .desktop file that electron-builder
generates skips the workaround we have applie e.g. in the /us/bin/pulsar
launcher script.
Gets rid of a lot of if-else that made the code harder to follow.
This should be pretty safe and unproblematic in a standalone script
like this, versus some more complex or nested Node process scenario,
or scenarios with async input/output that might be ongoing
when the process.exit() is handled.
Also, update some of the code comments a bit.
Co-authored-by: Andrew Dupont <github@andrewdupont.net>
Add a new token that can upload Rolling release binaries from Cirrus
to GitHub Releases for the Rolling repo.
Prefer this token in the upload script if it is set in the
corresponding env var ROLLING_UPLOAD_TOKEN, otherwise try GITHUB_TOKEN
(This allows the script to work in Cirrus, where the new env var will
be set, and in GitHub Actions where we use the GITHUB_TOKEN.)
(Testing to see if this can be set per-script, otherwise we will have
to set it for the whole task instead.)
Throw literally the entire script into a try/catch.
This script should exit "cleanly" no matter what,
and avoid erroring out the overall CI run at all costs.
(This script is run on a best-effort basis, and should first do no
harm, since the automation it provides is easy to replicate manually.)
Need to check this way, since the CI script already modifies
the version string to end in something like "2023081600", not "-dev",
for Rolling releases (or for all builds other than Regular releases).
Also: Update and add more logging of what the script is doing.
Also also: Fix some spaces --> tabs on a couple of lines.
Adds a renaming script to rename the binaries with our
Regular release naming scheme, and updates the Cirrus config
to run said renaming script.
De-facto codifies our existing, officially unofficial naming scheme
with a bit of automation.
We can always revise this down the line
if consensus changes for how to name these files.
Just a little institutional knowledge to unburden team members with,
via the (sometimes double-edged sword...) of automation.