79a5d76801
Our friends at GitHub show the programming languages for a long time, and inspired by that this commit means to create about the same functionality. Language detection is done through Linguist, as before, where the difference is that we cache the result in the database. Also, Gitaly can incrementaly scan a repository. This is done through a shell out, which creates overhead of about 3s each run. For now this won't be improved. Scans are triggered by pushed to the default branch, usually `master`. However, one exception to this rule the charts page. If we're requesting this expensive data anyway, we just cache it in the database. Edge cases where there is no repository, or its empty are caught in the Repository model. This makes use of Redis caching, which is probably already loaded. The added model is called RepositoryLanguage, which will make it harder if/when GitLab supports multiple repositories per project. However, for now I think this shouldn't be a concern. Also, Language could be confused with the i18n languages and felt like the current name was suiteable too. Design of the Project#Show page is done with help from @dimitrieh. This change is not visible to the end user unless detections are done. |
||
---|---|---|
.. | ||
environments | ||
initializers | ||
locales | ||
prometheus | ||
routes | ||
application.rb | ||
boot.rb | ||
database.yml.env | ||
database.yml.mysql | ||
database.yml.postgresql | ||
dependency_decisions.yml | ||
environment.rb | ||
gitlab.yml.example | ||
karma.config.js | ||
license_finder.yml | ||
mail_room.yml | ||
no_todos_messages.yml | ||
object_store_settings.rb | ||
README.md | ||
redis.cache.yml.example | ||
redis.queues.yml.example | ||
redis.shared_state.yml.example | ||
resque.yml.example | ||
routes.rb | ||
secrets.yml.example | ||
settings.rb | ||
sidekiq.yml.example | ||
sidekiq_queues.yml | ||
spring.rb | ||
unicorn.rb.example | ||
unicorn.rb.example.development | ||
webpack.config.js |
Configuration files Documentation
Note that most configuration files (config/*.*
) committed into
gitlab-ce will not be used for
omnibus-gitlab. Configuration
files committed into gitlab-ce are only used for development.
gitlab.yml
You can find most of GitLab configuration settings here.
mail_room.yml
This file is actually an YML wrapped inside an ERB file to enable templated
values to be specified from gitlab.yml
. mail_room loads this file first as
an ERB file and then loads the resulting YML as its configuration.
resque.yml
This file is called resque.yml
for historical reasons. We are NOT
using Resque at the moment. It is used to specify Redis configuration
values when a single database instance of Redis is desired.
Advanced Redis configuration files
In more advanced configurations of Redis key-value storage, it is desirable to separate the keys by lifecycle and intended use to ease provisioning and management of scalable Redis clusters.
These settings provide routing and other configuration data (such as sentinel, persistence policies, and other Redis customization) for connections to Redis single instances, Redis sentinel, and Redis clusters.
If desired, the routing URL provided by these settings can be used with:
- Unix Socket
- named socket for each Redis instance desired.
database number
for each Redis instance desired.
- TCP Socket
host name
or IP for each Redis instance desired- TCP port number for each Redis instance desired
database number
for each Redis instance desired
Example URL attribute formats for GitLab Redis .yml
configuration files
- Unix Socket, default Redis database (0)
url: unix:/path/to/redis.sock
url: unix:/path/to/redis.sock?db=
- Unix Socket, Redis database 44
url: unix:/path/to/redis.sock?db=44
url: unix:/path/to/redis.sock?extra=foo&db=44
- TCP Socket for Redis on localhost, port 6379, database 33
url: redis://:mynewpassword@localhost:6379/33
- TCP Socket for Redis on remote host
myserver
, port 6379, database 33url: redis://:mynewpassword@myserver:6379/33
redis.cache.yml
If configured, redis.cache.yml
overrides the
resque.yml
settings to configure the Redis database instance
used for Rails.cache
and other volatile non-persistent data which enhances
the performance of GitLab.
Settings here can be overridden by the environment variable
GITLAB_REDIS_CACHE_CONFIG_FILE
which provides
an alternate location for configuration settings.
The order of precedence for the URL used to connect to the Redis instance
used for cache
is:
- URL from a configuration file pointed to by the
GITLAB_REDIS_CACHE_CONFIG_FILE
environment variable - URL from
redis.cache.yml
- URL from a configuration file pointed to by the
GITLAB_REDIS_CONFIG_FILE
environment variable - URL from
resque.yml
redis://localhost:6380
The order of precedence for all other configuration settings for cache
are selected from only the first of the following files found (if a setting
is not provided in an earlier file, the remainder of the files are not
searched):
- the configuration file pointed to by the
GITLAB_REDIS_CACHE_CONFIG_FILE
environment variable - the configuration file
redis.cache.yml
- the configuration file pointed to by the
GITLAB_REDIS_CONFIG_FILE
environment variable - the configuration file
resque.yml
redis.queues.yml
If configured, redis.queues.yml
overrides the
resque.yml
settings to configure the Redis database instance
used for clients of ::Gitlab::Redis::Queues
.
These queues are intended to be the foundation
of reliable inter-process communication between modules, whether on the same
host node, or within a cluster. The primary clients of the queues are
SideKiq, Mailroom, CI Runner, Workhorse, and push services. Settings here can
be overridden by the environment variable
GITLAB_REDIS_QUEUES_CONFIG_FILE
which provides an alternate location for
configuration settings.
The order of precedence for the URL used to connect to the Redis instance
used for queues
is:
- URL from a configuration file pointed to by the
GITLAB_REDIS_QUEUES_CONFIG_FILE
environment variable - URL from
redis.queues.yml
- URL from a configuration file pointed to by the
GITLAB_REDIS_CONFIG_FILE
environment variable - URL from
resque.yml
redis://localhost:6381
The order of precedence for all other configuration settings for queues
are selected from only the first of the following files found (if a setting
is not provided in an earlier file, the remainder of the files are not
searched):
- the configuration file pointed to by the
GITLAB_REDIS_QUEUES_CONFIG_FILE
environment variable - the configuration file
redis.queues.yml
- the configuration file pointed to by the
GITLAB_REDIS_CONFIG_FILE
environment variable - the configuration file
resque.yml
redis.shared_state.yml
If configured, redis.shared_state.yml
overrides the
resque.yml
settings to configure the Redis database instance
used for clients of ::Gitlab::Redis::SharedState
such as session state,
and rate limiting.
Settings here can be overridden by the environment variable
GITLAB_REDIS_SHARED_STATE_CONFIG_FILE
which provides
an alternate location for configuration settings.
The order of precedence for the URL used to connect to the Redis instance
used for shared_state
is:
- URL from a configuration file pointed to by the
GITLAB_REDIS_SHARED_STATE_CONFIG_FILE
environment variable - URL from
redis.shared_state.yml
- URL from a configuration file pointed to by the
GITLAB_REDIS_CONFIG_FILE
environment variable - URL from
resque.yml
redis://localhost:6382
The order of precedence for all other configuration settings for shared_state
are selected from only the first of the following files found (if a setting
is not provided in an earlier file, the remainder of the files are not
searched):
- the configuration file pointed to by the
GITLAB_REDIS_SHARED_STATE_CONFIG_FILE
environment variable - the configuration file
redis.shared_state.yml
- the configuration file pointed to by the
GITLAB_REDIS_CONFIG_FILE
environment variable - the configuration file
resque.yml