kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2020-11-26 03:09:17 +00:00
parent 9331523ddc
commit 846ebeb02e
18 changed files with 146 additions and 90 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
app/models/user.rb
View File

@ -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

5
changelogs/unreleased/cat-fix-nplus1-solo-owned-groups.yml Normal file
View File

@ -0,0 +1,5 @@
---
title: Fix N+1 when looking up user's solo owned groups
merge_request: 48340
author:
type: performance

1
doc/ci/multi_project_pipelines.md
View File

@ -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)**

4
doc/development/application_limits.md
View File

@ -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

26
doc/development/architecture.md
View File

@ -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)

8
doc/development/changelog.md
View File

@ -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:

4
doc/development/documentation/site_architecture/deployment_process.md
View File

@ -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.

10
doc/development/documentation/site_architecture/index.md
View File

@ -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)

24
doc/development/documentation/site_architecture/release_process.md
View File

@ -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

4
doc/development/gitaly.md
View File

@ -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

60
doc/development/migration_style_guide.md
View File

@ -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)

6
doc/development/pry_debugging.md
View File

@ -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

8
doc/development/python_guide/index.md
View File

@ -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.

16
doc/development/rake_tasks.md
View File

@ -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:

8
doc/development/redis.md
View File

@ -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.

2
doc/development/shell_commands.md
View File

@ -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

5
doc/subscriptions/gitlab_com/index.md
View File

@ -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

43
spec/models/user_spec.rb
View File

@ -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) }