Add codespell support (without CI) and make it fix some typos (#536)

Per "request" of @0ko in https://codeberg.org/forgejo/forgejo/pulls/3270#issuecomment-1774032

TODOs
- postponed: how to add codespell (written in Python) to CI -- separate workflow? add to some other step? to some other tool/specification?

Reviewed-on: https://codeberg.org/forgejo/docs/pulls/536
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Yaroslav Halchenko <debian@onerussian.com>
Co-committed-by: Yaroslav Halchenko <debian@onerussian.com>
This commit is contained in:
Yaroslav Halchenko 2024-05-05 14:53:04 +00:00 committed by Earl Warren
parent 4cba3d36b3
commit 9ad5f2ab0f
19 changed files with 36 additions and 29 deletions

7
.codespellrc Normal file
View file

@ -0,0 +1,7 @@
[codespell]
# Ref: https://github.com/codespell-project/codespell#using-a-config-file
skip = .git*,*-lock.yaml,.codespellrc
check-hidden = true
# ALLWAYS - ALL WAYS, config variable
ignore-regex = \bALLWAYS\b
# ignore-words-list =

View file

@ -83,7 +83,7 @@ pnpm run lint
```
Prettier is also able to automatically format the code according to its rules.
To do so, ue the following command.
To do so, use the following command.
Be aware that it can occasionally break things, so be sure to check what it changes.
```shell
@ -111,7 +111,7 @@ Most changes should either be sent as a _single commit per PR_, or should be squ
_Fast-forwarding is the preferred merge strategy._
Changes can then be [backported](#backports) (or if appropriate frontported) by cherry-picking.
Rarely, it will make sense to create a feature branch containting a series of commits that will
Rarely, it will make sense to create a feature branch containing 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

View file

@ -379,7 +379,7 @@ runner:
# The labels of a runner are used to determine which jobs the runner can run, and how to run them.
# Like: ["macos-arm64:host", "ubuntu-latest:docker://node:16-bullseye", "ubuntu-22.04:docker://node:16-bullseye"]
# If it's empty when registering, it will ask for inputting labels.
# If it's empty when execute `deamon`, will use labels in `.runner` file.
# If it's empty when execute `daemon`, will use labels in `.runner` file.
labels: []
cache:
@ -595,7 +595,7 @@ will have the `Forgejo runner` declare that it supports the `node20` and `bullse
If the list of labels is empty, it defaults to `docker:docker://node:16-bullseye` and will declare the label `docker`.
Declaring a label means that the `Forgejo runner` will accept tasks that specify this label in the `runs-on` field.
So, to mimick the GitHub runners, the `runs-on` field can be set to `ubuntu-22.04:docker://node:20-bullseye` for instance.
So, to mimic the GitHub runners, the `runs-on` field can be set to `ubuntu-22.04:docker://node:20-bullseye` for instance.
With this, the Forgejo runner will respond to `runs-on: ubuntu-22.04` and will use the `node:20-bullseye` image from hub.docker.com.
This image is quite capable of running many of the workflows that are designed for the GitHub runners.
For a slightly bigger image, use `ghcr.io/catthehacker/ubuntu:act-22.04` instead of `node:20-bullseye` which should be compatible with most actions while remaining relatively small.

View file

@ -849,7 +849,7 @@ Additional settings can be included in this section to specify where the data is
- `ResponseWriter`: the responseWriter from the request.
- `RequestID`: the value matching REQUEST_ID_HEADERSdefault: `-`, if not matched.
- You must be very careful to ensure that this template does not throw errors or panics as this template runs outside the panic/recovery script.
- `REQUEST_ID_HEADERS`: **\<empty\>**: You can configure multiple values that are splited by comma here. It will match in the order of configuration, and the first match will be finally printed in the access log.
- `REQUEST_ID_HEADERS`: **\<empty\>**: You can configure multiple values that are split by comma here. It will match in the order of configuration, and the first match will be finally printed in the access log.
- e.g.
- In the Request Header: X-Request-ID: **test-id-123**
- Configuration in app.ini: REQUEST_ID_HEADERS = X-Request-ID

View file

@ -184,7 +184,7 @@ An important assumption for the Forgejo image to make is to own the folders it w
and reads from. This is naturally an issue since file-system permissions are a machine-local
concept and don't translate over the network easily.
We assume that a server with the hostname `server` is accessible which has a folder `/respositories`
We assume that a server with the hostname `server` is accessible which has a folder `/repositories`
shared via NFS. Append an entry to your `/etc/exports` like
```shell
@ -204,7 +204,7 @@ Four aspects to consider:
Effectively we are now able to write and create files and folders on the remote share. With the `all_squash` setting, we map
all users to one user, hence all data writable by one user is writable by all users, implying all files have a `drwxrwxrwx`
setting (abreviated "`0777` permissions"). We can also "fake-own" data, since all `chown` calls are now mapped to the anonymous user. This is an
setting (abbreviated "`0777` permissions"). We can also "fake-own" data, since all `chown` calls are now mapped to the anonymous user. This is an
important behaviour.
We now mount this folder on the `client` which will host Forgejo to a folder `/mnt/repositories`...

View file

@ -9,7 +9,7 @@ Forgejo can act as an instance wide OAuth2 provider. To achieve that, OAuth2 app
## Pre-registered applications
The following OAuth2 applications are pre-registered beause it is generally useful for Forgejo to be an OAuth2 provider for the corresponding third party software. Their usage is explained in the [Forgejo user guide](../../user/oauth2-provider/).
The following OAuth2 applications are pre-registered because it is generally useful for Forgejo to be an OAuth2 provider for the corresponding third party software. Their usage is explained in the [Forgejo user guide](../../user/oauth2-provider/).
- **git-credential-manager** is the name of the OAuth2 application for the [Git Credential Manager](https://github.com/git-ecosystem/git-credential-manager) (a Git [credential helper](https://git-scm.com/docs/gitcredentials#_custom_helpers))
- **git-credential-oauth** is the name of the OAuth2 application for the [git-credential-oauth](https://github.com/hickford/git-credential-oauth) (a Git [credential helper](https://git-scm.com/docs/gitcredentials#_custom_helpers))

View file

@ -78,4 +78,4 @@ AcceptEnv GIT_PROTOCOL
### Database performance
When trying to undertand poor database performance in conjunction with Forgejo, it is useful to set `[database].SLOW_QUERY_THRESHOLD` to a value lower than the default (5 seconds). This ensures that SQL queries that are slow, but not too slow to meet the default value, are logged and can provide insight into what kind of SQL queries are slow, moreover, this is useful information for Forgejo contributors to find the code where this SQL query is executed and understand the context.
When trying to understand poor database performance in conjunction with Forgejo, it is useful to set `[database].SLOW_QUERY_THRESHOLD` to a value lower than the default (5 seconds). This ensures that SQL queries that are slow, but not too slow to meet the default value, are logged and can provide insight into what kind of SQL queries are slow, moreover, this is useful information for Forgejo contributors to find the code where this SQL query is executed and understand the context.

View file

@ -9,4 +9,4 @@ The Forgejo [domains](https://codeberg.org/forgejo/meta/issues/41) are owned by
## Forgejo Governance
Forgejo was bootstraped in November 2022 and defines [its governance](https://codeberg.org/forgejo/governance/src/branch/main/README.md) in a [dedicated repository](https://codeberg.org/forgejo/governance).
Forgejo was bootstrapped in November 2022 and defines [its governance](https://codeberg.org/forgejo/governance/src/branch/main/README.md) in a [dedicated repository](https://codeberg.org/forgejo/governance).

View file

@ -130,7 +130,7 @@ Reach out to packagers and users to manually verify the release works as expecte
It will trigger a workflow to:
- Push the vX.Y.Z tag to https://codeberg.org/forgejo/forgejo
- Downoad Binaries from https://codeberg.org/forgejo-experimental, sign them and copy them to https://codeberg.org/forgejo
- Download Binaries from https://codeberg.org/forgejo-experimental, sign them and copy them to https://codeberg.org/forgejo
- Copy container images from https://codeberg.org/forgejo-experimental to https://codeberg.org/forgejo
### Forgejo release mirror

View file

@ -146,7 +146,7 @@ resource r0 {
volume 0 {
# device name
device /dev/drbd0;
# specify disk to be used for devide above
# specify disk to be used for device above
disk /dev/nvme0n1p5;
# where to create metadata
# specify the block device name when using a different disk
@ -434,7 +434,7 @@ echo 'export TERM=vt100' >> .bashrc
### Creating a runner
Multiple runners can co-exist on the same machine. To keep things
organized they are located in a directtory that is the same as the url
organized they are located in a directory that is the same as the url
from which the token is obtained. For instance
DIR=codeberg.org/forgejo-integration means that the token was obtained from the
https://codeberg.org/forgejo-integration organization.

View file

@ -162,7 +162,7 @@ run in sequence. It is not a substitute for `artifacts`.
Note that [actions/cache](https://code.forgejo.org/actions/cache) has `zstd`
as a dependency for creating tar archives in the runner.
## Auto cancelation of workflows
## Auto cancellation of workflows
When a new commit is pushed to a branch, the workflows that are were
triggered by parent commits are canceled.
@ -315,13 +315,13 @@ A context is an object that contains information relevant to a `workflow` run. F
### secrets
A map of the respository secrets. It is empty if the `event` that triggered the `workflow` is `pull_request` and the head is from a fork of the repository.
A map of the repository secrets. It is empty if the `event` that triggered the `workflow` is `pull_request` and the head is from a fork of the repository.
Example: `${{ secrets.MYSECRETS }}`
### vars
A map of the respository variables.
A map of the repository variables.
Example: `${{ vars.MYVARIABLE }}`
@ -818,7 +818,7 @@ jobs:
steps:
- run: |
grep Alpine /etc/os-release
echo SUCESS
echo SUCCESS
```
[Check out the example](https://code.forgejo.org/forgejo/end-to-end/src/branch/main/actions/example-container/.forgejo/workflows/test.yml)
@ -1032,7 +1032,7 @@ test "KEY2=$KEY2" = "KEY2=value2"
- **action:** a repository that can be used in a way similar to a function in any programming language to run a single **step**.
- **artifact** is a file or collection of files produced during a **workflow** run.
- **automatic token** is the token created at the begining of each **workflow**.
- **automatic token** is the token created at the beginning of each **workflow**.
- **context** is a top level object available in an expression that contains information about the running workflow.
- **expression:** a string enclosed in `${{ ... }}` and evaluated at runtime.
- **job:** a sequential set of **steps**.

View file

@ -11,4 +11,4 @@ bugs, or even casually host a project.
Please make sure you have a mirror or backup of any important data uploaded
to Forgejo Next! It won't be reset unless there is a need to, but this instance is
running potentially unstable code, so don't use it as your only storage for
irreplacable valuable data.
irreplaceable valuable data.

View file

@ -38,7 +38,7 @@ Please consult the [enry][enry] or [linguist][linguist] documentation for more d
## Adjusting the language detection
Sometimes the programming language of a file is not recognized properly, or it is miscategorized. Forgejo provides a mechanism where the language detection can be told about the language of a file, and its category can be adjusted aswell. The same mechanism can also force a file to be considered for language statistics, regardless of its category - or the opposite, too: to tell Forgejo never to consider it.
Sometimes the programming language of a file is not recognized properly, or it is miscategorized. Forgejo provides a mechanism where the language detection can be told about the language of a file, and its category can be adjusted as well. The same mechanism can also force a file to be considered for language statistics, regardless of its category - or the opposite, too: to tell Forgejo never to consider it.
The way to do this is via a [`.gitattributes`][gitattributes] file. This file has a simple syntax where each line is made up of a pattern, followed by a space separated list of attributes. There are many attributes that git itself supports, but we're only going to talk about the custom attributes for language detection. All of these have a `linguist-` prefix, as that is where they originate from.

View file

@ -65,7 +65,7 @@ Example:
There are some restrictions in place:
- Code linked in private repositories will not be displayed if the current viewer has insufficent permissions.
- Code linked in private repositories will not be displayed if the current viewer has insufficient permissions.
- It can only ever be a permalink; means linking to files by a branch or tag will not result in a preview.
- There is a maximum amount of lines that will be rendered. By default this is 50.
- Only permalinks to the current instance will work.

View file

@ -66,11 +66,11 @@ to authenticate on https://code.forgejo.org:
- `git clone https://code.forgejo.org/earl-warren/test`
- `git push` will open new page on the default browser, looking like this:
![git-credential-oauth OAuth2 grant page](../_images/user/oauth2-provider/oauth-git-credential-client.png)
- subsequent `git push` will re-use the token obtained from OAuth2 as long as it remains in the [git credential-cache](https://git-scm.com/docs/git-credential-cache) (i.e. 2h / 7200s)
- subsequent `git push` will reuse the token obtained from OAuth2 as long as it remains in the [git credential-cache](https://git-scm.com/docs/git-credential-cache) (i.e. 2h / 7200s)
> **NOTE:** Scopes are not implemented for OAuth2 tokens and they can be used to execute any actions on behalf the user, not just git related actions. Scoped applications tokens or SSH keys limited to interactions with the repository should be prefered in environments where security is a concern.
> **NOTE:** Scopes are not implemented for OAuth2 tokens and they can be used to execute any actions on behalf the user, not just git related actions. Scoped applications tokens or SSH keys limited to interactions with the repository should be preferred in environments where security is a concern.
It is possible for any user to manually register a new OAuth2 application in the `/user/settings/applications` page for the purpose of using a Git [credential helpers](https://git-scm.com/docs/gitcredentials#_custom_helpers) different from the pre-registered ones. In that case the `~/gitconfig` setting (`oauthClientId` etc.) needs to be adapted accrodingly
It is possible for any user to manually register a new OAuth2 application in the `/user/settings/applications` page for the purpose of using a Git [credential helpers](https://git-scm.com/docs/gitcredentials#_custom_helpers) different from the pre-registered ones. In that case the `~/gitconfig` setting (`oauthClientId` etc.) needs to be adapted accordingly
## Examples

View file

@ -16,7 +16,7 @@ The following section describes how to create it.
## Index Repository
Cargo stores informations about the available packages in a package index stored in a git repository.
Cargo stores information about the available packages in a package index stored in a git repository.
In Forgejo this repository has the special name `_cargo-index`.
After a package was uploaded, its metadata is automatically written to the index.
The content of this repository should not be manually modified.

View file

@ -96,12 +96,12 @@ Previously published packages are not deleted by disabling the Package Registry.
## Deduplication
The package registry has a build-in deduplication of uploaded blobs.
The package registry has a built-in deduplication of uploaded blobs.
If two identical files are uploaded only one blob is saved on the filesystem.
This ensures no space is wasted for duplicated files.
If two packages are uploaded with identical files, both packages will display the same size but on the filesystem they require only half of the size.
Whenever a package gets deleted only the references to the underlaying blobs are removed.
Whenever a package gets deleted only the references to the underlying blobs are removed.
The blobs get not removed at this moment, so they still require space on the filesystem.
When a new package gets uploaded the existing blobs may get referenced again.

View file

@ -6,7 +6,7 @@ origin_url: 'https://github.com/go-gitea/gitea/blob/e865de1e9d65dc09797d165a51c8
## Swift Packages Repository
Publish [Swift](hhttps://www.swift.org/) packages for your user or organization.
Publish [Swift](https://www.swift.org/) packages for your user or organization.
### Requirements

View file

@ -16,7 +16,7 @@ To protect a branch, you need to go to the repositorys **Settings** >
![Add a new rule](../_images/user/protection/branch-protect.png)
The name of the branch can be a glob where / is the separator and **
spans accross separators. For instance `main`, `release/**`or`precious\*`.
spans across separators. For instance `main`, `release/**`or`precious\*`.
If two rules apply to the same branch, the one that has no glob takes
precedence.