Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
9331523ddc
commit
846ebeb02e
18 changed files with 146 additions and 90 deletions
|
|
@ -1245,7 +1245,7 @@ class User < ApplicationRecord
|
|||
end
|
||||
|
||||
def solo_owned_groups
|
||||
@solo_owned_groups ||= owned_groups.select do |group|
|
||||
@solo_owned_groups ||= owned_groups.includes(:owners).select do |group|
|
||||
group.owners == [self]
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Fix N+1 when looking up user's solo owned groups
|
||||
merge_request: 48340
|
||||
author:
|
||||
type: performance
|
||||
|
|
@ -301,6 +301,7 @@ Some features are not implemented yet. For example, support for environments.
|
|||
- `only` and `except`
|
||||
- `when` (only with `on_success`, `on_failure`, and `always` values)
|
||||
- `extends`
|
||||
- `needs`
|
||||
|
||||
## Trigger a pipeline when an upstream project is rebuilt **(PREMIUM)**
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ limits to GitLab.
|
|||
## Documentation
|
||||
|
||||
First of all, you have to gather information and decide which are the different
|
||||
limits that will be set for the different GitLab tiers. You also need to
|
||||
limits that are set for the different GitLab tiers. You also need to
|
||||
coordinate with others to [document](../administration/instance_limits.md)
|
||||
and communicate those limits.
|
||||
|
||||
|
|
@ -63,7 +63,7 @@ It's recommended to create two separate migration script files.
|
|||
end
|
||||
```
|
||||
|
||||
Some plans exist only on GitLab.com. This will be a no-op for plans
|
||||
Some plans exist only on GitLab.com. This is a no-op for plans
|
||||
that do not exist.
|
||||
|
||||
### Plan limits validation
|
||||
|
|
|
|||
|
|
@ -282,8 +282,8 @@ When deployed, GitLab should be considered the amalgamation of the below process
|
|||
|
||||
GitLab can be considered to have two layers from a process perspective:
|
||||
|
||||
- **Monitoring**: Anything from this layer is not required to deliver GitLab the application, but will allow administrators more insight into their infrastructure and what the service as a whole is doing.
|
||||
- **Core**: Any process that is vital for the delivery of GitLab as a platform. If any of these processes halt there will be a GitLab outage. For the Core layer, you can further divide into:
|
||||
- **Monitoring**: Anything from this layer is not required to deliver GitLab the application, but allows administrators more insight into their infrastructure and what the service as a whole is doing.
|
||||
- **Core**: Any process that is vital for the delivery of GitLab as a platform. If any of these processes halt, a GitLab outage results. For the Core layer, you can further divide into:
|
||||
- **Processors**: These processes are responsible for actually performing operations and presenting the service.
|
||||
- **Data**: These services store/expose structured data for the GitLab service.
|
||||
|
||||
|
|
@ -297,7 +297,7 @@ GitLab can be considered to have two layers from a process perspective:
|
|||
- Process: `alertmanager`
|
||||
- GitLab.com: [Monitoring of GitLab.com](https://about.gitlab.com/handbook/engineering/monitoring/)
|
||||
|
||||
[Alert manager](https://prometheus.io/docs/alerting/latest/alertmanager/) is a tool provided by Prometheus that _"handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integration such as email, PagerDuty, or Opsgenie. It also takes care of silencing and inhibition of alerts."_ You can read more in [issue #45740](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45740) about what we will be alerting on.
|
||||
[Alert manager](https://prometheus.io/docs/alerting/latest/alertmanager/) is a tool provided by Prometheus that _"handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integration such as email, PagerDuty, or Opsgenie. It also takes care of silencing and inhibition of alerts."_ You can read more in [issue #45740](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45740) about what we alert on.
|
||||
|
||||
#### Certificate management
|
||||
|
||||
|
|
@ -600,7 +600,7 @@ GitLab packages the popular Database to provide storage for Application meta dat
|
|||
- Process: `postgres-exporter`
|
||||
- GitLab.com: [Monitoring of GitLab.com](https://about.gitlab.com/handbook/engineering/monitoring/)
|
||||
|
||||
[`postgres_exporter`](https://github.com/wrouesnel/postgres_exporter) is the community provided Prometheus exporter that will deliver data about PostgreSQL to Prometheus for use in Grafana Dashboards.
|
||||
[`postgres_exporter`](https://github.com/wrouesnel/postgres_exporter) is the community provided Prometheus exporter that delivers data about PostgreSQL to Prometheus for use in Grafana Dashboards.
|
||||
|
||||
#### Prometheus
|
||||
|
||||
|
|
@ -656,10 +656,10 @@ Redis is packaged to provide a place to store:
|
|||
|
||||
The registry is what users use to store their own Docker images. The bundled
|
||||
registry uses NGINX as a load balancer and GitLab as an authentication manager.
|
||||
Whenever a client requests to pull or push an image from the registry, it will
|
||||
return a `401` response along with a header detailing where to get an
|
||||
authentication token, in this case the GitLab instance. The client will then
|
||||
request a pull or push auth token from GitLab and retry the original request
|
||||
Whenever a client requests to pull or push an image from the registry, it
|
||||
returns a `401` response along with a header detailing where to get an
|
||||
authentication token, in this case the GitLab instance. The client then
|
||||
requests a pull or push auth token from GitLab and retries the original request
|
||||
to the registry. Learn more about [token authentication](https://docs.docker.com/registry/spec/auth/token/).
|
||||
|
||||
An external registry can also be configured to use GitLab as an auth endpoint.
|
||||
|
|
@ -710,7 +710,7 @@ disabled by default.
|
|||
- Process: `puma`
|
||||
- GitLab.com: [Puma](../user/gitlab_com/index.md#puma)
|
||||
|
||||
[Puma](https://puma.io/) is a Ruby application server that is used to run the core Rails Application that provides the user facing features in GitLab. Often process output you will see this as `bundle` or `config.ru` depending on the GitLab version.
|
||||
[Puma](https://puma.io/) is a Ruby application server that is used to run the core Rails Application that provides the user facing features in GitLab. Often this displays in process output as `bundle` or `config.ru` depending on the GitLab version.
|
||||
|
||||
#### Unicorn
|
||||
|
||||
|
|
@ -727,7 +727,7 @@ disabled by default.
|
|||
- Process: `unicorn`
|
||||
- GitLab.com: [Unicorn](../user/gitlab_com/index.md#unicorn)
|
||||
|
||||
[Unicorn](https://yhbt.net/unicorn/) is a Ruby application server that is used to run the core Rails Application that provides the user facing features in GitLab. Often process output you will see this as `bundle` or `config.ru` depending on the GitLab version.
|
||||
[Unicorn](https://yhbt.net/unicorn/) is a Ruby application server that is used to run the core Rails Application that provides the user facing features in GitLab. Often this displays in process output as `bundle` or `config.ru` depending on the GitLab version.
|
||||
|
||||
#### LDAP Authentication
|
||||
|
||||
|
|
@ -792,16 +792,16 @@ It's important to understand the distinction as some processes are used in both
|
|||
|
||||
### GitLab Web HTTP request cycle
|
||||
|
||||
When making a request to an HTTP Endpoint (think `/users/sign_in`) the request will take the following path through the GitLab Service:
|
||||
When making a request to an HTTP Endpoint (think `/users/sign_in`) the request takes the following path through the GitLab Service:
|
||||
|
||||
- NGINX - Acts as our first line reverse proxy.
|
||||
- GitLab Workhorse - This determines if it needs to go to the Rails application or somewhere else to reduce load on Puma.
|
||||
- Puma - Since this is a web request, and it needs to access the application it will go to Puma.
|
||||
- Puma - Since this is a web request, and it needs to access the application, it routes to Puma.
|
||||
- PostgreSQL/Gitaly/Redis - Depending on the type of request, it may hit these services to store or retrieve data.
|
||||
|
||||
### GitLab Git request cycle
|
||||
|
||||
Below we describe the different paths that HTTP vs. SSH Git requests will take. There is some overlap with the Web Request Cycle but also some differences.
|
||||
Below we describe the different paths that HTTP vs. SSH Git requests take. There is some overlap with the Web Request Cycle but also some differences.
|
||||
|
||||
### Web request (80/443)
|
||||
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ Its simplest usage is to provide the value for `title`:
|
|||
bin/changelog 'Hey DZ, I added a feature to GitLab!'
|
||||
```
|
||||
|
||||
If you want to generate a changelog entry for GitLab EE, you will need to pass
|
||||
If you want to generate a changelog entry for GitLab EE, you must pass
|
||||
the `--ee` option:
|
||||
|
||||
```plaintext
|
||||
|
|
@ -144,10 +144,10 @@ At this point the script would ask you to select the category of the change (map
|
|||
```
|
||||
|
||||
The entry filename is based on the name of the current Git branch. If you run
|
||||
the command above on a branch called `feature/hey-dz`, it will generate a
|
||||
the command above on a branch called `feature/hey-dz`, it generates a
|
||||
`changelogs/unreleased/feature-hey-dz.yml` file.
|
||||
|
||||
The command will output the path of the generated file and its contents:
|
||||
The command outputs the path of the generated file and its contents:
|
||||
|
||||
```plaintext
|
||||
create changelogs/unreleased/my-feature.yml
|
||||
|
|
@ -175,7 +175,7 @@ type:
|
|||
You can pass the **`--amend`** argument to automatically stage the generated
|
||||
file and amend it to the previous commit.
|
||||
|
||||
If you use **`--amend`** and don't provide a title, it will automatically use
|
||||
If you use **`--amend`** and don't provide a title, it uses
|
||||
the "subject" of the previous commit, which is the first line of the commit
|
||||
message:
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ and tag all tooling images locally:
|
|||
```
|
||||
|
||||
For each image, there's a manual job under the `images` stage in
|
||||
[`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/.gitlab-ci.yml) which can be invoked at will.
|
||||
[`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/.gitlab-ci.yml) which can be invoked at any time.
|
||||
|
||||
## Update an old Docker image with new upstream docs content
|
||||
|
||||
|
|
@ -51,7 +51,7 @@ Porting changes to older branches can have unintended effects as we're constantl
|
|||
changing the backend of the website. Use only when you know what you're doing
|
||||
and make sure to test locally.
|
||||
|
||||
The website will keep changing and being improved. In order to consolidate
|
||||
The website keeps changing and being improved. In order to consolidate
|
||||
those changes to the stable branches, we'd need to pick certain changes
|
||||
from time to time.
|
||||
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ from where content is sourced, the `gitlab-docs` project, and the published outp
|
|||
H -- symlink --> G
|
||||
```
|
||||
|
||||
You will not find any GitLab docs content in the `gitlab-docs` repository.
|
||||
GitLab docs content isn't kept in the `gitlab-docs` repository.
|
||||
All documentation files are hosted in the respective repository of each
|
||||
product, and all together are pulled to generate the docs website:
|
||||
|
||||
|
|
@ -62,7 +62,7 @@ in order not to break any existing links throughout the internet, we still
|
|||
maintain the CE docs (`https://docs.gitlab.com/ce/`), although it is hidden
|
||||
from the website, and is now a symlink to the EE docs. When
|
||||
[Pages supports redirects](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/24),
|
||||
we will be able to remove this completely.
|
||||
we can remove this completely.
|
||||
|
||||
## Assets
|
||||
|
||||
|
|
@ -179,7 +179,7 @@ we reference the array with a symbol (`:versions`).
|
|||
|
||||
Whenever the custom CSS and JavaScript files under `content/assets/` change,
|
||||
make sure to bump their version in the front matter. This method guarantees that
|
||||
your changes will take effect by clearing the cache of previous files.
|
||||
your changes take effect by clearing the cache of previous files.
|
||||
|
||||
Always use Nanoc's way of including those files, do not hardcode them in the
|
||||
layouts. For example use:
|
||||
|
|
@ -196,7 +196,7 @@ The links pointing to the files should be similar to:
|
|||
<%= @items['/path/to/assets/file.*'].path %>
|
||||
```
|
||||
|
||||
Nanoc will then build and render those links correctly according with what's
|
||||
Nanoc then builds and renders those links correctly according with what's
|
||||
defined in [`Rules`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/Rules).
|
||||
|
||||
## Linking to source files
|
||||
|
|
@ -236,7 +236,7 @@ If you’re a GitLab team member, find credentials for the Algolia dashboard
|
|||
in the shared [GitLab 1Password account](https://about.gitlab.com/handbook/security/#1password-for-teams).
|
||||
To receive weekly reports of the search usage, search the Google doc with
|
||||
title `Email, Slack, and GitLab Groups and Aliases`, search for `docsearch`,
|
||||
and add a comment with your email. You'll be added to the alias that gets the weekly
|
||||
and add a comment with your email to be added to the alias that gets the weekly
|
||||
reports.
|
||||
|
||||
## Monthly release process (versions)
|
||||
|
|
|
|||
|
|
@ -44,14 +44,14 @@ this needs to happen when the stable branches for all products have been created
|
|||
```
|
||||
|
||||
A new `Dockerfile.12.0` should have been created and `.gitlab-ci.yml` should
|
||||
have the branches variables updated into a new branch. They will be automatically
|
||||
have the branches variables updated into a new branch. They are automatically
|
||||
committed.
|
||||
|
||||
1. Push the newly created branch, but **don't create a merge request**.
|
||||
Once you push, the `image:docker-singe` job will create a new Docker image
|
||||
After you push, the `image:docker-singe` job creates a new Docker image
|
||||
tagged with the branch name you created in the first step. In the end, the
|
||||
image will be uploaded in the [Container Registry](https://gitlab.com/gitlab-org/gitlab-docs/container_registry)
|
||||
and it will be listed under the `registry` environment folder at
|
||||
image is uploaded in the [Container Registry](https://gitlab.com/gitlab-org/gitlab-docs/container_registry)
|
||||
and it is listed under the `registry` environment folder at
|
||||
`https://gitlab.com/gitlab-org/gitlab-docs/-/environments/folders/registry` (must
|
||||
have developer access).
|
||||
|
||||
|
|
@ -114,20 +114,20 @@ version and rotates the old one:
|
|||
|
||||
The versions dropdown is in a way "hardcoded". When the site is built, it looks
|
||||
at the contents of `content/_data/versions.yaml` and based on that, the dropdown
|
||||
is populated. So, older branches will have different content, which means the
|
||||
dropdown will list one or more releases behind. Remember that the new changes of
|
||||
is populated. So, older branches have different content, which means the
|
||||
dropdown list one or more releases behind. Remember that the new changes of
|
||||
the dropdown are included in the unmerged `release-X-Y` branch.
|
||||
|
||||
The content of `content/_data/versions.yaml` needs to change for all online
|
||||
versions (stable branches `X.Y` of the `gitlab-docs` project):
|
||||
|
||||
1. Run the Rake task that will create all the respective merge requests needed to
|
||||
update the dropdowns and will be set to automatically be merged when their
|
||||
1. Run the Rake task that creates all the respective merge requests needed to
|
||||
update the dropdowns and are set to automatically be merged when their
|
||||
pipelines succeed:
|
||||
|
||||
NOTE: **Note:**
|
||||
The `release-X-Y` branch needs to be present locally,
|
||||
and you need to have switched to it, otherwise the Rake task will fail.
|
||||
and you need to have switched to it, otherwise the Rake task fails.
|
||||
|
||||
```shell
|
||||
git checkout release-X-Y
|
||||
|
|
@ -144,7 +144,7 @@ In case a pipeline fails, see [troubleshooting](#troubleshooting).
|
|||
## 5. Merge the release merge request
|
||||
|
||||
The dropdown merge requests should have now been merged into their respective
|
||||
version (stable `X.Y` branch), which will trigger another pipeline. At this point,
|
||||
version (stable `X.Y` branch), which triggers another pipeline. At this point,
|
||||
you need to only babysit the pipelines and make sure they don't fail:
|
||||
|
||||
1. Check the [pipelines page](https://gitlab.com/gitlab-org/gitlab-docs/pipelines)
|
||||
|
|
@ -152,9 +152,9 @@ you need to only babysit the pipelines and make sure they don't fail:
|
|||
1. After all the pipelines of the online versions succeed, merge the release merge request.
|
||||
1. Finally, run the
|
||||
[`Build docker images weekly` pipeline](https://gitlab.com/gitlab-org/gitlab-docs/pipeline_schedules)
|
||||
that will build the `:latest` and `:archives` Docker images.
|
||||
that builds the `:latest` and `:archives` Docker images.
|
||||
|
||||
Once the scheduled pipeline succeeds, the docs site will be deployed with all
|
||||
Once the scheduled pipeline succeeds, the docs site is deployed with all
|
||||
new versions online.
|
||||
|
||||
## Troubleshooting
|
||||
|
|
|
|||
|
|
@ -191,6 +191,10 @@ If you want to run tests locally against a modified version of Gitaly you
|
|||
can replace `tmp/tests/gitaly` with a symlink. This is much faster
|
||||
because it avoids a Gitaly re-install each time you run `rspec`.
|
||||
|
||||
Make sure this directory contains the files `config.toml` and `praefect.config.toml`.
|
||||
You can copy them from `config.toml.example` and `config.praefect.toml.example` respectively.
|
||||
After copying, make sure to edit them so everything points to the correct paths.
|
||||
|
||||
```shell
|
||||
rm -rf tmp/tests/gitaly
|
||||
ln -s /path/to/gitaly tmp/tests/gitaly
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
# Migration Style Guide
|
||||
|
||||
When writing migrations for GitLab, you have to take into account that
|
||||
these will be run by hundreds of thousands of organizations of all sizes, some with
|
||||
these are run by hundreds of thousands of organizations of all sizes, some with
|
||||
many years of data in their database.
|
||||
|
||||
In addition, having to take a server offline for an upgrade small or big is a
|
||||
|
|
@ -44,15 +44,15 @@ and post-deployment migrations (`db/post_migrate`) are run after the deployment
|
|||
Changes to the schema should be committed to `db/structure.sql`. This
|
||||
file is automatically generated by Rails, so you normally should not
|
||||
edit this file by hand. If your migration is adding a column to a
|
||||
table, that column will be added at the bottom. Please do not reorder
|
||||
columns manually for existing tables as this will cause confusion to
|
||||
table, that column is added at the bottom. Please do not reorder
|
||||
columns manually for existing tables as this causes confusion to
|
||||
other people using `db/structure.sql` generated by Rails.
|
||||
|
||||
When your local database in your GDK is diverging from the schema from
|
||||
`master` it might be hard to cleanly commit the schema changes to
|
||||
Git. In that case you can use the `scripts/regenerate-schema` script to
|
||||
regenerate a clean `db/structure.sql` for the migrations you're
|
||||
adding. This script will apply all migrations found in `db/migrate`
|
||||
adding. This script applies all migrations found in `db/migrate`
|
||||
or `db/post_migrate`, so if there are any migrations you don't want to
|
||||
commit to the schema, rename or remove them. If your branch is not
|
||||
targeting `master` you can set the `TARGET` environment variable.
|
||||
|
|
@ -80,7 +80,7 @@ and whether they require downtime and how to work around that whenever possible.
|
|||
|
||||
Every migration must specify if it requires downtime or not, and if it should
|
||||
require downtime it must also specify a reason for this. This is required even
|
||||
if 99% of the migrations won't require downtime as this makes it easier to find
|
||||
if 99% of the migrations don't require downtime as this makes it easier to find
|
||||
the migrations that _do_ require downtime.
|
||||
|
||||
To tag a migration, add the following two constants to the migration class'
|
||||
|
|
@ -104,7 +104,7 @@ class MyMigration < ActiveRecord::Migration[6.0]
|
|||
end
|
||||
```
|
||||
|
||||
It is an error (that is, CI will fail) if the `DOWNTIME` constant is missing
|
||||
It is an error (that is, CI fails) if the `DOWNTIME` constant is missing
|
||||
from a migration class.
|
||||
|
||||
## Reversibility
|
||||
|
|
@ -136,7 +136,7 @@ By default, migrations are single transaction. That is, a transaction is opened
|
|||
at the beginning of the migration, and committed after all steps are processed.
|
||||
|
||||
Running migrations in a single transaction makes sure that if one of the steps fails,
|
||||
none of the steps will be executed, leaving the database in valid state.
|
||||
none of the steps are executed, leaving the database in valid state.
|
||||
Therefore, either:
|
||||
|
||||
- Put all migrations in one single-transaction migration.
|
||||
|
|
@ -146,12 +146,12 @@ Therefore, either:
|
|||
For example, if you create an empty table and need to build an index for it,
|
||||
it is recommended to use a regular single-transaction migration and the default
|
||||
rails schema statement: [`add_index`](https://api.rubyonrails.org/v5.2/classes/ActiveRecord/ConnectionAdapters/SchemaStatements.html#method-i-add_index).
|
||||
This is a blocking operation, but it won't cause problems because the table is not yet used,
|
||||
This is a blocking operation, but it doesn't cause problems because the table is not yet used,
|
||||
and therefore it does not have any records yet.
|
||||
|
||||
## Heavy operations in a single transaction
|
||||
|
||||
When using a single-transaction migration, a transaction will hold on a database connection
|
||||
When using a single-transaction migration, a transaction holds a database connection
|
||||
for the duration of the migration, so you must make sure the actions in the migration
|
||||
do not take too much time: GitLab.com’s production database has a `15s` timeout, so
|
||||
in general, the cumulative execution time in a migration should aim to fit comfortably
|
||||
|
|
@ -183,8 +183,8 @@ on the `users` table once it has been enqueued.
|
|||
More information about PostgresSQL locks: [Explicit Locking](https://www.postgresql.org/docs/current/explicit-locking.html)
|
||||
|
||||
For stability reasons, GitLab.com has a specific [`statement_timeout`](../user/gitlab_com/index.md#postgresql)
|
||||
set. When the migration is invoked, any database query will have
|
||||
a fixed time to execute. In a worst-case scenario, the request will sit in the
|
||||
set. When the migration is invoked, any database query has
|
||||
a fixed time to execute. In a worst-case scenario, the request sits in the
|
||||
lock queue, blocking other queries for the duration of the configured statement timeout,
|
||||
then failing with `canceling statement due to statement timeout` error.
|
||||
|
||||
|
|
@ -275,7 +275,7 @@ end
|
|||
|
||||
**Creating a new table when we have two foreign keys:**
|
||||
|
||||
For this, we'll need three migrations:
|
||||
For this, we need three migrations:
|
||||
|
||||
1. Creating the table without foreign keys (with the indices).
|
||||
1. Add foreign key to the first table.
|
||||
|
|
@ -355,7 +355,7 @@ def up
|
|||
end
|
||||
```
|
||||
|
||||
The RuboCop rule generally allows standard Rails migration methods, listed below. This example will cause a Rubocop offense:
|
||||
The RuboCop rule generally allows standard Rails migration methods, listed below. This example causes a Rubocop offense:
|
||||
|
||||
```ruby
|
||||
disable_ddl_transaction!
|
||||
|
|
@ -400,9 +400,9 @@ In a worst-case scenario, the method:
|
|||
|
||||
- Executes the block for a maximum of 50 times over 40 minutes.
|
||||
- Most of the time is spent in a pre-configured sleep period after each iteration.
|
||||
- After the 50th retry, the block will be executed without `lock_timeout`, just
|
||||
- After the 50th retry, the block is executed without `lock_timeout`, just
|
||||
like a standard migration invocation.
|
||||
- If a lock cannot be acquired, the migration will fail with `statement timeout` error.
|
||||
- If a lock cannot be acquired, the migration fails with `statement timeout` error.
|
||||
|
||||
The migration might fail if there is a very long running transaction (40+ minutes)
|
||||
accessing the `users` table.
|
||||
|
|
@ -438,9 +438,9 @@ class MyMigration < ActiveRecord::Migration[6.0]
|
|||
end
|
||||
```
|
||||
|
||||
Here the call to `disable_statement_timeout` will use the connection local to
|
||||
Here the call to `disable_statement_timeout` uses the connection local to
|
||||
the `with_multiple_threads` block, instead of re-using the global connection
|
||||
pool. This ensures each thread has its own connection object, and won't time
|
||||
pool. This ensures each thread has its own connection object, and doesn't time
|
||||
out when trying to obtain one.
|
||||
|
||||
PostgreSQL has a maximum amount of connections that it allows. This
|
||||
|
|
@ -583,7 +583,7 @@ remember to add an index on the column.
|
|||
This is **required** for all foreign-keys, e.g., to support efficient cascading
|
||||
deleting: when a lot of rows in a table get deleted, the referenced records need
|
||||
to be deleted too. The database has to look for corresponding records in the
|
||||
referenced table. Without an index, this will result in a sequential scan on the
|
||||
referenced table. Without an index, this results in a sequential scan on the
|
||||
table, which can take a long time.
|
||||
|
||||
Here's an example where we add a new column with a foreign key
|
||||
|
|
@ -621,7 +621,7 @@ the standard `add_column` helper should be used in all cases.
|
|||
|
||||
Before PostgreSQL 11, adding a column with a default was problematic as it would
|
||||
have caused a full table rewrite. The corresponding helper `add_column_with_default`
|
||||
has been deprecated and will be removed in a later release.
|
||||
has been deprecated and is scheduled to be removed in a later release.
|
||||
|
||||
If a backport adding a column with a default value is needed for %12.9 or earlier versions,
|
||||
it should use `add_column_with_default` helper. If a [large table](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml#L3)
|
||||
|
|
@ -667,7 +667,7 @@ without requiring `disable_ddl_transaction!`.
|
|||
## Updating an existing column
|
||||
|
||||
To update an existing column to a particular value, you can use
|
||||
`update_column_in_batches`. This will split the updates into batches, so we
|
||||
`update_column_in_batches`. This splits the updates into batches, so we
|
||||
don't update too many rows at in a single statement.
|
||||
|
||||
This updates the column `foo` in the `projects` table to 10, where `some_column`
|
||||
|
|
@ -782,12 +782,12 @@ end
|
|||
## Integer column type
|
||||
|
||||
By default, an integer column can hold up to a 4-byte (32-bit) number. That is
|
||||
a max value of 2,147,483,647. Be aware of this when creating a column that will
|
||||
hold file sizes in byte units. If you are tracking file size in bytes, this
|
||||
a max value of 2,147,483,647. Be aware of this when creating a column that
|
||||
holds file sizes in byte units. If you are tracking file size in bytes, this
|
||||
restricts the maximum file size to just over 2GB.
|
||||
|
||||
To allow an integer column to hold up to an 8-byte (64-bit) number, explicitly
|
||||
set the limit to 8-bytes. This will allow the column to hold a value up to
|
||||
set the limit to 8-bytes. This allows the column to hold a value up to
|
||||
`9,223,372,036,854,775,807`.
|
||||
|
||||
Rails migration example:
|
||||
|
|
@ -837,7 +837,7 @@ timestamps with timezones:
|
|||
- `datetime_with_timezone`
|
||||
|
||||
This ensures all timestamps have a time zone specified. This, in turn, means
|
||||
existing timestamps won't suddenly use a different timezone when the system's
|
||||
existing timestamps don't suddenly use a different timezone when the system's
|
||||
timezone changes. It also makes it very clear which timezone was used in the
|
||||
first place.
|
||||
|
||||
|
|
@ -938,19 +938,17 @@ Since we had to do this a few times already, there are now some helpers to help
|
|||
with this.
|
||||
|
||||
To use this you can include `Gitlab::Database::RenameReservedPathsMigration::V1`
|
||||
in your migration. This will provide 3 methods which you can pass one or more
|
||||
in your migration. This provides 3 methods which you can pass one or more
|
||||
paths that need to be rejected.
|
||||
|
||||
**`rename_root_paths`**: This will rename the path of all _namespaces_ with the
|
||||
- **`rename_root_paths`**: Renames the path of all _namespaces_ with the
|
||||
given name that don't have a `parent_id`.
|
||||
|
||||
**`rename_child_paths`**: This will rename the path of all _namespaces_ with the
|
||||
- **`rename_child_paths`**: Renames the path of all _namespaces_ with the
|
||||
given name that have a `parent_id`.
|
||||
|
||||
**`rename_wildcard_paths`**: This will rename the path of all _projects_, and all
|
||||
- **`rename_wildcard_paths`**: Renames the path of all _projects_, and all
|
||||
_namespaces_ that have a `project_id`.
|
||||
|
||||
The `path` column for these rows will be renamed to their previous value followed
|
||||
The `path` column for these rows are renamed to their previous value followed
|
||||
by an integer. For example: `users` would turn into `users0`
|
||||
|
||||
## Using models in migrations (discouraged)
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
## Invoking pry debugging
|
||||
|
||||
To invoke the debugger, place `binding.pry` somewhere in your
|
||||
code. When the Ruby interpreter hits that code, execution will stop,
|
||||
code. When the Ruby interpreter hits that code, execution stops,
|
||||
and you can type in commands to debug the state of the program
|
||||
|
||||
## `byebug` vs `binding.pry`
|
||||
|
|
@ -20,7 +20,7 @@ use the powerful Pry REPL.
|
|||
`binding.pry` uses Pry, but lacks some of the `byebug`
|
||||
features. GitLab uses the [`pry-byebug`](https://github.com/deivid-rodriguez/pry-byebug)
|
||||
gem. This gem brings some capabilities `byebug` to `binding.pry`, so
|
||||
using that, will give you the most debugging powers.
|
||||
using that gives you the most debugging powers.
|
||||
|
||||
## `byebug`
|
||||
|
||||
|
|
@ -104,7 +104,7 @@ You also can move around in the callstack with these commands:
|
|||
- `down`: Moves the stack frame down. Takes an optional numeric
|
||||
argument to move multiple frames.
|
||||
- `frame <n>`: Moves to a specific frame. Called without arguments
|
||||
will show the current frame.
|
||||
displays the current frame.
|
||||
|
||||
## Short commands
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ You can read more about it in: <https://github.com/pyenv/pyenv-installer#prerequ
|
|||
|
||||
### Shell integration
|
||||
|
||||
Pyenv installation will add required changes to Bash. If you use a different shell,
|
||||
Pyenv installation adds required changes to Bash. If you use a different shell,
|
||||
check for any additional steps required for it.
|
||||
|
||||
For Fish, you can install a plugin for [Fisher](https://github.com/jorgebucaran/fisher):
|
||||
|
|
@ -63,13 +63,13 @@ on the main project level, so we can run that on our development machines.
|
|||
Recently, an equivalent to the `Gemfile` and the [Bundler](https://bundler.io/) project has been introduced to Python:
|
||||
`Pipfile` and [Pipenv](https://pipenv.readthedocs.io/en/latest/).
|
||||
|
||||
You will now find a `Pipfile` with the dependencies in the root folder. To install them, run:
|
||||
A `Pipfile` with the dependencies now exists in the root folder. To install them, run:
|
||||
|
||||
```shell
|
||||
pipenv install
|
||||
```
|
||||
|
||||
Running this command will install both the required Python version as well as required pip dependencies.
|
||||
Running this command installs both the required Python version as well as required pip dependencies.
|
||||
|
||||
## Use instructions
|
||||
|
||||
|
|
@ -80,5 +80,5 @@ of the application. With Pipenv, this is a simple as running:
|
|||
pipenv shell
|
||||
```
|
||||
|
||||
After running that command, you can run GitLab on the same shell and it will be using the Python and dependencies
|
||||
After running that command, you can run GitLab on the same shell and it uses the Python and dependencies
|
||||
installed from the `pipenv install` command.
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ bin/rake "gitlab:seed:insights:issues[group-path/project-path]"
|
|||
```
|
||||
|
||||
By default, this seeds an average of 10 issues per week for the last 52 weeks
|
||||
per project. All issues will also be randomly labeled with team, type, severity,
|
||||
per project. All issues are also randomly labeled with team, type, severity,
|
||||
and priority.
|
||||
|
||||
#### Seeding groups with sub-groups
|
||||
|
|
@ -116,8 +116,8 @@ so no worries about missing errors.
|
|||
There are a few environment flags you can pass to change how projects are seeded
|
||||
|
||||
- `SIZE`: defaults to `8`, max: `32`. Amount of projects to create.
|
||||
- `LARGE_PROJECTS`: defaults to false. If set will clone 6 large projects to help with testing.
|
||||
- `FORK`: defaults to false. If set to `true` will fork `torvalds/linux` five times. Can also be set to an existing project full_path and it will fork that instead.
|
||||
- `LARGE_PROJECTS`: defaults to false. If set, clones 6 large projects to help with testing.
|
||||
- `FORK`: defaults to false. If set to `true`, forks `torvalds/linux` five times. Can also be set to an existing project `full_path` to fork that instead.
|
||||
|
||||
## Run tests
|
||||
|
||||
|
|
@ -132,10 +132,10 @@ In order to run the test you can use the following commands:
|
|||
`bin/rake spec` takes significant time to pass.
|
||||
Instead of running the full test suite locally, you can save a lot of time by running
|
||||
a single test or directory related to your changes. After you submit a merge request,
|
||||
CI will run full test suite for you. Green CI status in the merge request means
|
||||
CI runs full test suite for you. Green CI status in the merge request means
|
||||
full test suite is passed.
|
||||
|
||||
You can't run `rspec .` since this will try to run all the `_spec.rb`
|
||||
You can't run `rspec .` since this tries to run all the `_spec.rb`
|
||||
files it can find, also the ones in `/tmp`
|
||||
|
||||
You can pass RSpec command line options to the `spec:unit`,
|
||||
|
|
@ -157,7 +157,7 @@ To run several tests inside one directory:
|
|||
speeds up development by keeping your application running in the background so
|
||||
you don't need to boot it every time you run a test, Rake task or migration.
|
||||
|
||||
If you want to use it, you'll need to export the `ENABLE_SPRING` environment
|
||||
If you want to use it, you must export the `ENABLE_SPRING` environment
|
||||
variable to `1`:
|
||||
|
||||
```shell
|
||||
|
|
@ -180,7 +180,7 @@ environment you can do so with the following command:
|
|||
RAILS_ENV=production NODE_ENV=production bundle exec rake gitlab:assets:compile
|
||||
```
|
||||
|
||||
This will compile and minify all JavaScript and CSS assets and copy them along
|
||||
This compiles and minifies all JavaScript and CSS assets and copy them along
|
||||
with all other frontend assets (images, fonts, etc) into `/public/assets` where
|
||||
they can be easily inspected.
|
||||
|
||||
|
|
@ -200,7 +200,7 @@ following:
|
|||
bundle exec rake gemojione:digests
|
||||
```
|
||||
|
||||
This will update the file `fixtures/emojis/digests.json` based on the currently
|
||||
This updates the file `fixtures/emojis/digests.json` based on the currently
|
||||
available Emoji.
|
||||
|
||||
To generate a sprite file containing all the Emoji, run:
|
||||
|
|
|
|||
|
|
@ -43,9 +43,9 @@ a single Redis server. This means that keys should **always** be
|
|||
globally unique across all categories.
|
||||
|
||||
It is usually better to use immutable identifiers - project ID rather than
|
||||
full path, for instance - in Redis key names. If full path is used, the key will
|
||||
stop being consulted if the project is renamed. If the contents of the key are
|
||||
invalidated by a name change, it is better to include a hook that will expire
|
||||
full path, for instance - in Redis key names. If full path is used, the key
|
||||
stops being consulted if the project is renamed. If the contents of the key are
|
||||
invalidated by a name change, it is better to include a hook that expires
|
||||
the entry, instead of relying on the key changing.
|
||||
|
||||
### Multi-key commands
|
||||
|
|
@ -195,7 +195,7 @@ provides a convenient interface for adding and counting values in HyperLogLogs.
|
|||
For cases where we need to efficiently check the whether an item is in a group
|
||||
of items, we can use a Redis set.
|
||||
[`Gitlab::SetCache`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/set_cache.rb)
|
||||
provides an `#include?` method that will use the
|
||||
provides an `#include?` method that uses the
|
||||
[`SISMEMBER`](https://redis.io/commands/sismember) command, as well as `#read`
|
||||
to fetch all entries in the set.
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ system(*%W(#{Gitlab.config.git.bin_path} branch -d -- #{branch_name}))
|
|||
|
||||
## Bypass the shell by splitting commands into separate tokens
|
||||
|
||||
When we pass shell commands as a single string to Ruby, Ruby will let `/bin/sh` evaluate the entire string. Essentially, we are asking the shell to evaluate a one-line script. This creates a risk for shell injection attacks. It is better to split the shell command into tokens ourselves. Sometimes we use the scripting capabilities of the shell to change the working directory or set environment variables. All of this can also be achieved securely straight from Ruby
|
||||
When we pass shell commands as a single string to Ruby, Ruby lets `/bin/sh` evaluate the entire string. Essentially, we are asking the shell to evaluate a one-line script. This creates a risk for shell injection attacks. It is better to split the shell command into tokens ourselves. Sometimes we use the scripting capabilities of the shell to change the working directory or set environment variables. All of this can also be achieved securely straight from Ruby
|
||||
|
||||
```ruby
|
||||
# Wrong
|
||||
|
|
|
|||
|
|
@ -112,6 +112,7 @@ to the **Billing** section of the relevant namespace:
|
|||
| **Seats owed** | If your maximum seats used exceeds the seats in your subscription, you owe an additional fee for the users you've added. |
|
||||
| **Subscription start date** | Date your subscription started. If this is for a Free plan, is the date you transitioned off your group's paid plan. |
|
||||
| **Subscription end date** | Date your current subscription ends. Does not apply to Free plans. |
|
||||
| **Billable users list** | List of users that belong to your group subscription. Does not apply to Free plans. |
|
||||
|
||||
## Renew your GitLab.com subscription
|
||||
|
||||
|
|
@ -215,6 +216,10 @@ To upgrade your [GitLab tier](https://about.gitlab.com/pricing/):
|
|||
|
||||
When the purchase has been processed, you receive confirmation of your new subscription tier.
|
||||
|
||||
## See your billable users list
|
||||
|
||||
To see a list of your billable users on your GitLab group page go to **Settings > Billing**. This page provides information about your subscription and occupied seats for your group which is the list of billable users for your particular group.
|
||||
|
||||
## Subscription expiry
|
||||
|
||||
When your subscription or trial expires, GitLab does not delete your data, but
|
||||
|
|
|
|||
|
|
@ -2965,6 +2965,49 @@ RSpec.describe User do
|
|||
end
|
||||
end
|
||||
|
||||
describe '#solo_owned_groups' do
|
||||
let_it_be_with_refind(:user) { create(:user) }
|
||||
|
||||
subject(:solo_owned_groups) { user.solo_owned_groups }
|
||||
|
||||
context 'no owned groups' do
|
||||
it { is_expected.to be_empty }
|
||||
end
|
||||
|
||||
context 'has owned groups' do
|
||||
let_it_be(:group) { create(:group) }
|
||||
|
||||
before do
|
||||
group.add_owner(user)
|
||||
end
|
||||
|
||||
context 'not solo owner' do
|
||||
let_it_be(:user2) { create(:user) }
|
||||
|
||||
before do
|
||||
group.add_owner(user2)
|
||||
end
|
||||
|
||||
it { is_expected.to be_empty }
|
||||
end
|
||||
|
||||
context 'solo owner' do
|
||||
it { is_expected.to include(group) }
|
||||
|
||||
it 'avoids N+1 queries' do
|
||||
fresh_user = User.find(user.id)
|
||||
control_count = ActiveRecord::QueryRecorder.new do
|
||||
fresh_user.solo_owned_groups
|
||||
end.count
|
||||
|
||||
create(:group).add_owner(user)
|
||||
|
||||
expect { solo_owned_groups }.not_to exceed_query_limit(control_count)
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe "#recent_push" do
|
||||
let(:user) { build(:user) }
|
||||
let(:project) { build(:project) }
|
||||
|
|
|
|||
Loading…
Reference in a new issue