Gitea Formula

Manage Gitea with Salt.

Table of Contents

General notes

See the full SaltStack Formulas installation and usage instructions.

If you are interested in writing or contributing to formulas, please pay attention to the Writing Formula Section.

If you want to use this formula, please pay attention to the FORMULA file and/or git tag, which contains the currently released version. This formula is versioned according to Semantic Versioning.

See Formula Versioning Section for more details.

If you need (non-default) configuration, please refer to:

• how to configure the formula with map.jinja
• the pillar.example file
• the Special notes section

Special notes

• This installs from the official binary source.
• The formula is currently Linux/systemd-centric. It should be relatively easy to provide the correct parameters and service file for other platforms though.
• Since the formula skips the web installer, you will need to provide at least the database configuration.
• You can optionally specify the secrets, but they can be autogenerated by Salt as well. In that case, they will be saved in a separate file inside your config dir.
• All the paths are modifiable, find them in lookup:paths. You should not need to set the corresponding values in your config, they are added automatically.
• If Gitea requires mounts for some of the paths, you can specify them in service:requires_mount as a list.
• If Gitea requires a local service unit (e.g. Redis server), specify it/them in service:wants as a list. This formula will do its best to automatically add a locally running database service to this list.

RST mod

This formula provides basic support for installing an external rst renderer. This especially makes Gitea display README.rst files similar to as it does for README.md.

The installation is not included by default, you will have to specifically target gitea.mods.rst to the minion. Furthermore, you will have to setup the external renderer in your app.ini similar to:

markup.restructuredtext:
  enabled: true
  file_extensions: '.rst'
  render_command: timeout 30s /usr/local/bin/grst
  is_input_file: true
markup.sanitizer.restructuredtext:
  element: pre
  allow_attr: class
  regexp: ''

The mod compiles chroma (the syntax highlighting library that is used by Gitea) from source and installs a Python script that renders RST files, which currently relies on chroma and the docutils python package. The parameters can be modified in gitea:lookup:mod_rst. I currently use this to patch *.sls, *.jinja and *.j2 highlighting into chroma.

Configuration

An example pillar is provided, please see pillar.example. Note that you do not need to specify everything by pillar. Often, it's much easier and less resource-heavy to use the parameters/<grain>/<value>.yaml files for non-sensitive settings. The underlying logic is explained in map.jinja.

Available states

The following states are found in this formula:

gitea

Meta-state.

This installs Gitea, manages its configuration and then starts the gitea service.

gitea.package

Installs Gitea only.

Releases are downloaded from the official server by default and their signatures verified.

gitea.config

Manages Gitea configuration. Has a dependency on gitea.package.

gitea.service

Starts the Gitea service and enables it at boot time. Has a dependency on gitea.config.

gitea.go

Creates a build user and downloads Go. Required for building Chroma.

gitea.mods.rst

Compiles Chroma from source and installs a Python script that can be setup as an external renderer for *.rst files.

Has a dependency on gitea.go.

gitea.clean

Meta-state.

Undoes everything performed in the gitea meta-state in reverse order, i.e. stops the service, removes the configuration file and then uninstalls the package. Some paths are left to avoid accidental data loss (namely GITEA_WORKDIR, APP_DATA_PATH and the gitea user home).

gitea.package.clean

Removes Gitea. Has a dependency on gitea.config.clean.

gitea.config.clean

Removes Gitea configuration. Has a dependency on gitea.service.clean.

gitea.service.clean

Stops the gitea service and disables it at boot time.

gitea.go.clean

Removes the build user and Go installation.

gitea.mods.rst.clean

Removes the built chroma binary, the build path and the grst script.

Contributing to this repo

Commit messages

Commit message formatting is significant!

Please see How to contribute for more details.

pre-commit

pre-commit is configured for this formula, which you may optionally use to ease the steps involved in submitting your changes. First install the pre-commit package manager using the appropriate method, then run bin/install-hooks and now pre-commit will run automatically on each git commit. :

$ bin/install-hooks
pre-commit installed at .git/hooks/pre-commit
pre-commit installed at .git/hooks/commit-msg

State documentation

There is a script that semi-autodocuments available states: bin/slsdoc.

If a .sls file begins with a Jinja comment, it will dump that into the docs. It can be configured differently depending on the formula. See the script source code for details currently.

This means if you feel a state should be documented, make sure to write a comment explaining it.

Testing

Linux testing is done with kitchen-salt.

Requirements

• Ruby
• Docker

$ gem install bundler
$ bundle install
$ bin/kitchen test [platform]

Where [platform] is the platform name defined in kitchen.yml, e.g. debian-9-2019-2-py3.

bin/kitchen converge

Creates the docker instance and runs the gitea main state, ready for testing.

bin/kitchen verify

Runs the inspec tests on the actual instance.

bin/kitchen destroy

Removes the docker instance.

bin/kitchen test

Runs all of the stages above in one go: i.e. destroy + converge + verify + destroy.

bin/kitchen login

Gives you SSH access to the instance for manual testing.