Earl Warren
852b447f91
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 |
||
|---|---|---|
| .forgejo/workflows | ||
| .husky | ||
| .vscode | ||
| docs | ||
| images/user | ||
| scripts | ||
| .editorconfig | ||
| .gitignore | ||
| .npmrc | ||
| .prettierignore | ||
| .prettierrc | ||
| package.json | ||
| pnpm-lock.yaml | ||
| README.md | ||
Forgejo Documentation
This is the documentation for Forgejo and is published on the Forgejo website.
The main development branch of this repo is the
next branch,
which documents the version of Forgejo that is currently being developed.
Each time a new major version of Forgejo is released, a new branch will be created in this repo to document the stable release.
Current release branches are as follows:
Documentation content lives in the docs subfolder, and images in the images subfolder.
Contributing
Pull Requests
PRs should usually be sent against the next branch.
Sometimes it will be appropriate to send a PR against a specific release branch if the changes only affect that release.
Most changes should either be sent as a single commit per PR, or should be squashed before merging. Fast-forwarding is the preferred merge strategy. Changes can then be backported (or if appropriate frontported) by cherry-picking.
Rarely, it will make sense to create a feature branch containting a series of commits that will be merged instead of squashing and fast-forwarding. Such a feature branch can then be merged into multiple versions of the docs if appropriate. In this case, the feature branch should usually be taken from the last common ancestor of all of the version branches into which it will potentially be merged.
If you have commit access to this repository, you should work on a temporary branch within this repository
with the pr/ prefix and submit your pull request from there. Use the following commands to do it.
git clone git@codeberg.org:forgejo/docs ; cd docs
git checkout <target-branch>
git checkout -b pr/<short-pr-desc>
# Make the changes you want to submit
git add . ; git commit
git push -u origin pr/<short-pr-desc>
# Proceed to open your pull request
This is currently necessary due to technical limitations with Forgejo Actions. If you do not have commit access, you may fork this repository and send a pull request the usual way, but a live preview of the website will not be available.
Backports
If a commit is meant to be backported to a stable branch, it must be
labelled with backport/v1.20, backport/v1.19, etc.
Previewing changes
Run pnpm run preview to clone the website repo
and launch a local development server. The current docs branch will be opened in the browser.
Modifications can be made to the docs while the dev server is running, and the preview will live-reload.
Links
All internal links within the documentation content should be relative to each page's path
at the https://forgejo.org/docs/{{version}}/ URL.
File extensions (.md) should not be included, and every URL should end with a trailing slash.
Look at existing links for examples.
Images
Images should use relative URLs to the image files, which will be published at https://forgejo.org/images/{{version}}/.
Code of Conduct
All contributors are required to abide by the Forgejo Code of Conduct.
Feel free to reach out to the moderation team in case of any conflicts.
License
The documentation content originates from several different sources and each page has a different license.
Please check the license frontmatter key near the top of each file to see the relevant license.
Where not otherwise stated, content is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License.