Because Electron now has a macOS 11 minimum supported version, we have
no blockers to adopting the latest Go toolchain. This also lets us use
the new `range` features in Go, among other things.
Until we split up the rest of the codebase into workspaces, having a
separate dependabot group for docsite won't work since the root rule
will always conflict
This adds the new tasks `docsite:start`, `docsite:build:public`,
`docsite:build:embedded`, `storybook:build`, and `copyfiles:*:*` to
Taskfile.
It also updates the "Build Helper" and "Docsite and Storybook CI/CD"
workflows to use these new tasks.
It also makes the docsite embedded build a dependency of the electron
tasks, ensuring that the embedded docsite is included when building
locally.
Tested and confirms this works on Windows
NodeJS 20 is almost EOL so I'm updating our workflows to use NodeJS 22.
This does not change anything about our app, which will still use NodeJS
20 until Electron shifts away from it. NodeJS 22 is fully
backwards-compatible with NodeJS 20 so there's no issue from a testing
standpoint.
## Summary
We are moving our docsite to this repo for better coordination.
## What's changed?
- The docsite codebase is now in docs/
- The docsite will replace storybook as the published GitHub Pages site
for this repo
- Storybook will now be hosted at https://docs.waveterm.dev/storybook
- A new CI workflow will validate any changes to Storybook or the
docsite
- A combined CD workflow will build and deploy Storybook and the docsite
as a single artifact
- The Build Helper workflow will now build an embedded version of the
docsite before building the app, ensuring the docsite version it has is
always the latest
There was a race condition in the Build Helper where if multiple runners
got to the "Create draft release" step at the same time, we could get
duplicate releases created. Now, each of the build runners will upload
the artifacts to the workflow artifact feed. Then, a single runner will
create the draft release.
This will take the latest artifact from the waveterm-docs repo and embed
it in the app binary. When the help view is launched, it will be served
from our backend. If the embedded copy doesn't exist, such as in
unpackaged versions of the app or in locally packaged versions, it will
use the hosted site instead.
There is a sibling PR in the docs repository to build the embedded
version of the app (strips out some external links, removes Algolia
DocSearch, updates the baseUrl)
https://github.com/wavetermdev/waveterm-docs/pull/46
This uses the GitHub Form Syntax to make richer issue templates. I took
a lot of inspiration from the Dioxus project for the wording of these
templates.
