Having two workflows that do mostly the same thing, and the major difference
between them is whether they create a new release, or reuse an existing one,
when they should be sharing the vast majority of code, is rather pointless, and
leads to bugs.
Bugs like forgetting to add the settings required for Windows code signing to
the release workflow.
With the workflows merged, we have a single build workflow to maintain, share
the vast majority of code between snapshot and production builds, and thus, we
can avoid such mishaps in the future.
It also makes the release process slightly more reliable, because the snapshot
and release builds will not trip over each other, as there will be only one.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Do not run the snapshot workflow for tagged releases, and when deleting the
snapshot tag during recreation, push the deletion up to the origin too.
Pushing the deletion up to the origin lets us fully recreate the tag, so it will
not point to some random old commit, but to the latest one.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
For this to work, we need to change our workflow a little: instead of a static
`snapshot` tag, we have to use a SemVer-compatible tag, such as
`0.10.3-snapshot` - effectively the same version that is in `package.json` (sans
the build number).
To make this automatic, there's a new tool, `tools/snapshot-tag`, which strips
the build number from the version in `package.json`, if there's any. We use this
tool to figure out which tag to re-release during the snapshot workflow.
We also have to update README.md to point to the appropriate snapshot, so the
`tools/release/create-snapshot.sh` tool has been updated to take care of that,
too.
With the workflow changes, we can adjust the autoUpdater configuration to allow
pre-releases, and use the "snapshot" channel. Because we only enable this when
running a snapshot release, auto-upgrade *to* a snapshot release will only work
from a snapshot release. Upgrading from an earlier snapshot to a release is not
done either, because we're tied to a given channel.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
It happend a few times before that we updated `package.json`, but forgot to
update `yarn.lock`. This extra steps make sure we don't miss that.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
As part of our snapshot workflow, we delete and re-create the snapshot
release (and tag), to have a consistent tag to link to, and upload artifacts to.
However, when doing so, we only deleted the release and the tag remotely, not on
the local checkout.
This led to every second build failing, until the publish step was re-run.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Some of our updated dependencies require node >= 14 now, so up the version we
use in CI accordingly.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
As it turns out, we fail to build in a CI environment with node 16 on at least
Windows. Lets fall back to node 12, which allows us to continue building
everywhere.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
For historical reasons, we've been using node 10 for both release and snapshot
builds, and 12 for linting. As that's rather old, and some of our transitive
dependencies no longer support anything older than 12, lets move forward, and
bump node to 16. That's the current LTS release, and our whole stack should work
well with it, Electron and serialport included.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We should be doing a proper release, not a pre-release, and also name our
publish step appropriately.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of relying on electron-builder to do the right thing, do the release
process ourselves, step by step.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This is a major restructuring of our GitHub Actions workflows. First of all, we
now have separate workflows for release and snapshot builds, as having them
separate makes it easier to control which one runs when. It also allows us to
fine tune a lot of things for the snapshot workflow, which runs much more often.
Another change is that we're now using a static tag (`snapshot`) for development
builds, rather than a versioned tag, and this tag - and the pre-release on
GitHub - will get remade on every run, to keep it up to date.
We also have the build number back for our snapshot builds again, something we
lost with the transition away from Travis.
Documentation and scripts have been appropriately updated.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Update our `usb` dependency to 1.6.5, which compiles with -std=c++14 set. Also
remove the `CXXFLAGS` environment variable from the GitHub workflows, as they
are no longer needed.
Fixes#661.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We moved away from tagging production releases with a `chrysalis-` prefix, we're
using `-snapshot` postfixes for snapshot builds instead.
In the end, we'll publish a snapshot for every push to master (even if it's a
release push), and we'll publish a release if we're tagged appropriately.
This addresses the second part of #644.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
For the production publish step, we do not need `EP_PRE_RELEASE` set to true, as
we're going to use a draft. We do need `CXXFLAGS` set like in all other steps.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This separates the build and publish steps, so we can have slightly different
publish steps depending on whether we're building a snapshot or a tagged
release. On a tagged release, we'll update the existing draft. On a snapshot,
we'll overwrite an existing pre-release.
Also update the document describing our release process.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
By default, the action we use defaults to `build` as the build script name,
while we use `compile` for the same purpose. I believe `compile` is the better
name, so tell the action to use that.
We need this step so that our sources are compiled before they're packed up.
Without compilation, many of the things we want to end up in the package simply
won't be there, and the build would fail.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To build successfully, we need to pass `-std=c++14` to the c++ compiler while
compiling native dependencies. The easiest to achieve that is setting the
`CXXFLAGS` environment variable appropriately.
Similarly, we set `YARN_GPG` to no, to avoid timeouts on certain platforms.
Both of these were set for Travis, so we just copy them here, too.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Now that we have a "System Information" screen that can create debug bundles,
suggest that screen in the template, instead of recommending saving the dev
console contents.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
