Add a description of the steps necessary to migrate a Gitea installation to Forgejo on Arch Linux using the native packages.
Reviewed-on: https://codeberg.org/forgejo/docs/pulls/298
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Paul Sargent <psarge@gmail.com>
Co-committed-by: Paul Sargent <psarge@gmail.com>
The upcoming 3.1 release of the Forgeo runner will allow to specify
which template and release must be must be used for a LXC
container. It also defines the lxc:// scheme as distinct from the
host:// scheme.
The host:// scheme is documented to be used for running jobs directly
from the host, which was not possible with the Forgejo runner versions
prior to 3.1
- [Shiki](https://github.com/shikijs/shiki) doesn't support highlighting
Go templates, so instead use handlebars template highlighting for this
code snippet.
- split the installation page into separate pages for Docker, binary install, and packages
- clarify the next step is the installation page via the web
- clarify the first user created has admin rights
- clarify how values in the config sheet are provided when using Docker installation
- explain database preparation can be skipped if using SQLite which is built-in
Fixes: https://codeberg.org/forgejo/docs/issues/117
Documentation proposal for remote data mounting, following up from https://codeberg.org/forgejo/forgejo/issues/1590
Co-authored-by: Daniel Bischof <daniel.bischof@protonmail.com>
Reviewed-on: https://codeberg.org/forgejo/docs/pulls/193
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: dbischof90 <dbischof90@noreply.codeberg.org>
Co-committed-by: dbischof90 <dbischof90@noreply.codeberg.org>
See 9b698362a3
Also remove the token line from the .runner file. It is confusing and
difficult to explain because it is different from the registration
token. It really is a shared secret between the runner and the Forgejo
instance that has a purpose which is entirely different.
The original documentation was written with a focus on local storage
and missed a few important aspects of how storage types can be mixed
together in some subsystems.
* unify the susbsystem paths to be "directory" instead of using "base
path". It is not technically a directory in S3 but looks like one
and the approximation is unlikely to cause confusion.
* use S3 instead of minio where possible to emphasize the storage type
is not MinIO specific and add a section for the compatibility with
garage
* change the document structure to have two separate parts:
* [storage] the global sections
* [xxxx] the subsystem specific section
and within each of them local and S3 are documented separately
because they share nothing
* [storage] is documented to be a fallback if [xxxx] does not exist
for a given subsystem. There is no notion of inheritance because
it behaves in ways that are not tested and for which consistency is
not guaranteed
* backward compatibility with Gitea is documented to be the reason why
there are no safeguards against undocumented features
