* Rename "You're done" to "Starting Your Server"
* Add instructions for initial registration token flow
* Shorten "How do I know it works" section
* Beautify "What's Next" section
* Link docker builds to section in dev pages
* Delete old section on port forwarding
* Create new section on port exposing, near reverse proxy section
* Rewrite Other Reverse Proxies section to update specified routes
* Move reverse proxy software caveats into its own subsection
* Other wording and structure fixes and improvements
* Use indirect URLs
* Change your.server.name to canonical example.com
* Put Getting help section in a tip admonition
* Remove statement on Caddy preference
* Clean up "What's next" section
* Use de facto unstasble path instead of the standard one
* Document both the unstable and well-known paths as being exposed by
Continuwuity when set
* Make curling said path one of the Testing steps
* Removing confusing console `~$` prefix symbols, move commands and
response into separate code blocks
* Number the MSCs
- enabling the `http3` features requires unstable features, namely `reqwest_unstable`
- the main suggestion of cargo is to enable this through RUSTFLAGS
- we had no way to customize RUSTFLAGS, now we do
- changed the max-perf package to showcase this feature
- also turn on http3 by default in both max-perf and the default build
(jade approved this)
Previously, we would push all tagged releases into the stable component,
including alphas and rc's. Let's use some regex to only push stable
releases which conform to tag "^v+\d\.+\d\.+\d$"
so we ONLY get the manually published releases into the stable
component.
All pre-releases go into the "unstable" component for now. Nightly builds
go into the "dev" component (as before) and feature branches still get
their dedicated component named after the branch.
TODO: It would be nifty if stable releases would ALSO be published at the
unstable component.
When running the mirror-images step from within the release-image workflow
we receive error messages such as
> msg="Failed to sync" target=ghcr.io/continuwuity/continuwuity:v0.5.0-rc.7
> source=forgejo.ellis.link/continuwuation/continuwuity:v0.5.0-rc.7
> error="failed to send blob post, ref
> ghcr.io/continuwuity/continuwuity@sha256:74976f7b85018b5abd867333bc783c7230d985a4b0af595bbf55964e25afe6ef:
> unauthorized"
So, we will need to define our credentials in the release-image workflow too
it seems, when we pull in the mirror-image workflow.
This is a test by adding all credentials that are defined in mirror-images.yml
Probably we don't need them all, but if this does not work, the whole approach
is flawed and we can remove everyting again.
If it works, we should remove unneccessary credentials until we found the
required ones.
stratself
Renovate Bot
Jade Ellis
Getz Mikalsen
Ginger
aviac
timedout
Sebastian Spaeth
ezera
éźera