uboot: (firmwareOdroidC2/C4) don't invoke patch tool, use patches = [] instead
https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L948 this can do it nicely. Signed-off-by: Anton Arapov <anton@deadbeef.mx>
This commit is contained in:
commit
56de2bcd43
30691 changed files with 3076956 additions and 0 deletions
151
nixos/modules/services/misc/gitlab.xml
Normal file
151
nixos/modules/services/misc/gitlab.xml
Normal file
|
|
@ -0,0 +1,151 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="module-services-gitlab">
|
||||
<title>GitLab</title>
|
||||
<para>
|
||||
GitLab is a feature-rich git hosting service.
|
||||
</para>
|
||||
<section xml:id="module-services-gitlab-prerequisites">
|
||||
<title>Prerequisites</title>
|
||||
|
||||
<para>
|
||||
The <literal>gitlab</literal> service exposes only an Unix socket at
|
||||
<literal>/run/gitlab/gitlab-workhorse.socket</literal>. You need to
|
||||
configure a webserver to proxy HTTP requests to the socket.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For instance, the following configuration could be used to use nginx as
|
||||
frontend proxy:
|
||||
<programlisting>
|
||||
<link linkend="opt-services.nginx.enable">services.nginx</link> = {
|
||||
<link linkend="opt-services.nginx.enable">enable</link> = true;
|
||||
<link linkend="opt-services.nginx.recommendedGzipSettings">recommendedGzipSettings</link> = true;
|
||||
<link linkend="opt-services.nginx.recommendedOptimisation">recommendedOptimisation</link> = true;
|
||||
<link linkend="opt-services.nginx.recommendedProxySettings">recommendedProxySettings</link> = true;
|
||||
<link linkend="opt-services.nginx.recommendedTlsSettings">recommendedTlsSettings</link> = true;
|
||||
<link linkend="opt-services.nginx.virtualHosts">virtualHosts</link>."git.example.com" = {
|
||||
<link linkend="opt-services.nginx.virtualHosts._name_.enableACME">enableACME</link> = true;
|
||||
<link linkend="opt-services.nginx.virtualHosts._name_.forceSSL">forceSSL</link> = true;
|
||||
<link linkend="opt-services.nginx.virtualHosts._name_.locations._name_.proxyPass">locations."/".proxyPass</link> = "http://unix:/run/gitlab/gitlab-workhorse.socket";
|
||||
};
|
||||
};
|
||||
</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="module-services-gitlab-configuring">
|
||||
<title>Configuring</title>
|
||||
|
||||
<para>
|
||||
GitLab depends on both PostgreSQL and Redis and will automatically enable
|
||||
both services. In the case of PostgreSQL, a database and a role will be
|
||||
created.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The default state dir is <literal>/var/gitlab/state</literal>. This is where
|
||||
all data like the repositories and uploads will be stored.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A basic configuration with some custom settings could look like this:
|
||||
<programlisting>
|
||||
services.gitlab = {
|
||||
<link linkend="opt-services.gitlab.enable">enable</link> = true;
|
||||
<link linkend="opt-services.gitlab.databasePasswordFile">databasePasswordFile</link> = "/var/keys/gitlab/db_password";
|
||||
<link linkend="opt-services.gitlab.initialRootPasswordFile">initialRootPasswordFile</link> = "/var/keys/gitlab/root_password";
|
||||
<link linkend="opt-services.gitlab.https">https</link> = true;
|
||||
<link linkend="opt-services.gitlab.host">host</link> = "git.example.com";
|
||||
<link linkend="opt-services.gitlab.port">port</link> = 443;
|
||||
<link linkend="opt-services.gitlab.user">user</link> = "git";
|
||||
<link linkend="opt-services.gitlab.group">group</link> = "git";
|
||||
smtp = {
|
||||
<link linkend="opt-services.gitlab.smtp.enable">enable</link> = true;
|
||||
<link linkend="opt-services.gitlab.smtp.address">address</link> = "localhost";
|
||||
<link linkend="opt-services.gitlab.smtp.port">port</link> = 25;
|
||||
};
|
||||
secrets = {
|
||||
<link linkend="opt-services.gitlab.secrets.dbFile">dbFile</link> = "/var/keys/gitlab/db";
|
||||
<link linkend="opt-services.gitlab.secrets.secretFile">secretFile</link> = "/var/keys/gitlab/secret";
|
||||
<link linkend="opt-services.gitlab.secrets.otpFile">otpFile</link> = "/var/keys/gitlab/otp";
|
||||
<link linkend="opt-services.gitlab.secrets.jwsFile">jwsFile</link> = "/var/keys/gitlab/jws";
|
||||
};
|
||||
<link linkend="opt-services.gitlab.extraConfig">extraConfig</link> = {
|
||||
gitlab = {
|
||||
email_from = "gitlab-no-reply@example.com";
|
||||
email_display_name = "Example GitLab";
|
||||
email_reply_to = "gitlab-no-reply@example.com";
|
||||
default_projects_features = { builds = false; };
|
||||
};
|
||||
};
|
||||
};
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you're setting up a new GitLab instance, generate new
|
||||
secrets. You for instance use <literal>tr -dc A-Za-z0-9 <
|
||||
/dev/urandom | head -c 128 > /var/keys/gitlab/db</literal> to
|
||||
generate a new db secret. Make sure the files can be read by, and
|
||||
only by, the user specified by <link
|
||||
linkend="opt-services.gitlab.user">services.gitlab.user</link>. GitLab
|
||||
encrypts sensitive data stored in the database. If you're restoring
|
||||
an existing GitLab instance, you must specify the secrets secret
|
||||
from <literal>config/secrets.yml</literal> located in your GitLab
|
||||
state folder.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When <literal>incoming_mail.enabled</literal> is set to <literal>true</literal>
|
||||
in <link linkend="opt-services.gitlab.extraConfig">extraConfig</link> an additional
|
||||
service called <literal>gitlab-mailroom</literal> is enabled for fetching incoming mail.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Refer to <xref linkend="ch-options" /> for all available configuration
|
||||
options for the
|
||||
<link linkend="opt-services.gitlab.enable">services.gitlab</link> module.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="module-services-gitlab-maintenance">
|
||||
<title>Maintenance</title>
|
||||
|
||||
<section xml:id="module-services-gitlab-maintenance-backups">
|
||||
<title>Backups</title>
|
||||
<para>
|
||||
Backups can be configured with the options in <link
|
||||
linkend="opt-services.gitlab.backup.keepTime">services.gitlab.backup</link>. Use
|
||||
the <link
|
||||
linkend="opt-services.gitlab.backup.startAt">services.gitlab.backup.startAt</link>
|
||||
option to configure regular backups.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To run a manual backup, start the <literal>gitlab-backup</literal> service:
|
||||
<screen>
|
||||
<prompt>$ </prompt>systemctl start gitlab-backup.service
|
||||
</screen>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="module-services-gitlab-maintenance-rake">
|
||||
<title>Rake tasks</title>
|
||||
|
||||
<para>
|
||||
You can run GitLab's rake tasks with <literal>gitlab-rake</literal>
|
||||
which will be available on the system when GitLab is enabled. You
|
||||
will have to run the command as the user that you configured to run
|
||||
GitLab with.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A list of all availabe rake tasks can be obtained by running:
|
||||
<screen>
|
||||
<prompt>$ </prompt>sudo -u git -H gitlab-rake -T
|
||||
</screen>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</chapter>
|
||||
Loading…
Add table
Add a link
Reference in a new issue