MirrorHub/gitea
0
0
Fork 0
mirror of https://github.com/go-gitea/gitea synced 2024-12-22 14:14:11 +01:00
Code Issues Releases Wiki Activity

General documentation cleanup (#3317)

Browse source 
* Clean up spelling, grammar, perspective, whitespace, language, markup, etc.
This commit is contained in:
Michael Lustfield 2018-01-08 16:48:42 -06:00 committed by Kim "BKC" Carlbäcker
parent 923c0105f4
commit 3ee8be3849
30 changed files with 500 additions and 279 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

0
docs/content/doc/advanced.fr-fr.md Executable file → Normal file
View file

158
docs/content/doc/advanced/config-cheat-sheet.en-us.md
View file

@ -15,11 +15,17 @@ menu:
# Configuration Cheat Sheet
This is a cheat sheet for the Gitea configuration file. It contains all settings that can configured.
This is a cheat sheet for the Gitea configuration file. It contains most settings
that can configured as well as their default values.
Any changes to the Gitea configuration file should be made in `custom/conf/app.ini` or any corresponding location. When installing from a distribution, this will typically be found at `/etc/gitea/conf/app.ini`.
Any changes to the Gitea configuration file should be made in `custom/conf/app.ini`
or any corresponding location. When installing from a distribution, this will
typically be found at `/etc/gitea/conf/app.ini`.
The defaults provided here are best-effort (not built automatically). They are accurately recorded in [app.ini.sample](https://github.com/go-gitea/gitea/blob/master/custom/conf/app.ini.sample) (s/master/<tag|release\>. Any string in the format `%(X)s` is a feature powered by [ini](https://github.com/go-ini/ini/#recursive-values), for reading values recursively.
The defaults provided here are best-effort (not built automatically). They are
accurately recorded in [app.ini.sample](https://github.com/go-gitea/gitea/blob/master/custom/conf/app.ini.sample)
(s/master/<tag|release\>). Any string in the format `%(X)s` is a feature powered
by [ini](https://github.com/go-ini/ini/#recursive-values), for reading values recursively.
Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
@ -28,22 +34,34 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
## Overall (`DEFAULT`)
- `APP_NAME`: **Gitea: Git with a cup of tea**: Application name, used in the page title.
- `RUN_USER`: **git**: The user Gitea will run as. This should be a dedicated service (non-user) account. Setting this incorrectly will cause Gitea to not start.
- `RUN_MODE`: **dev**: For performance and other purposes, change this to `prod` when deployed to a production environment. The installation process will set this to `prod` automatically. \[prod, dev, test\]
- `RUN_USER`: **git**: The user Gitea will run as. This should be a dedicated system
(non-user) account. Setting this incorrectly will cause Gitea to not start.
- `RUN_MODE`: **dev**: For performance and other purposes, change this to `prod` when
deployed to a production environment. The installation process will set this to `prod`
automatically. \[prod, dev, test\]
## Repository (`repository`)
- `ROOT`: **~/gitea-repositories/**: Root path for storing all repository data. It must be an absolute path.
- `SCRIPT_TYPE`: **bash**: The script type your server supports, usually this is `bash`, but some users report that only `sh` is available.
- `ROOT`: **~/gitea-repositories/**: Root path for storing all repository data. It must be
an absolute path.
- `SCRIPT_TYPE`: **bash**: The script type this server supports, usually this is `bash`,
but some users report that only `sh` is available.
- `ANSI_CHARSET`: **\<empty\>**: The default charset for an unrecognized charset.
- `FORCE_PRIVATE`: **false**: Force every new repository to be private.
- `DEFAULT_PRIVATE`: **last**: Default private when create a new repository. \[last, private, public\]
- `MAX_CREATION_LIMIT`: **-1**: Global maximum creation limit of repositories per user, `-1` means no limit.
- `PULL_REQUEST_QUEUE_LENGTH`: **1000**: Length of pull request patch test queue, make it as large as possible. Use caution when editing this value.
- `MIRROR_QUEUE_LENGTH`: **1000**: Patch test queue length, increase if pull request patch testing starts hanging.
- `PREFERRED_LICENSES`: **Apache License 2.0,MIT License**: Preferred Licenses to place at the top of the List. Name must match file name in conf/license or custom/conf/license.
- `DISABLE_HTTP_GIT`: **false**: Disable the ability to interact with repositories over the HTTP protocol.
- `USE_COMPAT_SSH_URI`: **false**: Force ssh:// clone url instead of scp-style uri when default SSH port is used.
- `DEFAULT_PRIVATE`: **last**: Default private when creating a new repository.
\[last, private, public\]
- `MAX_CREATION_LIMIT`: **-1**: Global maximum creation limit of repositories per user,
`-1` means no limit.
- `PULL_REQUEST_QUEUE_LENGTH`: **1000**: Length of pull request patch test queue, make it
as large as possible. Use caution when editing this value.
- `MIRROR_QUEUE_LENGTH`: **1000**: Patch test queue length, increase if pull request patch
testing starts hanging.
- `PREFERRED_LICENSES`: **Apache License 2.0,MIT License**: Preferred Licenses to place at
the top of the list. Name must match file name in conf/license or custom/conf/license.
- `DISABLE_HTTP_GIT`: **false**: Disable the ability to interact with repositories over the
HTTP protocol.
- `USE_COMPAT_SSH_URI`: **false**: Force ssh:// clone url instead of scp-style uri when
default SSH port is used.
## UI (`ui`)
@ -60,40 +78,43 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
## Markdown (`markdown`)
- `ENABLE_HARD_LINE_BREAK`: **false**: Whether or not to enable hard the line break extension.
- `ENABLE_HARD_LINE_BREAK`: **false**: Enable Markdown's hard line break extension.
## Server (`server`)
- `PROTOCOL`: **http**: Either `http`, `https`, `fcgi`, or `unix`.
- `DOMAIN`: **localhost**: Domain name of your server.
- `PROTOCOL`: **http**: \[http, https, fcgi, unix\]
- `DOMAIN`: **localhost**: Domain name of this server.
- `ROOT_URL`: **%(PROTOCOL)s://%(DOMAIN)s:%(HTTP\_PORT)s/**: Full public URL of Gitea server.
- `HTTP_ADDR`: **0.0.0.0**: HTTP listen address.
- If `PROTOCOL` is set to `fcgi`, Gitea will listen for FastCGI requests on TCP socket defined by `HTTP_ADDR` and `HTTP_PORT` configuration settings.
- If `PROTOCOL` is set to `fcgi`, Gitea will listen for FastCGI requests on TCP socket
defined by `HTTP_ADDR` and `HTTP_PORT` configuration settings.
- If `PROTOCOL` is set to `unix`, this should be the name of the Unix socket file to use.
- `HTTP_PORT`: **3000**: HTTP listen port.
- If `PROTOCOL` is set to `fcgi`, Gitea will listen for FastCGI requests on TCP socket defined by `HTTP_ADDR` and `HTTP_PORT` configuration settings.
- `UNIX_SOCKET_PERMISSION`: **666**: Permisson mode for Unix socket.
- `DISABLE_SSH`: **false**: Disables SSH feature when it's not available.
- `START_SSH_SERVER`: **false**: When enabled, uses the built-in SSH server.
- `SSH_DOMAIN`: **%(DOMAIN)s**: Domain name of your ssh server, used for displayed clone URL.
- If `PROTOCOL` is set to `fcgi`, Gitea will listen for FastCGI requests on TCP socket
defined by `HTTP_ADDR` and `HTTP_PORT` configuration settings.
- `UNIX_SOCKET_PERMISSION`: **666**: Permissions for the Unix socket.
- `DISABLE_SSH`: **false**: Disable SSH feature when it's not available.
- `START_SSH_SERVER`: **false**: When enabled, use the built-in SSH server.
- `SSH_DOMAIN`: **%(DOMAIN)s**: Domain name of this server, used for displayed clone URL.
- `SSH_PORT`: **22**: SSH port displayed in clone URL.
- `SSH_LISTEN_PORT`: **%(SSH\_PORT)s**: Port for the built-in SSH server.
- `OFFLINE_MODE`: **false**: Disables use of CDN for static files and Gravatar for profile pictures.
- `DISABLE_ROUTER_LOG`: **false**: Mutes printing of the router log.
- `DISABLE_ROUTER_LOG`: **false**: Mute printing of the router log.
- `CERT_FILE`: **custom/https/cert.pem**: Cert file path used for HTTPS.
- `KEY_FILE`: **custom/https/key.pem**: Key file path used for HTTPS.
- `STATIC_ROOT_PATH`: **./**: Upper level of template and static files path.
- `ENABLE_GZIP`: **false**: Enables application-level GZIP support.
- `LANDING_PAGE`: **home**: Landing page for unauthenticated users, either `home` or `explore`.
- `LANDING_PAGE`: **home**: Landing page for unauthenticated users \[home, explore\].
- `LFS_START_SERVER`: **false**: Enables git-lfs support.
- `LFS_CONTENT_PATH`: **./data/lfs**: Where to store lfs files.
- `LFS_CONTENT_PATH`: **./data/lfs**: Where to store LFS files.
- `LFS_JWT_SECRET`: **\<empty\>**: LFS authentication secret, change this a unique string.
- `REDIRECT_OTHER_PORT`: **false**: If true and `PROTOCOL` is https, redirects http requests on another (https) port.
- `REDIRECT_OTHER_PORT`: **false**: If true and `PROTOCOL` is https, redirects http requests
on another (https) port.
- `PORT_TO_REDIRECT`: **80**: Port used when `REDIRECT_OTHER_PORT` is true.
## Database (`database`)
- `DB_TYPE`: **mysql**: The database type you choose, either `mysql`, `postgres`, `mssql` or `sqlite3`.
- `DB_TYPE`: **mysql**: The database type in use \[mysql, postgres, mssql, sqlite3\].
- `HOST`: **127.0.0.1:3306**: Database host address and port.
- `NAME`: **gitea**: Database name.
- `USER`: **root**: Database username.
@ -111,31 +132,41 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
## Security (`security`)
- `INSTALL_LOCK`: **false**: Disable to allow accessing the install page.
- `SECRET_KEY`: **random at every install**: Global secret key. This should be changed.
- `INSTALL_LOCK`: **false**: Disallow access to the install page.
- `SECRET_KEY`: **\<random at every install\>**: Global secret key. This should be changed.
- `LOGIN_REMEMBER_DAYS`: **7**: Cookie lifetime, in days.
- `COOKIE_USERNAME`: **gitea\_awesome**: Name of the cookie used to store the current username.
- `COOKIE_REMEMBER_NAME`: **gitea\_incredible**: Name of cookie used to store authentication information.
- `REVERSE_PROXY_AUTHENTICATION_USER`: **X-WEBAUTH-USER**: Header name for reverse proxy authentication.
- `DISABLE_GIT_HOOKS`: **false**: Prevent all users (including admin) from creating custom git hooks.
- `COOKIE_REMEMBER_NAME`: **gitea\_incredible**: Name of cookie used to store authentication
information.
- `REVERSE_PROXY_AUTHENTICATION_USER`: **X-WEBAUTH-USER**: Header name for reverse proxy
authentication.
- `DISABLE_GIT_HOOKS`: **false**: Prevent all users (including admin) from creating custom
git hooks.
## OpenID (`openid`)
- `ENABLE_OPENID_SIGNIN`: **false**: Allow authentication in via OpenID.
- `ENABLE_OPENID_SIGNUP`: **! DISABLE\_REGISTRATION**: Allow registering via OpenID.
- `WHITELISTED_URIS`: **\<empty\>**: If non-empty, list of POSIX regex patterns matching OpenID URI's to permit.
- `BLACKLISTED_URIS`: **\<empty\>**: If non-empty, list of POSIX regex patterns matching OpenID URI's to block.
- `WHITELISTED_URIS`: **\<empty\>**: If non-empty, list of POSIX regex patterns matching
OpenID URI's to permit.
- `BLACKLISTED_URIS`: **\<empty\>**: If non-empty, list of POSIX regex patterns matching
OpenID URI's to block.
## Service (`service`)
- `ACTIVE_CODE_LIVE_MINUTES`: **180**: Time limit (min) to confirm account/email registration.
- `RESET_PASSWD_CODE_LIVE_MINUTES`: **180**: Time limit (min) to confirm forgot password reset process.
- `REGISTER_EMAIL_CONFIRM`: **false**: Enable this to ask for mail confirmation of registration. Requires `Mailer` to be enabled.
- `DISABLE_REGISTRATION`: **false**: Disable registration, after which only admin can create accounts for users.
- `RESET_PASSWD_CODE_LIVE_MINUTES`: **180**: Time limit (min) to confirm forgot password reset
process.
- `REGISTER_EMAIL_CONFIRM`: **false**: Enable this to ask for mail confirmation of registration.
Requires `Mailer` to be enabled.
- `DISABLE_REGISTRATION`: **false**: Disable registration, after which only admin can create
accounts for users.
- `REQUIRE_SIGNIN_VIEW`: **false**: Enable this to force users to log in to view any page.
- `ENABLE_NOTIFY_MAIL`: **false**: Enable this to send e-mail to watchers of a repository when something happens, like creating issues. Requires `Mailer` to be enabled.
- `ENABLE_NOTIFY_MAIL`: **false**: Enable this to send e-mail to watchers of a repository when
something happens, like creating issues. Requires `Mailer` to be enabled.
- `ENABLE_REVERSE_PROXY_AUTHENTICATION`: **false**: Enable this to allow reverse proxy authentication.
- `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION`: **false**: Enable this to allow auto-registration for reverse authentication.
- `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION`: **false**: Enable this to allow auto-registration
for reverse authentication.
- `ENABLE_CAPTCHA`: **true**: Enable this to use captcha validation for registration.
## Webhook (`webhook`)
@ -151,43 +182,52 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
- `DISABLE_HELO`: **\<empty\>**: Disable HELO operation.
- `HELO_HOSTNAME`: **\<empty\>**: Custom hostname for HELO operation.
- `HOST`: **\<empty\>**: SMTP mail host address and port (example: smtp.gitea.io:587).
- `FROM`: **\<empty\>**: Mail from address, RFC 5322. This can be just an email address, or the "Name" \<email@example.com\> format.
- `FROM`: **\<empty\>**: Mail from address, RFC 5322. This can be just an email address, or
the "Name" \<email@example.com\> format.
- `USER`: **\<empty\>**: Username of mailing user (usually the sender's e-mail address).
- `PASSWD`: **\<empty\>**: Password of mailing user.
- `SKIP_VERIFY`: **\<empty\>**: Do not verify the self-signed certificates.
- **Note:** Gitea only supports SMTP with STARTTLS.
- `USE_SENDMAIL`: **false** Use the operating system's `sendmail` command instead of SMTP. This is common on linux systems.
- Note that enabling sendmail will ignore all other `mailer` settings except `ENABLED`, `FROM` and `SENDMAIL_PATH`.
- `SENDMAIL_PATH`: **sendmail**: The location of sendmail on the operating system. (can be command or full path)
- `USE_SENDMAIL`: **false** Use the operating system's `sendmail` command instead of SMTP.
This is common on linux systems.
- Note that enabling sendmail will ignore all other `mailer` settings except `ENABLED`,
`FROM` and `SENDMAIL_PATH`.
- `SENDMAIL_PATH`: **sendmail**: The location of sendmail on the operating system. (can be
command or full path)
## Cache (`cache`)
- `ADAPTER`: **memory**: Cache engine adapter, either `memory`, `redis`, or `memcache`. If you want to use `redis` or `memcache`, be sure to rebuild everything with build tags `redis` or `memcache`: `go build -tags='redis'`.
- `ADAPTER`: **memory**: Cache engine adapter, either `memory`, `redis`, or `memcache`.
- To use `redis` or `memcache`, be sure to rebuild everything with build tags `redis` or
`memcache`: `go build -tags='redis'`.
- `INTERVAL`: **60**: Garbage Collection interval (sec), for memory cache only.
- `HOST`: **\<empty\>**: Connection string for `redis` and `memcache`.
- Redis: `network=tcp,addr=127.0.0.1:6379,password=macaron,db=0,pool_size=100,idle_timeout=180`
- Memache: `127.0.0.1:9090;127.0.0.1:9091`
- Redis: `network=tcp,addr=127.0.0.1:6379,password=macaron,db=0,pool_size=100,idle_timeout=180`
- Memache: `127.0.0.1:9090;127.0.0.1:9091`
## Session (`session`)
- `PROVIDER`: **memory**: Session engine provider, either `memory`, `file`, `redis`, or `mysql`.
- `PROVIDER`: **memory**: Session engine provider \[memory, file, redis, mysql\].
- `PROVIDER_CONFIG`: **data/sessions**: For file, the root path; for others, the connection string.
- `COOKIE_SECURE`: **false**: Enable this to force using HTTPS for all session access.
- `COOKIE_NAME`: **i\_like\_gitea**: The name of the cookie used for the session ID, defaults to `i_like_gitea`.
- `COOKIE_NAME`: **i\_like\_gitea**: The name of the cookie used for the session ID.
- `GC_INTERVAL_TIME`: **86400**: GC interval in seconds.
## Picture (`picture`)
- `GRAVATAR_SOURCE`: **gravatar**: Can be `gravatar`, `duoshuo` or anything like `http://cn.gravatar.com/avatar/`.
- `GRAVATAR_SOURCE`: **gravatar**: Can be `gravatar`, `duoshuo` or anything like
`http://cn.gravatar.com/avatar/`.
- `DISABLE_GRAVATAR`: **false**: Enable this to use local avatars only.
- `ENABLE_FEDERATED_AVATAR`: **false**: Enable support for federated avatars (see http://www.libravatar.org)
- `ENABLE_FEDERATED_AVATAR`: **false**: Enable support for federated avatars (see
http://www.libravatar.org)
- `AVATAR_UPLOAD_PATH`: **data/avatars**: Path to store local and cached files.
## Attachment (`attachment`)
- `ENABLED`: **true**: Enable this to allow uploading attachments.
- `PATH`: **data/attachments**: Path to store attachments.
- `ALLOWED_TYPES`: **see app.ini.sample**: Allowed MIME types, e.g. `image/jpeg|image/png`, use `*/*` for all types.
- `ALLOWED_TYPES`: **see app.ini.sample**: Allowed MIME types, e.g. `image/jpeg|image/png`.
Use `*/*` for all types.
- `MAX_SIZE`: **4**: Maximum size (MB).
- `MAX_FILES`: **5**: Maximum number of attachments that can be uploaded at once.
@ -231,10 +271,9 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
- `MAX_GIT_DIFF_FILES`: **100**: Max number of files shown in diff view.
- `GC_ARGS`: **\<empty\>**: Arguments for command `git gc`, e.g. `--aggressive --auto`.
## markup (`markup`)
## Markup (`markup`)
Gitea supports external markup support, you can integrate all your favorite tool. For example,
below will add a markup named `asciidoc` which is followed `markup.` ini section. And there are some config items below.
Gitea can support Markup using external tools. The example below will add a markup named `asciidoc`.
```ini
[markup.asciidoc]
@ -244,10 +283,11 @@ RENDER_COMMAND = "asciidoc --out-file=- -"
IS_INPUT_FILE = false
```
- ENABLED: Whether enable this tool. default is false.
- FILE_EXTENSIONS: List of file extensions that should be rendered by an external command. Multiple extentions needs a comma as splitter.
- RENDER_COMMAND: External command to render all matching extensions.
- IS_INPUT_FILE: Input is not a standard input but a file param followed `RENDER_COMMAND`, default is false.
- ENABLED: **false** Enable markup support.
- FILE\_EXTENSIONS: **\<empty\>** List of file extensions that should be rendered by an external
command. Multiple extentions needs a comma as splitter.
- RENDER\_COMMAND: External command to render all matching extensions.
- IS\_INPUT\_FILE: **false** Input is not a standard input but a file param followed `RENDER_COMMAND`.
## Other (`other`)

51
docs/content/doc/advanced/customizing-gitea.en-us.md
View file

@ -15,42 +15,57 @@ menu:
# Customizing Gitea
The main way to customize Gitea is by using the `custom` folder. This is the central place to override and configure features.
Customizing Gitea is typically done using the `custom` folder. This is the central
place to override configuration settings, templates, etc.
If you install Gitea from binary, after the installation process ends, you can find the `custom` folder next to the binary.
Gitea will create the folder for you and prepopulate it with a `conf` folder inside, where Gitea stores all the configuration settings provided through the installation steps (have a look [here](https://docs.gitea.io/en-us/config-cheat-sheet/) for a complete list).
If Gitea is deployed from binary, all default paths will be relative to the gitea
binary. If installed from a distribution, these paths will likely be modified to
the Linux Filesystem Standard. Gitea will create required folders, including `custom/`.
Application settings are configured in `custom/conf/app.ini`. Distributions may
provide a symlink for `custom` using `/etc/gitea/`.
If you can't find the `custom` folder next to the binary, please check the `GITEA_CUSTOM` environment variable, that can be used to override the default path to something else. `GITEA_CUSTOM` might be set for example in your launch script file. Please have a look [here](https://docs.gitea.io/en-us/specific-variables/) for a complete list of environment variables.
- [Quick Cheat Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/)
- [Complete List](https://github.com/go-gitea/gitea/blob/master/custom/conf/app.ini.sample)
**Note** that you have to restart Gitea for it to notice the changes.
If the `custom` folder can't be found next to the binary, check the `GITEA_CUSTOM`
environment variable; this can be used to override the default path to something else.
`GITEA_CUSTOM` might, for example, be set by an init script.
- [List of Environment Variables](https://docs.gitea.io/en-us/specific-variables/)
**Note:** Gitea must perform a full restart to see configuration changes.
## Customizing /robots.txt
To make Gitea serve your own `/robots.txt` (by default, an empty 404 status is served), simply create a file called `robots.txt` in the `custom` folder with the [expected contents](http://www.robotstxt.org/).
To make Gitea serve a custom `/robots.txt` (default: empty 404), create a file called
`robots.txt` in the `custom` folder with [expected contents](http://www.robotstxt.org/).
## Serving custom public files
To make Gitea serve custom public files (like pages and images), use the folder `custom/public/` as the webroot. Symbolic links will be followed.
To make Gitea serve custom public files (like pages and images), use the folder
`custom/public/` as the webroot. Symbolic links will be followed.
For example, a file `image.png` stored in `custom/public`, can be accessed with the url `http://your-gitea-url/image.png`.
For example, a file `image.png` stored in `custom/public/`, can be accessed with
the url `http://gitea.domain.tld/image.png`.
## Changing the default avatar
Place the png image at the following path: `custom/public/img/avatar_default.png`
Place the png image at the following path: `custom/public/img/avatar\_default.png`
## Customizing Gitea pages
The `custom/templates` folder allows you to change every single page of Gitea.
The `custom/templates` folder allows changing every single page of Gitea. Templates
to override can be found in the `templates` directory of Gitea source. Override by
making a copy of the file under `custom/templates` using a full path structure
matching source.
You need to be aware of the template you want to change. All templates can be found in the `templates` folder of the Gitea sources.
Any statement contained inside `{{` and `}}` are Gitea's templete syntax and
shouldn't be touched without fully understanding these components.
When you find the correct .tmpl file, you need to copy it in the `custom/templates` folder of your installation, __respecting__ any subfolder you found in the source template.
You can now customize the template you copied in `custom/templates`, being carefully to not break the Gitea syntax.
Any statement contained inside `{{` and `}}` are Gitea templete's syntax and shouldn't be touch, unless you know what are you doing.
To add in custom HTML to the header or the footer of the page, in the `templates/custom` directory there are `header.tmpl` and `footer.tmpl` that can be modified. This is useful if you want to add in custom CSS files, or additional Javascript.
To add custom HTML to the header or the footer of the page, in the `templates/custom`
directory there is `header.tmpl` and `footer.tmpl` that can be modified. This can be
a useful place to add custom CSS files or additional Javascript.
## Customizing gitignores, labels, licenses, locales, and readmes.
Place your own files in corresponding sub-folder under `custom/options`.
Place custom files in corresponding sub-folder under `custom/options`.

25
docs/content/doc/advanced/hacking-on-gitea.en-us.md
View file

@ -15,21 +15,28 @@ menu:
# Hacking on Gitea
We won't cover the basics of a Golang setup within this guide. If you don't know how to get the environment up and running you should follow the official [install instructions](https://golang.org/doc/install).
Familiarity with the existing [installation instructions](https://golang.org/doc/install)
is required for this section.
If you want to contribute to Gitea you should fork the project and work on the `master` branch. There is a catch though, some internal packages are referenced by their GitHub URL. So you have to trick the Go tool to think that you work on a clone of the official repository. Start by downloading the source code as you normally would:
To contribute to Gitea, fork the project and work on the `master` branch.
Some internal packages are referenced using their respective Github URL. This can
become problematic. To "trick" the Go tool into thinking this is a clone from the
official repository, download the source code using "go get" and follow these instructions.
```
go get -d code.gitea.io/gitea
```
Now it's time to fork the [Gitea repository](https://github.com/go-gitea/gitea) on GitHub, after that you should have to switch to the source directory on the command line:
Fork the [Gitea repository](https://github.com/go-gitea/gitea) on GitHub, it should
then be possible to switch the source directory on the command line.
```
cd $GOPATH/src/code.gitea.io/gitea
```
To be able to create pull requests you should add your forked repository as a remote to the Gitea sources, otherwise you can not apply the changes to our repository because of lacking write permissions:
To be able to create pull requests, the forked repository should be added as a remote
to the Gitea sources, otherwise changes can't be pushed.
```
git remote rename origin upstream
@ -37,6 +44,12 @@ git remote add origin git@github.com:<USERNAME>/gitea.git
git fetch --all --prune
```
You've got a working development environment for Gitea now. Take a look at the `Makefile` to get an overview about the available tasks. The most common tasks should be `make test` which will start our test environment and `make build` which will build a `gitea` binary into your working directory. Writing test cases is not mandatory to contribute, but we will be happy if you do.
This should provide a working development environment for Gitea. Take a look at
the `Makefile` to get an overview about the available tasks. The most common tasks
should be `make test` which will start our test environment and `make build` which
will build a `gitea` binary into the working directory. Writing test cases is not
mandatory to contribute, but it is highly encouraged and helps developers sleep
at night.
That’s it! You are ready to hack on Gitea. Test your changes, push them to your repository and open a pull request.
That's it! You are ready to hack on Gitea. Test changes, push them to the repository,
and open a pull request.

12
docs/content/doc/advanced/make.en-us.md
View file

@ -15,16 +15,17 @@ menu:
# Make
Gitea makes heavy use of Make to automate tasks and have a faster development. This guide cover how to install Make.
Gitea makes heavy use of Make to automate tasks and improve development. This
guide covers how to install Make.
### On Linux
You can install with your package manager.
Install with the package manager.
On Ubuntu/Debian:
```bash
sudo apt-get install build-essential
sudo apt-get install make
```
On Fedora/RHEL/CentOS:
@ -35,10 +36,11 @@ sudo yum install make
### On Windows
If you are using Windows, you can download and use one of these distributions of Make:
One of these three distributions of Make will run on Windows:
- [Single binary build](http://www.equation.com/servlet/equation.cmd?fa=make). Copy somewhere and add to `PATH`.
- [32-bits version](ftp://ftp.equation.com/make/32/make.exe)
- [64-bits version](ftp://ftp.equation.com/make/64/make.exe)
- [MinGW](http://www.mingw.org/) includes a build. The binary is called `mingw32-make.exe` instead of `make.exe`. Add the `bin` folder to your `PATH`.
- [MinGW](http://www.mingw.org/) includes a build.
- The binary is called `mingw32-make.exe` instead of `make.exe`. Add the `bin` folder to `PATH`.
- [Chocolatey package](https://chocolatey.org/packages/make). Run `choco install make`

0
docs/content/doc/advanced/make.fr-fr.md Executable file → Normal file
View file

30
docs/content/doc/advanced/specific-variables.en-us.md
View file

@ -25,43 +25,45 @@ GITEA_CUSTOM=/home/gitea/custom ./gitea web
## From Go language
As Gitea is written in Go, it uses some Go variables as:
As Gitea is written in Go, it uses some Go variables, such as:
* `GOOS`
* `GOARCH`
* `GOPATH`
* [`GOPATH`](https://golang.org/cmd/go/#hdr-GOPATH_environment_variable)
For `GOPATH`, check [official documentation about GOPATH environment variable](https://golang.org/cmd/go/#hdr-GOPATH_environment_variable).
For others, check [official documentation about variables used when it runs the generator](https://golang.org/cmd/go/#hdr-Generate_Go_files_by_processing_source).
For documentation about each of the variables available, refer to the
[official Go documentation](https://golang.org/cmd/go/#hdr-Environment_variables).
## Gitea files
* `GITEA_WORK_DIR`: Gitea absolute path of work directory.
* `GITEA_CUSTOM`: Gitea uses `GITEA_WORK_DIR`/custom folder by default. Use this variable to change *custom* directory.
* `GITEA_WORK_DIR`: Absolute path of working directory.
* `GITEA_CUSTOM`: Gitea uses `GITEA_WORK_DIR`/custom folder by default. Use this variable
to change *custom* directory.
* `GOGS_WORK_DIR`: Deprecated, use `GITEA_WORK_DIR`
* `GOGS_CUSTOM`: Deprecated, use `GITEA_CUSTOM`
## Operating system specifics
* `USER`: system user that launch Gitea. Useful for repository URL address on Gitea interface
* `USERNAME`: if no USER found, Gitea will try `USERNAME`
* `HOME`: User home directory path (**except if** you're running on Windows, check the following `USERPROFILE` variable)
* `USER`: System user that Gitea will run as. Used for some repository access strings.
* `USERNAME`: if no `USER` found, Gitea will use `USERNAME`
* `HOME`: User home directory path. The `USERPROFILE` environment variable is used in Windows.
### Only on Windows
* `USERPROFILE`: User home directory path. If empty, uses `HOMEDRIVE` + `HOMEPATH`
* `HOMEDRIVE`: Main drive path you will use to get home directory
* `HOMEDRIVE`: Main drive path used to access the home directory (C:)
* `HOMEPATH`: Home relative path in the given home drive path
## Macaron (framework used by Gitea)
* `HOST`: Host Macaron will listen on
* `PORT`: Port Macaron will listen on
* `MACARON_ENV`: global variable to provide special functionality for development environments vs production environments. If MACARON_ENV is set to "" or "development" then templates will be recompiled on every request. For more performance, set the MACARON_ENV environment variable to "production".
* `MACARON_ENV`: global variable to provide special functionality for development environments
vs. production environments. If MACARON_ENV is set to "" or "development" then templates will
be recompiled on every request. For more performance, set the MACARON_ENV environment variable
to "production".
## Miscellaneous
* `SKIP_MINWINSVC`: Do not run as a service on Windows if set to 1
* `SKIP_MINWINSVC`: If set to 1, do not run as a service on Windows.
* `ZOOKEEPER_PATH`: [Zookeeper](http://zookeeper.apache.org/) jar file path

37
docs/content/doc/features/authentication.en-us.md
View file

@ -78,7 +78,7 @@ Both the LDAP via BindDN and the simple auth LDAP share the following fields:
- Bind Password (optional)
- The password for the Bind DN specified above, if any. _Note: The password
is stored in plaintext at the server. As such, ensure that your Bind DN
is stored in plaintext at the server. As such, ensure that the Bind DN
has as few privileges as possible._
- User Search Base **(required)**
@ -110,7 +110,8 @@ Both the LDAP via BindDN and the simple auth LDAP share the following fields:
**LDAP using simple auth** adds the following fields:
- User DN **(required)**
- A template to use as the user's DN. The `%s` matching parameter will be substituted with login name given on sign-in form.
- A template to use as the user's DN. The `%s` matching parameter will be
substituted with login name given on sign-in form.
- Example: `cn=%s,ou=Users,dc=mydomain,dc=com`
- Example: `uid=%s,ou=Users,dc=mydomain,dc=com`
@ -141,18 +142,20 @@ Both the LDAP via BindDN and the simple auth LDAP share the following fields:
## PAM (Pluggable Authentication Module)
To configure this you just need to set the 'PAM Service Name' to a filename in `/etc/pam.d/`.
If you want it to work with normal Linux passwords, the user running Gitea must have read access to `/etc/shadow`.
To configure PAM, set the 'PAM Service Name' to a filename in `/etc/pam.d/`. To
work with normal Linux passwords, the user running Gitea must have read access
to `/etc/shadow`.
## SMTP (Simple Mail Transfer Protocol)
This option allows Gitea to log in to your SMTP host as a Gitea user. To configure this, simply set the fields below:
This option allows Gitea to log in to an SMTP host as a Gitea user. To
configure this, set the fields below:
- Authentication Name **(required)**
- A name to assign to the new method of authorization.
- SMTP Authentication Type **(required)**
- Type of authentication for use on your SMTP host, PLAIN or LOGIN.
- Type of authentication to use to connect to SMTP host, PLAIN or LOGIN.
- Host **(required)**
- The address where the SMTP host can be reached.
@ -163,7 +166,8 @@ This option allows Gitea to log in to your SMTP host as a Gitea user. To configu
- Example: `587`
- Allowed Domains
- Restrict what domains can log in if you're using public SMTP host or SMTP host with multiple domains.
- Restrict what domains can log in if using a public SMTP host or SMTP host
with multiple domains.
- Example: `gitea.io,mydomain.com,mydomain2.com`
- Enable TLS Encryption
@ -171,15 +175,17 @@ This option allows Gitea to log in to your SMTP host as a Gitea user. To configu
- Skip TLS Verify
- Disable TLS verify on authentication.
- This authentication is activate
- Enable or disable this auth.
## FreeIPA
- In order to log in to Gitea using FreeIPA credentials, you need to create a bind account for Gitea to use:
- In order to log in to Gitea using FreeIPA credentials,a bind account needs to
be created for Gitea:
- On the FreeIPA server, create a `gitea.ldif` file, replacing `dc=example,dc=com` with your DN, and providing an appropriately secure password:
- On the FreeIPA server, create a `gitea.ldif` file, replacing `dc=example,dc=com`
with your DN, and provide an appropriately secure password:
```
dn: uid=gitea,cn=sysaccounts,cn=etc,dc=example,dc=com
changetype: add
@ -191,15 +197,18 @@ This option allows Gitea to log in to your SMTP host as a Gitea user. To configu
nsIdleTimeout: 0
```
- Import the LDIF (change localhost to an IPA server if needed), you’ll be prompted for your Directory Manager password:
- Import the LDIF (change localhost to an IPA server if needed). A prompt for
Directory Manager password will be presented:
```
ldapmodify -h localhost -p 389 -x -D \
"cn=Directory Manager" -W -f gitea.ldif
```
- Add an IPA group for gitea_users :
- Add an IPA group for gitea\_users :
```
ipa group-add --desc="Gitea Users" gitea_users
```
- Note: If you get an error about IPA credentials, please run `kinit admin` and give your admin account password.
- Note: For errors about IPA credentials, run `kinit admin` and provide the
domain admin account password.
- Now login to the Gitea as an Administrator, click on "Authentication" under Admin Panel. Then click `Add New Source` and fill in the details, changing all where appropriate to your own domain.
- Log in to Gitea as an Administrator and click on "Authentication" under Admin Panel.
Then click `Add New Source` and fill in the details, changing all where appropriate.

7
docs/content/doc/features/webhooks.en-us.md
View file

@ -15,11 +15,14 @@ menu:
# Webhooks
Gitea supports web hooks for repository events, you can find it in settings page(`/:username/:reponame/settings/hooks`). All event pushes are POST requests, and we currently support two formats: Gitea and Slack.
Gitea supports web hooks for repository events, this can be found in the settings
page(`/:username/:reponame/settings/hooks`). All event pushes are POST requests.
The two methods currently supported are Gitea and Slack.
### Event information
Following shows an example of event information that will be sent by Gitea to Payload URL:
The following is an example of event information that will be sent by Gitea to
a Payload URL:
```

13
docs/content/doc/help.en-us.md Normal file
View file

@ -0,0 +1,13 @@
---
date: "2017-01-20T15:00:00+08:00"
title: "Help"
slug: "help"
weight: 50
toc: false
draft: false
menu:
sidebar:
name: "Help"
weight: 50
identifier: "help"
---

28
docs/content/doc/help/seek-help.en-us.md Normal file
View file

@ -0,0 +1,28 @@
---
date: "2017-01-20T15:00:00+08:00"
title: "Support Options"
slug: "seek-help"
weight: 10
toc: true
draft: false
menu:
sidebar:
parent: "help"
name: "Support Options"
weight: 20
identifier: "seek-help"
---
# Support Options
- [Discord](https://discord.gg/NsatcWJ)
- [#gitea on Freenode](http://webchat.freenode.net?nick=giteachat....&channels=%23gitea&prompt=1)
- [Matrix](https://matrix.to/#/#gitea-dev:matrix.org)
## Bugs
If you found a bug, please create an [issue on Github](https://github.com/go-gitea/gitea/issues).
## Chinese Support
Support for the Chinese language is provided at [gocn.io](https://gocn.io/topic/Gitea).

43
docs/content/doc/help/troubleshooting.en-us.md
View file

@ -7,7 +7,7 @@ toc: true
draft: false
menu:
sidebar:
parent: "Help"
parent: "help"
name: "Troubleshooting"
weight: 20
identifier: "troubleshooting"
@ -15,43 +15,41 @@ menu:
# Troubleshooting
This page contains some common issues you can run into and their solutions.
This page contains some common seen issues and their solutions.
## SSH issues
If you are having issues with reaching your repositories over `ssh` while the
Gitea web front-end and `https` based git operations work fine, consider
looking at the following items.
For issues reaching repositories over `ssh` while the gitea web front-end, but
`https` based git repository access works fine, consider looking into the following.
```
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
```
This error signifies that the server rejected your log in attempt, check the
This error signifies that the server rejected a log in attempt, check the
following things:
* On the client:
* Ensure the public and private ssh keys are added to the correct Gitea user.
* Make sure there are no issues in your remote url, ensure the name of the
* Make sure there are no issues in the remote url, ensure the name of the
git user (before the `@`) is spelled correctly.
* Ensure the public and private ssh keys are available and reachable on the
client machine.
* Try to `ssh git@myremote.example` to ensure that everything is set up
properly.
* Ensure public and private ssh keys are correct on client machine.
* Try to connect using ssh (ssh git@myremote.example) to ensure a connection
can be made.
* On the server:
* Check the permissions of the `.ssh` directory in the home directory of your
`git` user.
* Make sure the repository exists and is correctly named.
* Check the permissions of the `.ssh` directory in the system user's home directory.
* Verify that the correct public keys are added to `.ssh/authorized_keys`.
Try to run `Rewrite '.ssh/authorized_keys' file (for Gitea SSH keys)` on the
Gitea admin panel.
* Read gitea logs.
* Read /var/log/auth (or similar).
* Check permissions of repositories.
If you get a similar error without the public key part (shown below) then
authentication succeeded, but some other setting is preventing ssh from
reaching the correct repository.
The following is an example of a missing public SSH key where authentication
succeeded, but some other setting is preventing SSH from reaching the correct
repository.
```
fatal: Could not read from remote repository.
@ -63,7 +61,8 @@ and the repository exists.
In this case, look into the following settings:
* On the server:
* Make sure that your `git` user has a usable shell set. You can verify this
with `getent passwd git | cut -d: -f7`, `chsh` can be used to modify this.
* Make sure that the `git` system user has a usable shell set
* Verify this with `getent passwd git | cut -d: -f7`
* `usermod` or `chsh` can be used to modify this.
* Ensure that the `gitea serv` command in `.ssh/authorized_keys` uses the
proper configuration file.
correct configuration file.

0
docs/content/doc/installation.fr-fr.md Executable file → Normal file
View file

24
docs/content/doc/installation/from-binary.en-us.md
View file

@ -15,7 +15,10 @@ menu:
# Installation from binary
All downloads come with SQLite, MySQL and PostgreSQL support, and are built with embedded assets. Keep in mind that this can be different for older releases. The installation based on our binaries is quite simple, just choose the file matching your platform from the [downloads page](https://dl.gitea.io/gitea), copy the URL and replace the URL within the commands below:
All downloads come with SQLite, MySQL and PostgreSQL support, and are built with
embedded assets. This can be different for older releases. Choose the file matching
the destination platform from the [downloads page](https://dl.gitea.io/gitea), copy
the URL and replace the URL within the commands below:
```
wget -O gitea https://dl.gitea.io/gitea/1.3.2/gitea-1.3.2-linux-amd64
@ -24,7 +27,8 @@ chmod +x gitea
## Test
After following the steps above you will have a `gitea` binary within your working directory, first you can test it if it works like expected and afterwards you can copy it to the destination where you want to store it. When you launch Gitea manually from your CLI you can always kill it by hitting `Ctrl + C`.
After getting a binary, it can be tested with `./gitea web` or moved to a permanent
location. When launched manually, Gitea can be killed using `Ctrl+C`.
```
./gitea web
@ -34,12 +38,16 @@ After following the steps above you will have a `gitea` binary within your worki
### Old glibc versions
Older Linux distributions (such as Debian 7 and CentOS 6) may not be able to load the Gitea binary, usually resulting an error like ```./gitea: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./gitea)```. This is due to the integrated SQLite support in the binaries we provide. In the future, we will provide binaries without the requirement for glibc. As a workaround, you can upgrade your distribution or [install from source]({{< relref "from-source.en-us.md" >}}).
Older Linux distributions (such as Debian 7 and CentOS 6) may not be able to load the
Gitea binary, usually producing an error such as ```./gitea: /lib/x86_64-linux-gnu/libc.so.6:
version `GLIBC\_2.14' not found (required by ./gitea)```. This is due to the integrated
SQLite support in the binaries provided by dl.gitea.io. In this situation, it is usually
possible to [install from source]({{< relref "from-source.en-us.md" >}}) without sqlite
support.
### Running gitea on another port
If getting an error like `702 runWeb()] [E] Failed to start server: listen tcp 0.0.0.0:3000: bind: address already in use` gitea needs to be started on another free port. This is possible using `./gitea web -p $PORT`.
## Anything missing?
Are we missing anything on this page? Then feel free to reach out to us on our [Discord server](https://discord.gg/NsatcWJ), there you will get answers to any question pretty fast.
For errors like `702 runWeb()] [E] Failed to start server: listen tcp 0.0.0.0:3000:
bind: address already in use` gitea needs to be started on another free port. This
is possible using `./gitea web -p $PORT`. It's possible another instance of gitea
is already running.

0
docs/content/doc/installation/from-binary.fr-fr.md Executable file → Normal file
View file

36
docs/content/doc/installation/from-package.en-us.md
View file

@ -15,17 +15,30 @@ menu:
# Installation from package
## Linux
## Debian
We have not published any real package yet, we will update this page directly when we start to publish packages for any Linux distribution, in the meantime you should follow our [installation from binary]({{< relref "from-binary.en-us.md" >}}) guide.
The only distribution that has any "official" package of Gitea is Debian. This is currently
in Debian's [contrib](https://wiki.debian.org/SourcesList). This is (currently) only available
in Debian testing and unstable (but should be installable/functional on stable).
- Edit /etc/apt/sourced.list
- Add "contrib" to "deb http://deb.debian.org/debian unstable main contrib"
- apt-get update
- apt-get install gitea
For other distributions, see the [deployment from binary]({{< relref "from-binary.en-us.md" >}}) guide.
## Windows
We have not published any package for Windows yet, we will update this page directly when we start to publish packages in the form of `MSI` installers or via [Chocolatey](https://chocolatey.org/), in the meantime you should follow our [installation from binary]({{< relref "from-binary.en-us.md" >}}) guide.
There are no published packages for Windows. This page will change when packages are published,
in the form of `MSI` installers or via [Chocolatey](https://chocolatey.org/). In the meantime
the [deployment from binary]({{< relref "from-binary.en-us.md" >}}) guide.
## macOS
Currently we only support the installation via `brew` for macOS. If you are not using [Homebrew](http://brew.sh/) you should follow our [installation from binary]({{< relref "from-binary.en-us.md" >}}) guide. To install Gitea via `brew` you just need to execute the following commands:
Currently, the only supported method of installation on MacOS is [Homebrew](http://brew.sh/).
Following the [deployment from binary]({{< relref "from-binary.en-us.md" >}}) guide may work,
but is not supported. To install Gitea via `brew`:
```
brew tap go-gitea/gitea
@ -34,13 +47,14 @@ brew install gitea
## FreeBSD
A FreeBSD port `www/gitea` is available. You can install a pre-built binary package:
A FreeBSD port `www/gitea` is available. To install the pre-built binary package:
```
pkg install gitea
```
For the most up to date version, or to build the port with custom options, [install it from the port](https://www.freebsd.org/doc/handbook/ports-using.html):
For the most up to date version, or to build the port with custom options,
[install it from the port](https://www.freebsd.org/doc/handbook/ports-using.html):
```
su -
@ -48,10 +62,8 @@ cd /usr/ports/www/gitea
make install clean
```
The port uses the standard FreeBSD file system layout: config files are in `/usr/local/etc/gitea`, bundled templates, options, plugins and themes are in `/usr/local/share/gitea`, and a start script is in `/usr/local/etc/rc.d/gitea`.
The port uses the standard FreeBSD file system layout: config files are in `/usr/local/etc/gitea`,
bundled templates, options, plugins and themes are in `/usr/local/share/gitea`, and a start script
is in `/usr/local/etc/rc.d/gitea`.
To enable Gitea to run as a service, run `sysrc gitea_enable=YES` and start it with `service gitea start`.
## Anything missing?
Are we missing anything on this page? Then feel free to reach out to us on our [Discord server](https://discord.gg/NsatcWJ), there you will get answers to any question pretty fast.
To enable Gitea to run as a service, run `sysrc gitea_enable=YES` and start it with `service gitea start`.

0
docs/content/doc/installation/from-package.fr-fr.md Executable file → Normal file
View file

52
docs/content/doc/installation/from-source.en-us.md
View file

@ -15,52 +15,66 @@ menu:
# Installation from source
We won't cover the basics of a Golang setup within this guide. If you don't know how to get the environment up and running you should follow the official [install instructions](https://golang.org/doc/install).
This section will not include basic [installation instructions](https://golang.org/doc/install).
**Note**: Go version 1.7 or higher is required
## Download
First of all you have to retrieve the source code, the easiest way is to simply use directly Go for that. Just call the following commands to fetch the source and to switch into the working directory.
First retrieve the source code. The easiest way is to use the Go tool. Use the following
commands to fetch the source and switch into the source directory.
```
go get -d -u code.gitea.io/gitea
cd $GOPATH/src/code.gitea.io/gitea
```
Now it's time to decide which version of Gitea you want to build and install. Currently there are multiple options you can choose from. If you want to build our `master` branch you can directly go ahead to the [build section](#build), this branch represents our current development version and this is not intended for production use.
If you want to build the latest stable version that acts as a development branch for the tagged releases you can see the available branches and how to checkout this branch with these commands:
Decide which version of Gitea to build and install. Currently, there are multiple options
to choose from. The `master` branch represents the current development version. To build
with master, skip to the [build section](#build).
To work with tagged releases, the following commands can be used:
```
git branch -a
git checkout v1.0
```
If you would validate a Pull Request, first your must enable this new branch : (`xyz` is the PR id, for example `2663` for [#2663](https://github.com/go-gitea/gitea/pull/2663))
To validate a Pull Request, first enable the new branch (`xyz` is the PR id; for example
`2663` for [#2663](https://github.com/go-gitea/gitea/pull/2663)):
```
git fetch origin pull/xyz/head:pr-xyz
```
Last but not least you can also directly build our tagged versions like `v1.0.0`, if you want to build Gitea from the source this is the suggested way for that. To use the tags you need to list the available tags and checkout a specific tag with the following commands:
To build Gitea from source at a specific tagged release (like v1.0.0), list the available
tags and check out the specific tag.
List available tags with the following.
```
git tag -l
git checkout v1.0.0
git checkout pr-xyz
git checkout v1.0.0 # or git checkout pr-xyz
```
## Build
Since we already bundle all required libraries to build Gitea you can continue with the build process itself. We provide various [make tasks](https://github.com/go-gitea/gitea/blob/master/Makefile) to keep the build process as simple as possible. <a href='{{< relref "doc/advanced/make.en-us.md" >}}'>See here how to get Make</a>. Depending on your requirements you possibly want to add various build tags, you can choose between these tags:
Since all required libraries are already bundled in the Gitea source, it's
possible to build Gitea with no additional downloads. Various
[make tasks](https://github.com/go-gitea/gitea/blob/master/Makefile) are
provided to keep the build process as simple as possible.
<a href='{{< relref "doc/advanced/make.en-us.md" >}}'>See here how to get Make</a>.
Depending on requirements, the following build tags can be included.
* `bindata`: With this tag you can embed all assets required to run an instance of Gitea, this makes a deployment quite easy because you don't need to care about any additional file.
* `sqlite`: With this tag you can enable support for a [SQLite3](https://sqlite.org/) database, this is only suggested for tiny Gitea installations.
* `tidb`: With this tag you can enable support for a [TiDB](https://github.com/pingcap/tidb) database, it's a quite simple file-based database comparable with SQLite.
* `pam`: With this tag you can enable support for PAM (Linux Pluggable Authentication Modules), this is useful if your users should be authenticated via your available system users.
* `bindata`: Build a single monolithic binary, with all assets included.
* `sqlite`: Enable support for a [SQLite3](https://sqlite.org/) database. Suggested only
for tiny installations.
* `tidb`: Enable support for a [TiDB](https://github.com/pingcap/tidb) database.
* `pam`: Enable support for PAM (Linux Pluggable Authentication Modules). Can be used to
authenticate local users or extend authentication to methods available to PAM.
Now it's time to build the binary, we suggest to embed the assets with the `bindata` build tag, to include the assets you also have to execute the `generate` make task, otherwise the assets are not prepared to get embedded:
Bundling assets into the binary using the `bindata` build tag can make development and
testing easier, but is not ideal for a production deployment. To include assets, they
must be built separately using the `generate` make task.
```
TAGS="bindata" make generate build
@ -68,12 +82,10 @@ TAGS="bindata" make generate build
## Test
After following the steps above you will have a `gitea` binary within your working directory, first you can test it if it works like expected and afterwards you can copy it to the destination where you want to store it. When you launch Gitea manually from your CLI you can always kill it by hitting `Ctrl + C`.
After following the steps above a `gitea` binary will be available in the working directory.
It can be tested from this directory or moved to a directory with test data. When Gitea is
launched manually from command line, it can be killed by pressing `Ctrl + C`.
```
./gitea web
```
## Anything missing?
Are we missing anything on this page? Then feel free to reach out to us on our [Discord server](https://discord.gg/NsatcWJ), there you will get answers to any question pretty fast.

0
docs/content/doc/installation/from-source.fr-fr.md Executable file → Normal file
View file

69
docs/content/doc/installation/run-as-service-in-ubuntu.en-us.md
View file

@ -13,56 +13,55 @@ menu:
identifier: "linux-service"
---
### Run as service in Ubuntu 16.04 LTS
#### Using systemd
### Run as service in Ubuntu 16.04 LTS
Run below command in terminal:
#### Using systemd
Run the below command in a terminal:
```
sudo vim /etc/systemd/system/gitea.service
```
Add code to the file from [here](https://github.com/go-gitea/gitea/blob/master/contrib/systemd/gitea.service).
Uncomment any service need to be enabled like mysql in this case in Unit section.
Change the user(git) accordingly to yours. And /home/git too if your username is different than git. Change the PORT or remove the -p flag if default port is used.
Lastly start and enable gitea at boot:
```
sudo systemctl start gitea
```
Copy the sample [gitea.service](https://github.com/go-gitea/gitea/blob/master/contrib/systemd/gitea.service).
Uncomment any service that needs to be enabled on this host, such as MySQL.
Change the user, home directory, and other required startup values. Change the
PORT or remove the -p flag if default port is used.
Enable and start gitea at boot:
```
sudo systemctl enable gitea
```
sudo systemctl start gitea
```
#### Using supervisor
#### Using supervisor
Install supervisor by running below command in terminal:
Install supervisor by running below command in terminal:
```
sudo apt install supervisor
```
Create a log dir for the supervisor logs(assuming gitea is installed in /home/git/gitea/):
```
mkdir /home/git/gitea/log/supervisor
```
Open supervisor config file in vi/vim/nano etc.
Create a log dir for the supervisor logs:
```
# assuming gitea is installed in /home/git/gitea/
mkdir /home/git/gitea/log/supervisor
```
Open supervisor config file in a file editor:
```
sudo vim /etc/supervisor/supervisord.conf
```
And append the code at the end of the file from [here](https://github.com/go-gitea/gitea/blob/master/contrib/supervisor/gitea).
Change the user(git) accordingly to yours. And /home/git too if your username is different than git. Change the PORT or remove the -p flag if default port is used.
Lastly start and enable supervisor at boot:
```
sudo systemctl start supervisor
```
Append the configuration from the sample
[supervisord config](https://github.com/go-gitea/gitea/blob/master/contrib/supervisor/gitea).
Change the user(git) and home(/home/git) settings to match the deployment
environment. Change the PORT or remove the -p flag if default port is used.
Lastly enable and start supervisor at boot:
```
sudo systemctl enable supervisor
```
sudo systemctl start supervisor
```

11
docs/content/doc/installation/windows-service.en-us.md
View file

@ -15,19 +15,22 @@ menu:
# Register as a Windows Service
To register Gitea as a Windows service, first run `cmd` as an Administrator, and then run the following command:
To register Gitea as a Windows service, open a command prompt (cmd) as an Administrator,
then run the following command:
```
sc create gitea start= auto binPath= ""C:\gitea\gitea.exe" web --config "C:\gitea\custom\conf\app.ini""
```
Do not forget to replace `C:\gitea` with your real Gitea folder.
Do not forget to replace `C:\gitea` with the correct Gitea directory.
After, open "Windows Services", search for the service named "gitea", right-click it and click on "Run". If everything is OK you should be able to reach Gitea on `http://localhost:3000` (or the port is was configured, if different than 3000).
Open "Windows Services", search for the service named "gitea", right-click it and click on
"Run". If everything is OK Gitea will be reachable on `http://localhost:3000` (or the port
that was configured).
## Unregister as a service
To unregister Gitea as a service, open `cmd` as an Administrator and run:
To unregister Gitea as a service, open a command prompt (cmd) as an Administrator and run:
```
sc delete gitea

0
docs/content/doc/installation/windows-service.fr-fr.md Executable file → Normal file
View file

53
docs/content/doc/installation/with-docker.en-us.md
View file

@ -15,13 +15,19 @@ menu:
# Installation with Docker
We provide automatically updated Docker images within our Docker Hub organization. It is up to you and your deployment to always use the latest stable tag or to use another service that updates the Docker image for you.
Gitea provides automatically updated Docker images within its Docker Hub organization. It is
possible to always use the latest stable tag or to use another service that handles updating
Docker images.
This reference setup guides you through the setup based on `docker-compose`, the installation of `docker-compose` is out of scope of this documentation. To install `docker-compose` follow the official [install instructions](https://docs.docker.com/compose/install/).
This reference setup guides users through the setup based on `docker-compose`, the installation
of `docker-compose` is out of scope of this documentation. To install `docker-compose` follow
the official [install instructions](https://docs.docker.com/compose/install/).
## Basics
The most simple setup just creates a volume and a network and starts the `gitea/gitea:latest` image as a service. Since there is no database available you can start it only with SQLite3. Create a directory like `gitea` and paste the following content into a file named `docker-compose.yml`.
The most simple setup just creates a volume and a network and starts the `gitea/gitea:latest`
image as a service. Since there is no database available one can be initialized using SQLite3.
Create a directory like `gitea` and paste the following content into a file named `docker-compose.yml`.
```yaml
version: "2"
@ -45,7 +51,9 @@ services:
## Custom port
To bind the integrated openSSH daemon and the webserver on a different port, you just need to adjust the port section. It's common to just change the host port and keep the ports within the container like they are.
To bind the integrated openSSH daemon and the webserver on a different port, adjust
the port section. It's common to just change the host port and keep the ports within
the container like they are.
```diff
version: "2"
@ -71,7 +79,8 @@ services:
## MySQL database
To start Gitea in combination with a MySQL database you should apply these changes to the `docker-compose.yml` file created above.
To start Gitea in combination with a MySQL database, apply these changes to the
`docker-compose.yml` file created above.
```diff
version: "2"
@ -110,7 +119,8 @@ services:
## PostgreSQL database
To start Gitea in combination with a PostgreSQL database you should apply these changes to the `docker-compose.yml` file created above.
To start Gitea in combination with a PostgreSQL database, apply these changes to
the `docker-compose.yml` file created above.
```diff
version: "2"
@ -148,7 +158,9 @@ services:
## Named volumes
To use named volumes instead of host volumes you just have to define and use the named volume within the `docker-compose.yml` configuration. This change will automatically create the required volume.
To use named volumes instead of host volumes, define and use the named volume
within the `docker-compose.yml` configuration. This change will automatically
create the required volume.
```diff
version: "2"
@ -175,24 +187,31 @@ services:
- "222:22"
```
If you are using MySQL or PostgreSQL it's up to you to create named volumes for these containers as well.
MySQL or PostgreSQL containers will need to be created separately.
## Start
To start this setup based on `docker-compose` you just have to execute `docker-compose up -d` to launch Gitea in the background. You can see if it started properly via `docker-compose ps`, and you can tail the log output via `docker-compose logs`.
To start this setup based on `docker-compose`, execute `docker-compose up -d`,
to launch Gitea in the background. Using `docker-compose ps` will show if Gitea
started properly. Logs can be viewed with `docker-compose logs`.
If you want to shutdown the setup again just execute `docker-compose down`, this will stop and kill the containers, the volumes will still exist.
To shut down the setup, execute `docker-compose down`. This will stop
and kill the containers. The volumes will still exist.
Notice: if you use a non 3000 port on http, you need change app.ini `LOCAL_ROOT_URL = http://localhost:3000/`.
Notice: if using a non-3000 port on http, change app.ini to match
`LOCAL_ROOT_URL = http://localhost:3000/`.
## Install
After starting the Docker setup via `docker-compose` you should access Gitea with your favorite browser to finalize the installation. Please visit http://server-ip:3000 and follow the installation wizard. If you have started a database with the `docker-compose` setup as documented above please note that you have to use `db` as the database hostname.
After starting the Docker setup via `docker-compose` Gitea should be available using a
favorite browser to finalize the installation. Visit http://server-ip:3000 and follow the
installation wizard. If the database was started with the `docker-compose` setup as
documented above please note that `db` must be used as the database hostname.
# Customization
Customization files described [here](https://docs.gitea.io/en-us/customizing-gitea/) should be placed in `/data/gitea` directory. If you are using host volumes it's quite easy to access these files, for named volumes you have to do it through another container or you should directly access `/var/lib/docker/volumes/gitea_gitea/_data`. The configuration file will be saved at `/data/gitea/conf/app.ini` after the installation.
# Anything missing?
Are we missing anything on this page? Then feel free to reach out to us on our [Discord server](https://discord.gg/NsatcWJ), there you will get answers to any question pretty fast.
Customization files described [here](https://docs.gitea.io/en-us/customizing-gitea/) should
be placed in `/data/gitea` directory. If using host volumes it's quite easy to access these
files; for named volumes this is done through another container or by direct access at
`/var/lib/docker/volumes/gitea_gitea/_data`. The configuration file will be saved at
`/data/gitea/conf/app.ini` after the installation.

0
docs/content/doc/installation/with-docker.fr-fr.md Executable file → Normal file
View file

0
docs/content/doc/upgrade.fr-fr.md Executable file → Normal file
View file

30
docs/content/doc/upgrade/from-gogs.en-us.md
View file

@ -15,25 +15,28 @@ menu:
# Upgrade from Gogs
Gogs versions up to 0.9.146 (db schema version 15) can be smoothly upgraded to Gitea.
Gogs, version 0.9.146 and older, can be easily migrated to Gitea.
There are some steps to do so below. On Unix run as your Gogs user:
There are some basic steps to follow. On a Linux system run as the Gogs user:
* Create a Gogs backup with `gogs dump`. This creates `gogs-dump-[timestamp].zip` file containing all your Gogs data.
* Download the file matching your platform from the [downloads page](https://dl.gitea.io/gitea).
* Create a Gogs backup with `gogs dump`. This creates `gogs-dump-[timestamp].zip` file
containing all important Gogs data.
* Download the file matching the destination platform from the [downloads page](https://dl.gitea.io/gitea).
* Put the binary at the desired install location.
* Copy `gogs/custom/conf/app.ini` to `gitea/custom/conf/app.ini`.
* If you have custom `templates, public` in `gogs/custom/` copy them to `gitea/custom/`.
* If you have any other custom folders like `gitignore, label, license, locale, readme` in `gogs/custom/conf` copy them to `gitea/custom/options`.
* Copy custom `templates, public` from `gogs/custom/` to `gitea/custom/`.
* For any other custom folders, such as `gitignore, label, license, locale, readme` in
`gogs/custom/conf`, copy them to `gitea/custom/options`.
* Copy `gogs/data/` to `gitea/data/`. It contains issue attachments and avatars.
* Verify by starting Gitea with `gitea web`.
* Enter Gitea admin panel on the UI, run `Rewrite '.ssh/authorized_keys' file`, then run `Rewrite all update hook of repositories` (needed when custom config path is changed).
* Enter Gitea admin panel on the UI, run `Rewrite '.ssh/authorized_keys' file`.
* If custom or config path was changed, run `Rewrite all update hook of repositories`.
### Change gogs specific information:
* Rename `gogs-repositories/` to `gitea-repositories/`
* Rename `gogs-data/` to `gitea-data/`
* In your `gitea/custom/conf/app.ini` change:
* In `gitea/custom/conf/app.ini` change:
FROM:
```
@ -63,19 +66,22 @@ ROOT_PATH = /home/:USER/gitea/log
### Troubleshooting
* If you encounter errors relating to custom templates in the `gitea/custom/templates` folder, try moving the templates causing the errors away one by one. They may not be compatible with Gitea.
* If errors are encountered relating to custom templates in the `gitea/custom/templates`
folder, try moving the templates causing the errors away one by one. They may not be
compatible with Gitea or an update.
### Add Gitea to startup on Unix
Update the appropriate file from [gitea/contrib](https://github.com/go-gitea/gitea/tree/master/contrib) with the right environment variables.
Update the appropriate file from [gitea/contrib](https://github.com/go-gitea/gitea/tree/master/contrib)
with the right environment variables.
For distro's with systemd:
For distros with systemd:
* Copy the updated script to `/etc/systemd/system/gitea.service`
* Add the service to the startup with: `sudo systemctl enable gitea`
* Disable old gogs startup script: `sudo systemctl disable gogs`
For distro's with SysVinit:
For distros with SysVinit:
* Copy the updated script to `/etc/init.d/gitea`
* Add the service to the startup with: `sudo rc-update add gitea`

0
docs/content/doc/upgrade/from-gogs.fr-fr.md Executable file → Normal file
View file

38
docs/content/doc/usage/backup-and-restore.en-us.md
View file

@ -15,11 +15,13 @@ menu:
# Backup and Restore
Gitea currently has a `dump` command that will save your installation to a zip file. There will be a `restore` command implemented at some point in the future. You will be able to use this to back up your installation, as well as make migrating servers easier.
Gitea currently has a `dump` command that will save the installation to a zip file. This
file can be unpacked and used to restore an instance.
## Backup Command (`dump`)
First, switch to the user running gitea: `su git` (or whatever user you are using). Run `./gitea dump` in the gitea installation directory. You should see some output similar to this:
Switch to the user running gitea: `su git`. Run `./gitea dump` in the gitea installation
directory. There should be some output similar to the following:
```
2016/12/27 22:32:09 Creating tmp work dir: /tmp/gitea-dump-417443001
@ -30,17 +32,31 @@ First, switch to the user running gitea: `su git` (or whatever user you are usin
2016/12/27 22:32:34 Finish dumping in file gitea-dump-1482906742.zip
```
Inside the `gitea-dump-1482906742.zip` file, you will find the following:
Inside the `gitea-dump-1482906742.zip` file, will be the following:
* `custom/conf/app.ini` - This is your server config.
* `gitea-db.sql` - SQL dump of your database.
* `gitea-repo.zip` - This zip will be a complete copy of your repo folder.
See Config -> repository -> `ROOT` for the location.
* `log/` - this will contain various logs. You don't need these if you are doing
a migration.
* `custom/conf/app.ini` - Server config.
* `gitea-db.sql` - SQL dump of database
* `gitea-repo.zip` - Complete copy of the repository directory.
* `log/` - Various logs. They are not needed for a recovery or migration.
Intermediate backup files are created in a temporary directory specified either with the `--tempdir` command-line parameter or the `TMPDIR` environment variable.
Intermediate backup files are created in a temporary directory specified either with the
`--tempdir` command-line parameter or the `TMPDIR` environment variable.
## Restore Command (`restore`)
WIP: Does not exist yet.
There is currently no support for a recovery command. It is a manual process that mostly
involves moving files to their correct locations and restoring a database dump.
Example:
```
apt-get install gitea
unzip gitea-dump-1482906742.zip
cd gitea-dump-1482906742
mv custom/conf/app.ini /etc/gitea/conf/app.ini
unzip gitea-repo.zip
mv gitea-repo/* /var/lib/gitea/repositories/
chown -R gitea:gitea /etc/gitea/conf/app.ini /var/lib/gitea/repositories/
mysql -u$USER -p$PASS $DATABASE <gitea-db.sql
# or sqlite3 $DATABASE_PATH <gitea-db.sql
service gitea restart
```

39
docs/content/doc/usage/command-line.md
View file

@ -20,13 +20,17 @@ menu:
`gitea [global options] command [command options] [arguments...]`
### Global options
- `--help`, `-h`: Show help text and exit. Optional. This can be used with any of the subcommands to see help text for it.
- `--version`, `-v`: Show version and exit. Optional. (example: `Gitea version 1.1.0+218-g7b907ed built with: bindata, sqlite`).
- `--help`, `-h`: Show help text and exit. Optional. This can be used with any of the
subcommands to see help text for it.
- `--version`, `-v`: Show version and exit. Optional. (example: `Gitea version
1.1.0+218-g7b907ed built with: bindata, sqlite`).
### Commands
#### web
Starts the server
Starts the server:
- Options:
- `--port number`, `-p number`: Port number. Optional. (default: 3000). Overrides configuration file.
- `--config path`, `-c path`: Gitea configuration file path. Optional. (default: custom/conf/app.ini).
@ -36,10 +40,14 @@ Starts the server
- `gitea web --port 80`
- `gitea web --config /etc/gitea.ini --pid /var/run/gitea.pid`
- Notes:
- Gitea should not be run as root. To bind to a port below 1000, you can use setcap on Linux: `sudo setcap 'cap_net_bind_service=+ep' /path/to/gitea`. This will need to be redone every time you update Gitea.
- Gitea should not be run as root. To bind to a port below 1000, you can use setcap on
Linux: `sudo setcap 'cap_net_bind_service=+ep' /path/to/gitea`. This will need to be
redone every time you update Gitea.
#### admin
Admin operations
Admin operations:
- Commands:
- `create-user`
- Options:
@ -51,18 +59,24 @@ Admin operations
- Examples:
- `gitea admin create-user --name myname --password asecurepassword --email me@example.com`
- `change-password`
- Arguments:
- Options:
- `--username value`, `-u value`: Username. Required.
- `--password value`, `-p value`: New password. Required.
- Examples:
- `gitea admin change-password --username myname --password asecurepassword`
#### cert
Generates a self-signed SSL certificate. Outputs to `cert.pem` and `key.pem` in the current directory and will overwrite any existing files.
Generates a self-signed SSL certificate. Outputs to `cert.pem` and `key.pem` in the current
directory and will overwrite any existing files.
- Options:
- `--host value`: Comma seperated hostnames and ips which this certificate is valid for. Wildcards are supported. Required.
- `--ecdsa-curve value`: ECDSA curve to use to generate a key. Optional. Valid options are P224, P256, P384, P521.
- `--rsa-bits value`: Size of RSA key to generate. Optional. Ignored if --ecdsa-curve is set. (default: 2048).
- `--host value`: Comma seperated hostnames and ips which this certificate is valid for.
Wildcards are supported. Required.
- `--ecdsa-curve value`: ECDSA curve to use to generate a key. Optional. Valid options
are P224, P256, P384, P521.
- `--rsa-bits value`: Size of RSA key to generate. Optional. Ignored if --ecdsa-curve is
set. (default: 2048).
- `--start-date value`: Creation date. Optional. (format: `Jan 1 15:04:05 2011`).
- `--duration value`: Duration which the certificate is valid for. Optional. (default: 8760h0m0s)
- `--ca`: If provided, this cert generates it's own certificate authority. Optional.
@ -70,7 +84,10 @@ Generates a self-signed SSL certificate. Outputs to `cert.pem` and `key.pem` in
- `gitea cert --host git.example.com,example.com,www.example.com --ca`
#### dump
Dumps all files and databases into a zip file. Outputs into a file like `gitea-dump-1482906742.zip` in the current directory.
Dumps all files and databases into a zip file. Outputs into a file like `gitea-dump-1482906742.zip`
in the current directory.
- Options:
- `--config path`, `-c path`: Gitea configuration file path. Optional. (default: custom/conf/app.ini).
- `--tempdir path`, `-t path`: Path to the temporary directory used. Optional. (default: /tmp).

23
docs/content/page/index.en-us.md
View file

@ -9,11 +9,16 @@ draft: false
# What is Gitea?
Gitea is a painless self-hosted Git service. It is similar to GitHub, Bitbucket or Gitlab. The initial development have been done on [Gogs](http://gogs.io) but we have forked it and named it Gitea. If you want to read more about the reasons why we have done that please read [this](https://blog.gitea.io/2016/12/welcome-to-gitea/) blog post.
Gitea is a painless self-hosted Git service. It is similar to GitHub, Bitbucket, and Gitlab.
Gitea is a fork of [Gogs](http://gogs.io). See the [Gitea Announcement](https://blog.gitea.io/2016/12/welcome-to-gitea/)
blog post to read about the justification for a fork.
## Purpose
The goal of this project is to make the easiest, fastest, and most painless way of setting up a self-hosted Git service. With Go, this can be done with an independent binary distribution across ALL platforms that Go supports, including Linux, macOS and Windows, even on architectures like ARM or PowerPC.
The goal of this project is to provide the easiest, fastest, and most painless way of setting
up a self-hosted Git service. With Go, this can be done with an independent binary distribution
across all platforms and architectures that Go supports. This support includes Linux, macOS, and
Windows, on architectures like amd64, i386, ARM, PowerPC, and others.
## Features
@ -25,7 +30,7 @@ The goal of this project is to make the easiest, fastest, and most painless way
- Pull requests
- Repository creation
- Searchable repository list
- List of your organizations
- List of organizations
- A list of mirror repositories
- Issues dashboard
- Context switcher (organization or current user)
@ -67,9 +72,9 @@ The goal of this project is to make the easiest, fastest, and most painless way
- PostgreSQL
- SQLite3
- MSSQL
- [TiDB](https://github.com/pingcap/tidb) (experimental)
- TiDB (experimental, not recommended)
- Configuration file
- See [here](https://github.com/go-gitea/gitea/blob/master/conf/app.ini)
- [app.ini](https://github.com/go-gitea/gitea/blob/master/conf/app.ini)
- Admin panel
- Statistics
- Actions
@ -245,14 +250,14 @@ The goal of this project is to make the easiest, fastest, and most painless way
## System Requirements
- A cheap Raspberry Pi is powerful enough for basic functionality.
- 2 CPU cores and 1GB RAM would be the baseline for teamwork.
- Gitea is supposed to be run with a dedicated non-root user account on UNIX systems, no other mode of operation is supported. (**NOTE**: in case you run it with your own user account and the built-in SSH server disabled, Gitea modifies the `~/.ssh/authorized_keys` file so you will **not** be able to interactively log in.)
- A Raspberry Pi 3 is powerful enough to run Gitea for small workloads.
- 2 CPU cores and 1GB RAM is typically sufficient for small teams/projects.
- Gitea should be run with a dedicated non-root system account on UNIX-type systems.
- Note: Gitea manages the `~/.ssh/authorized_keys` file. Running gitea as a regular user could break that user's ability to log in.
## Browser Support
- Please see [Semantic UI](https://github.com/Semantic-Org/Semantic-UI#browser-support) for specific versions of supported browsers.
- The official support minimal size is **1024*768**, UI may still looks right in smaller size but no promises and fixes.
## Components