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 2019-10-11 06:06:27 +00:00
parent 8c0166b981
commit b4e072cbaf
63 changed files with 352 additions and 378 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
app/controllers/groups_controller.rb
View File

@ -198,15 +198,13 @@ class GroupsController < Groups::ApplicationController
def load_events
params[:sort] ||= 'latest_activity_desc'
options = {}
options[:include_subgroups] = true
@projects = GroupProjectsFinder.new(params: params, group: group, options: options, current_user: current_user)
.execute
.includes(:namespace)
options = { include_subgroups: true }
projects = GroupProjectsFinder.new(params: params, group: group, options: options, current_user: current_user)
.execute
.includes(:namespace)
@events = EventCollection
.new(@projects, offset: params[:offset].to_i, filter: event_filter)
.new(projects, offset: params[:offset].to_i, filter: event_filter, groups: groups)
.to_a
Events::RenderService
@ -228,6 +226,14 @@ class GroupsController < Groups::ApplicationController
url_for(safe_params)
end
private
def groups
if @group.supports_events?
@group.self_and_descendants.public_or_visible_to_user(current_user)
end
end
end
GroupsController.prepend_if_ee('EE::GroupsController')

2
app/models/clusters/applications/cert_manager.rb
View File

@ -65,7 +65,7 @@ module Clusters
end
def retry_command(command)
"for i in $(seq 1 30); do #{command} && break; sleep 1s; echo \"Retrying ($i)...\"; done"
"for i in $(seq 1 30); do #{command} && break; sleep 1s; echo \"Retrying ($i)...\"; false; done"
end
def post_delete_script

9
app/models/event.rb
View File

@ -77,15 +77,6 @@ class Event < ApplicationRecord
scope :recent, -> { reorder(id: :desc) }
scope :code_push, -> { where(action: PUSHED) }
scope :in_projects, -> (projects) do
sub_query = projects
.except(:order)
.select(1)
.where('projects.id = events.project_id')
where('EXISTS (?)', sub_query).recent
end
scope :with_associations, -> do
# We're using preload for "push_event_payload" as otherwise the association
# is not always available (depending on the query being built).

43
app/models/event_collection.rb
View File

@ -6,6 +6,8 @@
# in a controller), it's not suitable for building queries that are used for
# building other queries.
class EventCollection
include Gitlab::Utils::StrongMemoize
# To prevent users from putting too much pressure on the database by cycling
# through thousands of events we put a limit on the number of pages.
MAX_PAGE = 10
@ -13,57 +15,52 @@ class EventCollection
# projects - An ActiveRecord::Relation object that returns the projects for
# which to retrieve events.
# filter - An EventFilter instance to use for filtering events.
def initialize(projects, limit: 20, offset: 0, filter: nil)
def initialize(projects, limit: 20, offset: 0, filter: nil, groups: nil)
@projects = projects
@limit = limit
@offset = offset
@filter = filter
@groups = groups
end
# Returns an Array containing the events.
def to_a
return [] if current_page > MAX_PAGE
relation = if Gitlab::Database.join_lateral_supported?
relation_with_join_lateral
relation = if groups
project_and_group_events
else
relation_without_join_lateral
relation_with_join_lateral('project_id', projects)
end
relation = paginate_events(relation)
relation.with_associations.to_a
end
private
# Returns the events relation to use when JOIN LATERAL is not supported.
#
# This relation simply gets all the events for all authorized projects, then
# limits that set.
def relation_without_join_lateral
events = filtered_events.in_projects(projects)
def project_and_group_events
project_events = relation_with_join_lateral('project_id', projects)
group_events = relation_with_join_lateral('group_id', groups)
paginate_events(events)
Event.from_union([project_events, group_events]).recent
end
# Returns the events relation to use when JOIN LATERAL is supported.
#
# This relation is built using JOIN LATERAL, producing faster queries than a
# regular LIMIT + OFFSET approach.
def relation_with_join_lateral
projects_for_lateral = projects.select(:id).to_sql
def relation_with_join_lateral(parent_column, parents)
parents_for_lateral = parents.select(:id).to_sql
lateral = filtered_events
.limit(limit_for_join_lateral)
.where('events.project_id = projects_for_lateral.id')
.where("events.#{parent_column} = parents_for_lateral.id") # rubocop:disable GitlabSecurity/SqlInjection
.to_sql
# The outer query does not need to re-apply the filters since the JOIN
# LATERAL body already takes care of this.
outer = base_relation
.from("(#{projects_for_lateral}) projects_for_lateral")
base_relation
.from("(#{parents_for_lateral}) parents_for_lateral")
.joins("JOIN LATERAL (#{lateral}) AS #{Event.table_name} ON true")
paginate_events(outer)
end
def filtered_events
@ -97,4 +94,10 @@ class EventCollection
def projects
@projects.except(:order)
end
def groups
strong_memoize(:groups) do
groups.except(:order) if @groups
end
end
end

4
app/models/group.rb
View File

@ -436,6 +436,10 @@ class Group < Namespace
members.owners.order_recent_sign_in.limit(ACCESS_REQUEST_APPROVERS_TO_BE_NOTIFIED_LIMIT)
end
def supports_events?
false
end
private
def update_two_factor_requirement

2
app/views/groups/_activities.html.haml
View File

@ -1,5 +1,5 @@
.nav-block.activities
= render 'shared/event_filter'
= render 'shared/event_filter', show_group_events: @group.supports_events?
.controls
= link_to group_path(@group, rss_url_options), class: 'btn d-none d-sm-inline-block has-tooltip' , title: 'Subscribe' do
%i.fa.fa-rss

4
app/views/shared/_event_filter.html.haml
View File

@ -1,3 +1,5 @@
- show_group_events = local_assigns.fetch(:show_group_events, false)
.scrolling-tabs-container.inner-page-scroll-tabs.is-smaller.flex-fill
.fade-left= icon('angle-left')
.fade-right= icon('angle-right')
@ -9,6 +11,8 @@
= event_filter_link EventFilter::MERGED, _('Merge events'), s_('EventFilterBy|Filter by merge events')
- if event_filter_visible(:issues)
= event_filter_link EventFilter::ISSUE, _('Issue events'), s_('EventFilterBy|Filter by issue events')
- if show_group_events
= render_if_exists 'events/epics_filter'
- if comments_visible?
= event_filter_link EventFilter::COMMENTS, _('Comments'), s_('EventFilterBy|Filter by comments')
= event_filter_link EventFilter::TEAM, _('Team'), s_('EventFilterBy|Filter by team')

5
changelogs/unreleased/not_silent_retry_failure.yml Normal file
View File

@ -0,0 +1,5 @@
---
title: Stopped CRD apply retrying from allowing silent failures
merge_request: 18421
author:
type: fixed

23
doc/administration/monitoring/prometheus/gitlab_exporter.md
View File

@ -1,12 +1,16 @@
# GitLab exporter
>**Note:**
Available since [Omnibus GitLab 8.17][1132]. For installations from source
you'll have to install and configure it yourself.
>- Available since [Omnibus GitLab 8.17](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1132).
>- Renamed from `GitLab monitor exporter` to `GitLab exporter` in [GitLab 12.3](https://gitlab.com/gitlab-org/gitlab/merge_requests/16511).
The [GitLab exporter] allows you to measure various GitLab metrics, pulled from Redis and the database.
The [GitLab exporter](https://gitlab.com/gitlab-org/gitlab-exporter) allows you to
measure various GitLab metrics, pulled from Redis and the database, in Omnibus GitLab
instances.
To enable the GitLab exporter:
NOTE: **Note:**
For installations from source you'll have to install and configure it yourself.
To enable the GitLab exporter in an Omnibus GitLab instance:
1. [Enable Prometheus](index.md#configuring-prometheus)
1. Edit `/etc/gitlab/gitlab.rb`
@ -16,15 +20,10 @@ To enable the GitLab exporter:
gitlab_exporter['enable'] = true
```
1. Save the file and [reconfigure GitLab][reconfigure] for the changes to
take effect
1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
for the changes to take effect
Prometheus will now automatically begin collecting performance data from
the GitLab exporter exposed under `localhost:9168`.
[← Back to the main Prometheus page](index.md)
[1132]: https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1132
[GitLab exporter]: https://gitlab.com/gitlab-org/gitlab-exporter
[prometheus]: https://prometheus.io
[reconfigure]: ../../restart_gitlab.md#omnibus-gitlab-reconfigure

5
doc/administration/monitoring/prometheus/gitlab_monitor_exporter.md Normal file
View File

@ -0,0 +1,5 @@
---
redirect_to: 'gitlab_exporter.md'
---
This document was moved to [another location](gitlab_exporter.md).

BIN
doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merge_request_pipeline.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.3 KiB

BIN
doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merged_result_pipeline_v12_3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 28 KiB

2
doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md
View File

@ -20,7 +20,7 @@ GitLab can run pipelines for merge requests
on this merged result. That is, where the source and target branches are combined into a
new ref and a pipeline for this ref validates the result prior to merging.
![Merge request pipeline as the head pipeline](img/merge_request_pipeline.png)
![Merge request pipeline as the head pipeline](img/merged_result_pipeline_v12_3.png)
There are some cases where creating a combined ref is not possible or not wanted.
For example, a source branch that has conflicts with the target branch

4
doc/ci/variables/predefined_variables.md
View File

@ -60,12 +60,12 @@ future GitLab releases.**
| `CI_MERGE_REQUEST_PROJECT_URL` | 11.6 | all | The URL of the project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) (e.g. `http://192.168.10.15:3000/namespace/awesome-project`). Available only if `only: [merge_requests]` is used and the merge request is created. |
| `CI_MERGE_REQUEST_REF_PATH` | 11.6 | all | The ref path of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). (e.g. `refs/merge-requests/1/head`). Available only if `only: [merge_requests]` is used and the merge request is created. |
| `CI_MERGE_REQUEST_SOURCE_BRANCH_NAME` | 11.6 | all | The source branch name of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. |
| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the source branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. |
| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the source branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used, the merge request is created, and the pipeline is a [merged result pipeline](../merge_request_pipelines/pipelines_for_merged_results/index.md). **(PREMIUM)** |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_ID` | 11.6 | all | The ID of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_PATH` | 11.6 | all | The path of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_URL` | 11.6 | all | The URL of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. |
| `CI_MERGE_REQUEST_TARGET_BRANCH_NAME` | 11.6 | all | The target branch name of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. |
| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the target branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. |
| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the target branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used, the merge request is created, and the pipeline is a [merged result pipeline](../merge_request_pipelines/pipelines_for_merged_results/index.md). **(PREMIUM)** |
| `CI_MERGE_REQUEST_TITLE` | 11.9 | all | The title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. |
| `CI_MERGE_REQUEST_ASSIGNEES` | 11.9 | all | Comma-separated list of username(s) of assignee(s) for the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. |
| `CI_MERGE_REQUEST_MILESTONE` | 11.9 | all | The milestone title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. |

9
doc/ci/yaml/README.md
View File

@ -3309,13 +3309,8 @@ all updated Merge Requests will have a pipeline created when using
If your commit message contains `[ci skip]` or `[skip ci]`, using any
capitalization, the commit will be created but the pipeline will be skipped.
Alternatively, one can pass the `ci.skip` [Git push option][push-option] if
using Git 2.10 or newer:
```sh
git push --push-option=ci.skip # using git 2.10+
git push -o ci.skip # using git 2.18+
```
Alternatively, one can pass the `ci.skip` [Git push option](../../user/project/push_options.md#push-options-for-gitlab-cicd)
if using Git 2.10 or newer.
<!-- ## Troubleshooting

24
doc/development/architecture.md
View File

@ -12,7 +12,7 @@ Both EE and CE require some add-on components called GitLab Shell and Gitaly. Th
## Components
A typical install of GitLab will be on GNU/Linux. It uses Nginx or Apache as a web front end to proxypass the Unicorn web server. By default, communication between Unicorn and the front end is via a Unix domain socket but forwarding requests via TCP is also supported. The web front end accesses `/home/git/gitlab/public` bypassing the Unicorn server to serve static pages, uploads (e.g. avatar images or attachments), and precompiled assets. GitLab serves web pages and a [GitLab API](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/doc/api) using the Unicorn web server. It uses Sidekiq as a job queue which, in turn, uses redis as a non-persistent database backend for job information, meta data, and incoming jobs.
A typical install of GitLab will be on GNU/Linux. It uses NGINX or Apache as a web front end to proxypass the Unicorn web server. By default, communication between Unicorn and the front end is via a Unix domain socket but forwarding requests via TCP is also supported. The web front end accesses `/home/git/gitlab/public` bypassing the Unicorn server to serve static pages, uploads (e.g. avatar images or attachments), and precompiled assets. GitLab serves web pages and the [GitLab API](../api/README.md) using the Unicorn web server. It uses Sidekiq as a job queue which, in turn, uses Redis as a non-persistent database backend for job information, meta data, and incoming jobs.
We also support deploying GitLab on Kubernetes using our [GitLab Helm chart](https://docs.gitlab.com/charts/).
@ -20,7 +20,7 @@ The GitLab web app uses PostgreSQL for persistent database information (e.g. use
When serving repositories over HTTP/HTTPS GitLab utilizes the GitLab API to resolve authorization and access as well as serving Git objects.
The add-on component GitLab Shell serves repositories over SSH. It manages the SSH keys within `/home/git/.ssh/authorized_keys` which should not be manually edited. GitLab Shell accesses the bare repositories through Gitaly to serve Git objects and communicates with redis to submit jobs to Sidekiq for GitLab to process. GitLab Shell queries the GitLab API to determine authorization and access.
The add-on component GitLab Shell serves repositories over SSH. It manages the SSH keys within `/home/git/.ssh/authorized_keys` which should not be manually edited. GitLab Shell accesses the bare repositories through Gitaly to serve Git objects and communicates with Redis to submit jobs to Sidekiq for GitLab to process. GitLab Shell queries the GitLab API to determine authorization and access.
Gitaly executes Git operations from GitLab Shell and the GitLab web app, and provides an API to the GitLab web app to get attributes from Git (e.g. title, branches, tags, other meta data), and to get blobs (e.g. diffs, commits, files).
@ -224,7 +224,7 @@ Gitaly is a service designed by GitLab to remove our need for NFS for Git storag
- Configuration: [Omnibus][geo-omnibus], [Charts][geo-charts], [GDK][geo-gdk]
- Layer: Core Service (Processor)
#### Gitlab Exporter
#### GitLab Exporter
- [Project page](https://gitlab.com/gitlab-org/gitlab-exporter)
- Configuration: [Omnibus][gitlab-exporter-omnibus], [Charts][gitlab-exporter-charts]
@ -258,7 +258,7 @@ GitLab CI is the open-source continuous integration service included with GitLab
- Configuration: [Omnibus][shell-omnibus], [Charts][shell-charts], [Source][shell-source], [GDK][gitlab-yml]
- Layer: Core Service (Processor)
[GitLab Shell](https://gitlab.com/gitlab-org/gitlab-shell) is a program designed at GitLab to handle ssh-based `git` sessions, and modifies the list of authorized keys. GitLab Shell is not a Unix shell nor a replacement for Bash or Zsh.
[GitLab Shell](https://gitlab.com/gitlab-org/gitlab-shell) is a program designed at GitLab to handle SSH-based `git` sessions, and modifies the list of authorized keys. GitLab Shell is not a Unix shell nor a replacement for Bash or Zsh.
#### GitLab Workhorse
@ -317,7 +317,7 @@ MinIO is an object storage server released under Apache License v2.0. It is comp
- Layer: Core Service (Processor)
- Process: `nginx`
Nginx as an ingress port for all HTTP requests and routes them to the appropriate sub-systems within GitLab. We are bundling an unmodified version of the popular open source webserver.
NGINX has an Ingress port for all HTTP requests and routes them to the appropriate sub-systems within GitLab. We are bundling an unmodified version of the popular open source webserver.
#### Node Exporter
@ -344,7 +344,7 @@ Lightweight connection pooler for PostgreSQL.
Prometheus exporter for PgBouncer. Exports metrics at 9127/metrics.
#### Postgresql
#### PostgreSQL
- [Project page](https://github.com/postgres/postgres/blob/master/README)
- Configuration: [Omnibus][postgres-omnibus], [Charts][postgres-charts], [Source][postgres-source]
@ -400,7 +400,7 @@ Redis is packaged to provide a place to store:
- Layer: Core Service (Processor)
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.
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
@ -424,7 +424,7 @@ Sentry fundamentally is a service that helps you monitor and fix crashes in real
- Layer: Core Service (Processor)
- Process: `sidekiq`
Sidekiq is a Ruby background job processor that pulls jobs from the redis queue and processes them. Background jobs allow GitLab to provide a faster request/response cycle by moving work into the background.
Sidekiq is a Ruby background job processor that pulls jobs from the Redis queue and processes them. Background jobs allow GitLab to provide a faster request/response cycle by moving work into the background.
#### Unicorn
@ -470,9 +470,9 @@ It's important to understand the distinction as some processes are used in both
When making a request to an HTTP Endpoint (think `/users/sign_in`) the request will take the following path through the GitLab Service:
- nginx - Acts as our first line reverse proxy.
- 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 Unicorn.
- unicorn - Since this is a web request, and it needs to access the application it will go to Unicorn.
- Unicorn - Since this is a web request, and it needs to access the application it will go to Unicorn.
- Postgres/Gitaly/Redis - Depending on the type of request, it may hit these services to store or retrieve data.
### GitLab Git Request Cycle
@ -508,7 +508,7 @@ ps aux | grep '^git'
```
GitLab has several components to operate. It requires a persistent database
(PostgreSQL) and redis database, and uses Apache httpd or Nginx to proxypass
(PostgreSQL) and Redis database, and uses Apache httpd or NGINX to proxypass
Unicorn. All these components should run as different system users to GitLab
(e.g., `postgres`, `redis` and `www-data`, instead of `git`).
@ -580,7 +580,7 @@ SSH:
- `/var/log/auth.log` auth log (on Ubuntu).
- `/var/log/secure` auth log (on RHEL).
nginx:
NGINX:
- `/var/log/nginx/` contains error and access logs.

2
doc/development/changelog.md
View File

@ -79,7 +79,7 @@ changes.
- **Bad:** Strip out `nil`s in the Array of Commit objects returned from
`find_commits_by_message_with_elastic`
- **Good:** Fix 500 errors caused by elasticsearch results referencing
- **Good:** Fix 500 errors caused by Elasticsearch results referencing
garbage-collected commits
The first example focuses on _how_ we fixed something, not on _what_ it fixes.

2
doc/development/database_debugging.md
View File

@ -3,7 +3,7 @@
This section is to help give some copy-pasta you can use as a reference when you
run into some head-banging database problems.
An easy first step is to search for your error in Slack or google "GitLab (my error)".
An easy first step is to search for your error in Slack, or search for `GitLab <my error>` with Google.
---

2
doc/development/documentation/improvement-workflow.md
View File

@ -20,7 +20,7 @@ to accomplish their work with GitLab.
## How to update the docs
1. Click "Edit this Page" at the bottom of any page on docs.gitlab.com, or navigate to
1. Click "Edit this Page" at the bottom of any page on <https://docs.gitlab.com>, or navigate to
one of the repositories and doc paths listed on the [GitLab Documentation guidelines](index.md) page.
Work in a fork if you do not have developer access to the GitLab project.
1. Follow the described standards and processes listed on that Guidelines page,

28
doc/development/documentation/index.md
View File

@ -8,19 +8,18 @@ GitLab's documentation is [intended as the single source of truth (SSOT)](https:
In addition to this page, the following resources can help you craft and contribute documentation:
- [Style Guide](styleguide.md) - What belongs in the docs, language guidelines, and more.
- [Style Guide](styleguide.md) - What belongs in the docs, language guidelines, Markdown standards to follow, and more.
- [Structure and template](structure.md) - Learn the typical parts of a doc page and how to write each one.
- [Workflows](workflow.md) - A landing page for our key workflows:
- [Documentation process for feature changes](feature-change-workflow.md) - Adding required documentation when developing a GitLab feature.
- [Documentation improvement workflow](improvement-workflow.md) - New content not associated with a new feature.
- [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/) - A reference for the markdown implementation used by GitLab's documentation site and about.gitlab.com.
- [Site architecture](site_architecture/index.md) - How docs.gitlab.com is built.
- [Markdown Guide](../../user/markdown.md) - A reference for all markdown syntax supported by GitLab.
- [Site architecture](site_architecture/index.md) - How <http://docs.gitlab.com> is built.
## Source files and rendered web locations
Documentation for GitLab, GitLab Runner, and Omnibus is published to [docs.gitlab.com](https://docs.gitlab.com). Documentation for GitLab is also published within the application at `/help` on the domain of the GitLab instance.
At `/help`, only help for your current edition and version is included. Help for other versions is available at docs.gitlab.com.
Documentation for GitLab, GitLab Runner, Omnibus GitLab and Charts are published to <https://docs.gitlab.com>. Documentation for GitLab is also published within the application at `/help` on the domain of the GitLab instance.
At `/help`, only help for your current edition and version is included. Help for other versions is available at <https://docs.gitlab.com/archives/>.
The source of the documentation exists within the codebase of each GitLab application in the following repository locations:
@ -29,6 +28,7 @@ The source of the documentation exists within the codebase of each GitLab applic
| [GitLab](https://gitlab.com/gitlab-org/gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/gitlab/tree/master/doc) |
| [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/) | [`/docs`](https://gitlab.com/gitlab-org/gitlab-runner/tree/master/docs) |
| [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/gitlab/tree/master/doc) |
| [Charts](https://gitlab.com/gitlab-org/charts/gitlab) | [`/doc`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/doc) |
Documentation issues and merge requests are part of their respective repositories and all have the label `Documentation`.
@ -55,8 +55,8 @@ See the [Structure](styleguide.md#structure) section of the [Documentation Style
Changing a document's location requires specific steps to ensure that
users can seamlessly access the new doc page, whether they are accessing content
on a GitLab instance domain at `/help` or at docs.gitlab.com. Be sure to ping a
GitLab technical writer if you have any questions during the process (such as
on a GitLab instance domain at `/help` or at <https://docs.gitlab.com>. Be sure to assign a
technical writer if you have any questions during the process (such as
whether the move is necessary), and ensure that a technical writer reviews this
change prior to merging.
@ -132,7 +132,7 @@ land on the doc via `/help`.
If the documentation page being relocated already has Disqus comments,
we need to preserve the Disqus thread.
Disqus uses an identifier per page, and for docs.gitlab.com, the page identifier
Disqus uses an identifier per page, and for <https://docs.gitlab.com>, the page identifier
is configured to be the page URL. Therefore, when we change the document location,
we need to preserve the old URL as the same Disqus identifier.
@ -181,9 +181,9 @@ Every GitLab instance includes the documentation, which is available at `/help`
(`https://gitlab.example.com/help`). For example, <https://gitlab.com/help>.
There are [plans](https://gitlab.com/groups/gitlab-org/-/epics/693) to end this
practice and instead link out from the GitLab application to docs.gitlab.com URLs.
practice and instead link out from the GitLab application to <https://docs.gitlab.com> URLs.
The documentation available online on docs.gitlab.com is continuously
The documentation available online on <https://docs.gitlab.com> is continuously
deployed every hour from the `master` branch of GitLab, Omnibus, and Runner. Therefore,
once a merge request gets merged, it will be available online on the same day.
However, they will be shipped (and available on `/help`) within the milestone assigned
@ -195,7 +195,7 @@ available online on 2018-09-15, but, as the feature freeze date has passed, if
the MR does not have a "pick into 11.3" label, the milestone has to be changed
to 11.4 and it will be shipped with all GitLab packages only on 2018-10-22,
with GitLab 11.4. Meaning, it will only be available under `/help` from GitLab
11.4 onwards, but available on docs.gitlab.com on the same day it was merged.
11.4 onwards, but available on <https://docs.gitlab.com/archives/> on the same day it was merged.
### Linking to `/help`
@ -271,7 +271,7 @@ For example, [GitLab.com's `/help`](https://gitlab.com/help).
## Docs site architecture
See the [Docs site architecture](site_architecture/index.md) page to learn
how we build and deploy the site at [docs.gitlab.com](https://docs.gitlab.com) and
how we build and deploy the site at <https://docs.gitlab.com> and
to review all the assets and libraries in use.
### Global navigation
@ -301,7 +301,7 @@ You will need to push a branch to those repositories, it doesn't work for forks.
The `review-docs-deploy*` job will:
1. Create a new branch in the [gitlab-docs](https://gitlab.com/gitlab-org/gitlab-docs)
1. Create a new branch in the [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs)
project named after the scheme: `$DOCS_GITLAB_REPO_SUFFIX-$CI_ENVIRONMENT_SLUG`,
where `DOCS_GITLAB_REPO_SUFFIX` is the suffix for each product, e.g, `ce` for
CE, etc.

22
doc/development/documentation/styleguide.md
View File

@ -564,7 +564,7 @@ Inside the document:
### Remove image shadow
All images displayed on docs.gitlab.com have a box shadow by default.
All images displayed on the [GitLab Docs site](https://docs.gitlab.com) have a box shadow by default.
To remove the box shadow, use the image class `.image-noshadow` applied
directly to an HTML `img` tag:
@ -598,7 +598,7 @@ You can link any up-to-date video that is useful to the GitLab user.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/472) in GitLab 12.1.
GitLab docs (docs.gitlab.com) support embedded videos.
The [GitLab docs site](https://docs.gitlab.com) supports embedded videos.
You can only embed videos from
[GitLab's official YouTube account](https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg).
@ -634,7 +634,7 @@ leave a blank line here
leave a blank line here
```
This is how it renders on docs.gitlab.com:
This is how it renders on the GitLab Docs site:
<div class="video-fallback">
See the video: <a href="https://www.youtube.com/watch?v=enMumwvLAug">What is GitLab</a>.
@ -693,6 +693,10 @@ use the following markup for highlighting.
_Note that the alert boxes only work for one paragraph only. Multiple paragraphs,
lists, headers, etc will not render correctly. For multiple lines, use blockquotes instead._
Alert boxes only render properly on the GitLab Docs site (<http://docs.gitlab.com>).
Within GitLab itself, they will appear as plain markdown text (like the examples
above the rendered versions, below).
### Note
Notes catch the eye of most readers, and therefore should be used very sparingly.
@ -717,7 +721,7 @@ NOTE: **Note:**
This is something to note.
```
How it renders in docs.gitlab.com:
How it renders on the GitLab Docs site:
NOTE: **Note:**
This is something to note.
@ -729,7 +733,7 @@ TIP: **Tip:**
This is a tip.
```
How it renders in docs.gitlab.com:
How it renders on the GitLab Docs site:
TIP: **Tip:**
This is a tip.
@ -741,7 +745,7 @@ CAUTION: **Caution:**
This is something to be cautious about.
```
How it renders in docs.gitlab.com:
How it renders on the GitLab Docs site:
CAUTION: **Caution:**
This is something to be cautious about.
@ -753,7 +757,7 @@ DANGER: **Danger:**
This is a breaking change, a bug, or something very important to note.
```
How it renders in docs.gitlab.com:
How it renders on the GitLab Docs site:
DANGER: **Danger:**
This is a breaking change, a bug, or something very important to note.
@ -766,7 +770,7 @@ For highlighting a text within a blue blockquote, use this format:
> This is a blockquote.
```
which renders in docs.gitlab.com to:
which renders on the [GitLab Docs site](https://docs.gitlab.com) as:
> This is a blockquote.
@ -1154,7 +1158,7 @@ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --form "title=
```
The above example is run by and administrator and will add an SSH public key
titled ssh-key to user's account which has an id of 25.
titled `ssh-key` to user's account which has an id of 25.
#### Escape special characters

7
doc/development/elasticsearch.md
View File

@ -1,8 +1,9 @@
# Elasticsearch knowledge **(STARTER ONLY)**
This area is to maintain a compendium of useful information when working with elasticsearch.
This area is to maintain a compendium of useful information when working with Elasticsearch.
Information on how to enable Elasticsearch and perform the initial indexing is kept in ../integration/elasticsearch.md#enabling-elasticsearch
Information on how to enable Elasticsearch and perform the initial indexing is in
the [Elasticsearch integration documentation](../integration/elasticsearch.md#enabling-elasticsearch)
## Deep Dive
@ -61,7 +62,7 @@ Additionally, if you need large repos or multiple forks for testing, please cons
The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_versioned_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_versioned_search.rb).
All indexing after the initial one is done via `ElasticIndexerWorker` (sidekiq jobs).
All indexing after the initial one is done via `ElasticIndexerWorker` (Sidekiq jobs).
Search queries are generated by the concerns found in [ee/app/models/concerns/elastic](https://gitlab.com/gitlab-org/gitlab/tree/master/ee/app/models/concerns/elastic). These concerns are also in charge of access control, and have been a historic source of security bugs so please pay close attention to them!

6
doc/development/event_tracking/frontend.md
View File

@ -1,6 +1,6 @@
# Frontend tracking guide
GitLab provides `Tracking`, an interface that wraps the [Snowplow Javascript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to utilizing tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy).
GitLab provides `Tracking`, an interface that wraps the [Snowplow JavaScript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to utilizing tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy).
| field | type | default value | description |
|:-----------|:-------|:---------------------------|:------------|
@ -26,7 +26,7 @@ Below is an example of `data-track-*` attributes assigned to a button:
/>
```
Event listeners are bound at the document level to handle click events on or within elements with these data attributes. This allows for them to be properly handled on rerendering and changes to the DOM, but it's important to know that because of the way these events are bound, click events shouldn't be stopped from propagating up the DOM tree. If for any reason click events are being stopped from propagating, you'll need to implement your own listeners and follow the instructions in [Tracking in raw Javascript](#tracking-in-raw-javascript).
Event listeners are bound at the document level to handle click events on or within elements with these data attributes. This allows for them to be properly handled on rerendering and changes to the DOM, but it's important to know that because of the way these events are bound, click events shouldn't be stopped from propagating up the DOM tree. If for any reason click events are being stopped from propagating, you'll need to implement your own listeners and follow the instructions in [Tracking in raw JavaScript](#tracking-in-raw-javascript).
Below is a list of supported `data-track-*` attributes:
@ -99,7 +99,7 @@ And if needed within the template, you can use the `track` method directly as we
</template>
```
## Tracking in raw Javascript
## Tracking in raw JavaScript
Custom event tracking and instrumentation can be added by directly calling the `Tracking.event` static function. The following example demonstrates tracking a click on a button by calling `Tracking.event` manually.

2
doc/development/fe_guide/components.md
View File

@ -8,7 +8,7 @@
See also the [corresponding UX guide](https://design.gitlab.com/#/components/dropdowns).
### How to style a bootstrap dropdown
### How to style a Bootstrap dropdown
1. Use the HTML structure provided by the [docs][bootstrap-dropdowns]
1. Add a specific class to the top level `.dropdown` element

2
doc/development/fe_guide/development_process.md
View File

@ -80,7 +80,7 @@ With the purpose of being [respectful of others' time](https://about.gitlab.com/
1. Before writing code, ensure your vision of the architecture is aligned with
GitLab's architecture.
1. Add a diagram to the issue and ask a frontend maintainer in the slack channel `#frontend_maintainers` about it.
1. Add a diagram to the issue and ask a frontend maintainer in the Slack channel `#frontend_maintainers` about it.
![Diagram of Issue Boards Architecture](img/boards_diagram.png)

2
doc/development/fe_guide/icons.md
View File

@ -1,6 +1,6 @@
# Icons and SVG Illustrations
We manage our own Icon and Illustration library in the [gitlab-svgs][gitlab-svgs] repository.
We manage our own Icon and Illustration library in the [`gitlab-svgs`][gitlab-svgs] repository.
This repository is published on [npm][npm] and managed as a dependency via yarn.
You can browse all available Icons and Illustrations [here][svg-preview].
To upgrade to a new version run `yarn upgrade @gitlab/svgs`.

23
doc/development/fe_guide/performance.md
View File

@ -65,26 +65,27 @@ within the `pages` directory correspond to Rails controllers and actions. These
auto-generated bundles will be automatically included on the corresponding
pages.
For example, if you were to visit [gitlab.com/gitlab-org/gitlab-foss/issues](https://gitlab.com/gitlab-org/gitlab-foss/issues),
For example, if you were to visit <https://gitlab.com/gitlab-org/gitlab/issues>,
you would be accessing the `app/controllers/projects/issues_controller.rb`
controller with the `index` action. If a corresponding file exists at
`pages/projects/issues/index/index.js`, it will be compiled into a webpack
bundle and included on the page.
> **Note:** Previously we had encouraged the use of
> `content_for :page_specific_javascripts` within haml files, along with
> manually generated webpack bundles. However under this new system you should
> not ever need to manually add an entry point to the `webpack.config.js` file.
>
> **Tip:**
> If you are unsure what controller and action corresponds to a given page, you
> can find this out by inspecting `document.body.dataset.page` within your
> browser's developer console while on any page within gitlab.
NOTE: **Note:**
Previously we had encouraged the use of
`content_for :page_specific_javascripts` within haml files, along with
manually generated webpack bundles. However under this new system you should
not ever need to manually add an entry point to the `webpack.config.js` file.
TIP: **Tip:**
If you are unsure what controller and action corresponds to a given page, you
can find this out by inspecting `document.body.dataset.page` within your
browser's developer console while on any page within GitLab.
#### Important Considerations
- **Keep Entry Points Lite:**
Page-specific javascript entry points should be as lite as possible. These
Page-specific JavaScript entry points should be as lite as possible. These
files are exempt from unit tests, and should be used primarily for
instantiation and dependency injection of classes and methods that live in
modules outside of the entry point script. Just import, read the DOM,

2
doc/development/fe_guide/security.md
View File

@ -63,7 +63,7 @@ External fonts, CSS, and JavaScript should never be used with the exception of
Google Analytics and Piwik - and only when the instance has enabled it. Assets
should always be hosted and served locally from the GitLab instance. Embedded
resources via `iframes` should never be used except in certain circumstances
such as with ReCaptcha, which cannot be used without an `iframe`.
such as with reCAPTCHA, which cannot be used without an `iframe`.
## Avoiding inline scripts and styles

4
doc/development/fe_guide/style_guide_js.md
View File

@ -287,7 +287,7 @@ See [our current .eslintrc](https://gitlab.com/gitlab-org/gitlab/blob/master/.es
#### CSS classes used for JavaScript
1. If the class is being used in Javascript it needs to be prepend with `js-`
1. If the class is being used in JavaScript it needs to be prepend with `js-`
```html
// bad
@ -693,7 +693,7 @@ Useful links:
$('span').tooltip('_fixTitle');
```
### The Javascript/Vue Accord
### The JavaScript/Vue Accord
The goal of this accord is to make sure we are all on the same page.

4
doc/development/feature_flags/controls.md
View File

@ -3,7 +3,7 @@
In order to be able to turn on/off features behind feature flags in any of the
GitLab Inc. provided environments such as staging and production, you need to
have access to the chatops bot. Chatops bot is currently running on the ops instance,
which is different from GitLab.com or dev.gitlab.org.
which is different from <https://gitlab.com> or <https://dev.gitlab.org>.
Follow the Chatops document to [request access](../chatops_on_gitlabcom.md#requesting-access).
@ -39,7 +39,7 @@ If you get an error "Whoops! This action is not allowed. This incident
will be reported." that means your Slack account is not allowed to
change feature flags or you do not [have access](#access-for-enabling-a-feature-flag-in-production).
### Enabling feature for staging and dev.gitlab.org
### Enabling feature for internal testing
As a first step in a feature rollout, you should enable the feature on <https://staging.gitlab.com>
and <https://dev.gitlab.org>.

14
doc/development/gitaly.md
View File

@ -15,9 +15,9 @@ In May 2019, Bob Van Landuyt hosted a [Deep Dive] on GitLab's [Gitaly project] a
## Beginner's guide
Start by reading the gitaly repository's
Start by reading the Gitaly repository's
[Beginner's guide to Gitaly contributions](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/beginners_guide.md).
It describes how to setup gitaly, the various components of gitaly and what they do, and how to run its test suites.
It describes how to setup Gitaly, the various components of Gitaly and what they do, and how to run its test suites.
## Developing new Git features
@ -41,14 +41,14 @@ disk access (e.g. Rugged, `git`, `rm -rf`) anywhere outside
The process for adding new Gitaly features is:
- exploration / prototyping
- design and create a new Gitaly RPC [in gitaly-proto](https://gitlab.com/gitlab-org/gitaly-proto)
- release a new version of gitaly-proto
- design and create a new Gitaly RPC in [`gitaly-proto`](https://gitlab.com/gitlab-org/gitaly-proto)
- release a new version of `gitaly-proto`
- write implementation and tests for the RPC [in Gitaly](https://gitlab.com/gitlab-org/gitaly), in Go or Ruby
- release a new version of Gitaly
- write client code in GitLab CE/EE, GitLab Workhorse or GitLab Shell that calls the new Gitaly RPC
These steps often overlap. It is possible to use an unreleased version
of Gitaly and gitaly-proto during testing and development.
of Gitaly and `gitaly-proto` during testing and development.
- See the [Gitaly repo](https://gitlab.com/gitlab-org/gitaly/blob/master/CONTRIBUTING.md#development-and-testing-with-a-custom-gitaly-proto) for instructions on writing server side code with an unreleased protocol.
- See [below](#running-tests-with-a-locally-modified-version-of-gitaly) for instructions on running GitLab CE tests with a modified version of Gitaly.
@ -58,7 +58,7 @@ of Gitaly and gitaly-proto during testing and development.
It is possible to implement and test RPC's in Gitaly using Ruby code,
in
[gitaly-ruby](https://gitlab.com/gitlab-org/gitaly/tree/master/ruby).
[`gitaly-ruby`](https://gitlab.com/gitlab-org/gitaly/tree/master/ruby).
This should make it easier to contribute for developers who are less
comfortable writing Go code.
@ -234,7 +234,7 @@ Here are the steps to gate a new feature in Gitaly behind a feature flag.
}
```
1. Create prometheus metrics:
1. Create Prometheus metrics:
```go
var findAllTagsRequests = prometheus.NewCounterVec(

2
doc/development/i18n/index.md
View File

@ -29,7 +29,7 @@ See [Externalization for GitLab](externalization.md).
### Translate strings
The translation process is managed at [translate.gitlab.com](https://translate.gitlab.com)
The translation process is managed at <https://translate.gitlab.com>
using [Crowdin](https://crowdin.com/).
You will need to create an account before you can submit translations.
Once you are signed in, select the language you wish to contribute translations to.

2
doc/development/i18n/proofreader.md
View File

@ -57,7 +57,7 @@ are very appreciative of the work done by translators and proofreaders!
- Paolo Falomo - [GitLab](https://gitlab.com/paolofalomo), [Crowdin](https://crowdin.com/profile/paolo.falomo)
- Japanese
- Hiroyuki Sato - [GitLab](https://gitlab.com/hiroponz), [Crowdin](https://crowdin.com/profile/hiroponz)
- Tomo Dote - [Gitlab](https://gitlab.com/fu7mu4), [Crowdin](https://crowdin.com/profile/fu7mu4)
- Tomo Dote - [GitLab](https://gitlab.com/fu7mu4), [Crowdin](https://crowdin.com/profile/fu7mu4)
- Korean
- Chang-Ho Cha - [GitLab](https://gitlab.com/changho-cha), [Crowdin](https://crowdin.com/profile/zzazang)
- Ji Hun Oh - [GitLab](https://gitlab.com/Baw-Appie), [Crowdin](https://crowdin.com/profile/BawAppie)

4
doc/development/i18n/translation.md
View File

@ -8,7 +8,7 @@ The first step is to get familiar with Crowdin.
### Sign In
To contribute translations at [translate.gitlab.com](https://translate.gitlab.com)
To contribute translations at <https://translate.gitlab.com>
you must create a Crowdin account.
You may create a new account or use any of their supported sign in services.
@ -54,7 +54,7 @@ For example in French `OpenedNDaysAgo|Opened` would be translated to
Some technical terms should be treated like proper nouns and not be translated.
Technical terms that should always be in English are noted in the glossary when
using [translate.gitlab.com](https://translate.gitlab.com).
using <https://translate.gitlab.com>.
This helps maintain a logical connection and consistency between tools (e.g.
`git` client) and GitLab.

2
doc/development/import_export.md
View File

@ -36,7 +36,7 @@ SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS = 3000000
SIDEKIQ_MEMORY_KILLER_GRACE_TIME = 900
```
An import status `started`, and the following sidekiq logs will signal a memory issue:
An import status `started`, and the following Sidekiq logs will signal a memory issue:
```bash
WARN: Work still in progress <struct with JID>

2
doc/development/interacting_components.md
View File

@ -14,7 +14,7 @@ change that affects uploads should also be tested against [object storage],
which is _not_ enabled by default in [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit).
When working on a related feature, make sure to enable and test it
against [Minio](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/object_storage.md).
against [MinIO](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/object_storage.md).
See also [File Storage in GitLab](file_storage.md).

5
doc/development/kubernetes.md
View File

@ -44,12 +44,11 @@ to the relevant internal client.
All calls to the Kubernetes API must be in a background process. Do not
perform Kubernetes API calls within a web request as this will block
unicorn and can easily lead to a Denial Of Service (DoS) attack in GitLab as
Unicorn and can easily lead to a Denial Of Service (DoS) attack in GitLab as
the Kubernetes cluster response times are outside of our control.
The easiest way to ensure your calls happen a background process is to
delegate any such work to happen in a [sidekiq
worker](sidekiq_style_guide.md).
delegate any such work to happen in a [Sidekiq worker](sidekiq_style_guide.md).
There are instances where you would like to make calls to Kubernetes and
return the response and as such a background worker does not seem to be

2
doc/development/new_fe_guide/development/components.md
View File

@ -7,7 +7,7 @@ We have a lot of graphing libraries in our codebase to render graphs. In an effo
We chose D3 as our library going forward because of the following features:
- [Tree shaking webpack capabilities](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40).
- [Compatible with vue.js as well as vanilla javascript](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40).
- [Compatible with vue.js as well as vanilla JavaScript](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40).
D3 is very popular across many projects outside of GitLab:

4
doc/development/new_fe_guide/development/performance.md
View File

@ -2,9 +2,9 @@
## Monitoring
We have a performance dashboard available in one of our [grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated.
We have a performance dashboard available in one of our [Grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated.
These pages can be found inside a text file in the gitlab-build-images [repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [gitlab.txt](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
These pages can be found inside a text file in the [`gitlab-build-images` repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [`gitlab.txt`](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing urls of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team/) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`.
There are 3 recommended high impact metrics to review on each page:

2
doc/development/sidekiq_style_guide.md
View File

@ -27,7 +27,7 @@ While different workers cannot share a queue, they can share a queue namespace.
Defining a queue namespace for a worker makes it possible to start a Sidekiq
process that automatically handles jobs for all workers in that namespace,
without needing to explicitly list all their queue names. If, for example, all
workers that are managed by sidekiq-cron use the `cronjob` queue namespace, we
workers that are managed by `sidekiq-cron` use the `cronjob` queue namespace, we
can spin up a Sidekiq process specifically for these kinds of scheduled jobs.
If a new worker using the `cronjob` namespace is added later on, the Sidekiq
process will automatically pick up jobs for that worker too (after having been

10
doc/development/testing_guide/best_practices.md
View File

@ -113,7 +113,7 @@ Finished in 34.51 seconds (files took 0.76702 seconds to load)
1 example, 0 failures
```
Note: `live_debug` only works on javascript enabled specs.
Note: `live_debug` only works on JavaScript enabled specs.
#### Run `:js` spec in a visible browser
@ -158,7 +158,7 @@ really fast since:
- Gems loading is skipped
- Rails app boot is skipped
- gitlab-shell and Gitaly setup are skipped
- GitLab Shell and Gitaly setup are skipped
- Test repositories setup are skipped
`fast_spec_helper` also support autoloading classes that are located inside the
@ -347,7 +347,7 @@ them unspecified, and look up the value after the row is created.
#### Redis
GitLab stores two main categories of data in Redis: cached items, and sidekiq
GitLab stores two main categories of data in Redis: cached items, and Sidekiq
jobs.
In most specs, the Rails cache is actually an in-memory store. This is replaced
@ -587,9 +587,9 @@ All fixtures should be placed under `spec/fixtures/`.
### Repositories
Testing some functionality, e.g., merging a merge request, requires a git
Testing some functionality, e.g., merging a merge request, requires a Git
repository with a certain state to be present in the test environment. GitLab
maintains the [gitlab-test](https://gitlab.com/gitlab-org/gitlab-test)
maintains the [`gitlab-test`](https://gitlab.com/gitlab-org/gitlab-test)
repository for certain common cases - you can ensure a copy of the repository is
used with the `:repository` trait for project factories:

2
doc/development/testing_guide/end_to_end/page_objects.md
View File

@ -2,7 +2,7 @@
In GitLab QA we are using a known pattern, called _Page Objects_.
This means that we have built an abstraction for all GitLab pages that we use
This means that we have built an abstraction for all pages in GitLab that we use
to drive GitLab QA scenarios. Whenever we do something on a page, like filling
in a form, or clicking a button, we do that only through a page object
associated with this area of GitLab.

2
doc/development/testing_guide/flaky_tests.md
View File

@ -61,7 +61,7 @@ This was originally implemented in: <https://gitlab.com/gitlab-org/gitlab-foss/m
- [Capybara.reset_session! should be called before requests are blocked](https://gitlab.com/gitlab-org/gitlab-foss/issues/33779): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12224>
- FFaker generates funky data that tests are not ready to handle (and tests should be predictable so that's bad!):
- [Make `spec/mailers/notify_spec.rb` more robust](https://gitlab.com/gitlab-org/gitlab-foss/issues/20121): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10015>
- [Transient failure in spec/requests/api/commits_spec.rb](https://gitlab.com/gitlab-org/gitlab-foss/issues/27988#note_25342521): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/9944>
- [Transient failure in `spec/requests/api/commits_spec.rb`](https://gitlab.com/gitlab-org/gitlab-foss/issues/27988#note_25342521): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/9944>
- [Replace FFaker factory data with sequences](https://gitlab.com/gitlab-org/gitlab-foss/issues/29643): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10184>
- [Transient failure in spec/finders/issues_finder_spec.rb](https://gitlab.com/gitlab-org/gitlab-foss/issues/30211#note_26707685): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10404>

2
doc/development/testing_guide/frontend_testing.md
View File

@ -482,7 +482,7 @@ As long as the fixtures don't change, `yarn test` is sufficient (and saves you s
While developing locally, it may be helpful to keep Karma running so that you
can get instant feedback on as you write tests and modify code. To do this
you can start Karma with `yarn run karma-start`. It will compile the javascript
you can start Karma with `yarn run karma-start`. It will compile the JavaScript
assets and run a server at `http://localhost:9876/` where it will automatically
run the tests on any browser which connects to it. You can enter that url on
multiple browsers at once to have it run the tests on each in parallel.

4
doc/development/testing_guide/review_apps.md
View File

@ -142,7 +142,7 @@ their node under pressure.
### Log into my Review App
The default username is `root` and its password can be found in the 1Password
secure note named **gitlab-{ce,ee} Review App's root password**.
secure note named `gitlab-{ce,ee} Review App's root password`.
### Enable a feature flag for my Review App
@ -235,7 +235,7 @@ For the record, the debugging steps to find out this issue were:
1. Switch kubectl context to review-apps-ce (we recommend using [kubectx](https://github.com/ahmetb/kubectx/))
1. `kubectl get pods | grep dns`
1. `kubectl describe pod <pod name>` & confirm exact error message
1. Web search for exact error message, following rabbit hole to [a relevant kubernetes bug report](https://github.com/kubernetes/kubernetes/issues/57345)
1. Web search for exact error message, following rabbit hole to [a relevant Kubernetes bug report](https://github.com/kubernetes/kubernetes/issues/57345)
1. Access the node over SSH via the GCP console (**Computer Engine > VM
instances** then click the "SSH" button for the node where the `dns-gitlab-review-app-external-dns` pod runs)
1. In the node: `systemctl --version` => systemd 232

18
doc/development/uploads.md
View File

@ -82,7 +82,7 @@ To address this problem an HA object storage can be used and it's supported by [
Scaling NFS is outside of our support scope, and NFS is not a part of cloud native installations.
All features that require sidekiq and do not use object storage acceleration won't work without NFS. In Kubernetes, machine boundaries translate to PODs, and in this case the uploaded file will be written into the POD private disk. Since sidekiq POD cannot reach into other pods, the operation will fail to read it.
All features that require Sidekiq and do not use object storage acceleration won't work without NFS. In Kubernetes, machine boundaries translate to PODs, and in this case the uploaded file will be written into the POD private disk. Since Sidekiq POD cannot reach into other pods, the operation will fail to read it.
## How to select the proper level of acceleration?
@ -92,19 +92,19 @@ We can identify three major use-cases for an upload:
1. **storage:** if we are uploading for storing a file (i.e. artifacts, packages, discussion attachments). In this case [object storage acceleration](#workhorse-object-storage-acceleration) is the proper level as it's the less resource-intensive operation. Additional information can be found on [File Storage in GitLab](file_storage.md).
1. **in-controller/synchronous processing:** if we allow processing **small files** synchronously, using [disk acceleration](#workhorse-disk-acceleration) may speed up development.
1. **sidekiq/asynchronous processing:** Async processing must implement [object storage acceleration](#workhorse-object-storage-acceleration), the reason being that it's the only way to support Cloud Native deployments without a shared NFS.
1. **Sidekiq/asynchronous processing:** Async processing must implement [object storage acceleration](#workhorse-object-storage-acceleration), the reason being that it's the only way to support Cloud Native deployments without a shared NFS.
For more details about currently broken feature see [epic &1802](https://gitlab.com/groups/gitlab-org/-/epics/1802).
### Handling repository uploads
Some features involves git repository uploads without using a regular git client.
Some features involves Git repository uploads without using a regular Git client.
Some examples are uploading a repository file from the web interface and [design management](../user/project/issues/design_management.md).
Those uploads requires the rails controller to act as a git client in lieu of the user.
Those uploads requires the rails controller to act as a Git client in lieu of the user.
Those operation falls into _in-controller/synchronous processing_ category, but we have no warranties on the file size.
In case of a LFS upload, the file pointer is committed synchronously, but file upload to object storage is performed asynchronously with sidekiq.
In case of a LFS upload, the file pointer is committed synchronously, but file upload to object storage is performed asynchronously with Sidekiq.
## Upload encodings
@ -114,7 +114,7 @@ We have three kinds of file encoding in our uploads:
1. <i class="fa fa-check-circle"></i> **multipart**: `multipart/form-data` is the most common, a file is encoded as a part of a multipart encoded request.
1. <i class="fa fa-check-circle"></i> **body**: some APIs uploads files as the whole request body.
1. <i class="fa fa-times-circle"></i> **JSON**: some JSON API uploads files as base64 encoded strings. This requires [gitlab-workhorse#226](https://gitlab.com/gitlab-org/gitlab-workhorse/issues/226) to be implemented.
1. <i class="fa fa-times-circle"></i> **JSON**: some JSON API uploads files as base64 encoded strings. This will require a change to GitLab Workhorse, which [is planned](https://gitlab.com/gitlab-org/gitlab-workhorse/issues/226).
## Uploading technologies
@ -212,7 +212,9 @@ In this setup an extra rails route needs to be implemented in order to handle au
you can see an example of this in [`Projects::LfsStorageController`](https://gitlab.com/gitlab-org/gitlab/blob/cc723071ad337573e0360a879cbf99bc4fb7adb9/app/controllers/projects/lfs_storage_controller.rb)
and [its routes](https://gitlab.com/gitlab-org/gitlab/blob/cc723071ad337573e0360a879cbf99bc4fb7adb9/config/routes/git_http.rb#L31-32).
**note:** this will fallback to _Workhorse disk acceleration_ when object storage is not enabled in the gitlab instance. The answer to the `/authorize` call will only contain a file system path.
NOTE: **Note:**
This will fall back to _Workhorse disk acceleration_ when object storage is not enabled
in the GitLab instance. The answer to the `/authorize` call will only contain a file system path.
```mermaid
sequenceDiagram
@ -267,4 +269,4 @@ sequenceDiagram
This option affect the response to the `/authorize` call. When not enabled, the API response will not contain presigned URLs and workhorse will write the file the shared disk, on the path is provided by rails, acting like object storage was disabled.
Once the request reachs rails, it will schedule an object storage upload as a sidekiq job.
Once the request reachs rails, it will schedule an object storage upload as a Sidekiq job.

2
doc/user/project/deploy_tokens/index.md
View File

@ -71,7 +71,7 @@ To read the container registry images, you'll need to:
1. Log in to GitLab’s Container Registry using the deploy token:
```sh
docker login registry.example.com -u <username> -p <deploy_token>
docker login -u <username> -p <deploy_token> registry.example.com
```
Just replace `<username>` and `<deploy_token>` with the proper values. Then you can simply

136
doc/user/project/merge_requests/index.md
View File

@ -290,140 +290,10 @@ apply the patches. The target branch can be specified using the
[`/target_branch` quick action](../quick_actions.md). If the source
branch already exists, the patches will be applied on top of it.
## Git push options
## Use Git push options with merge requests
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) in GitLab 11.10.
NOTE: **Note:**
Git push options are only available with Git 2.10 or newer. With Git older than 2.18
`git push --push-option=...` should be used instead of `git push -o ...`.
GitLab supports using
[Git push options](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt)
to perform the following actions against merge requests at the same time
as pushing changes:
- Create a new merge request for the pushed branch.
- Set the target of the merge request to a particular branch.
- Set the merge request to merge when its pipeline succeeds.
- Set the merge request to remove the source branch when it's merged.
- Set the title of the merge request to a particular title.
- Set the description of the merge request to a particular description.
- Add or remove labels from the merge request.
### Create a new merge request using Git push options
To create a new merge request for a branch, use the
`merge_request.create` push option:
```sh
git push -o merge_request.create
```
### Set the target branch of a merge request using Git push options
To update an existing merge request's target branch, use the
`merge_request.target=<branch_name>` push option:
```sh
git push -o merge_request.target=branch_name
```
You can also create a merge request and set its target branch at the
same time using a `-o` flag per push option:
```sh
git push -o merge_request.create -o merge_request.target=branch_name
```
### Set merge when pipeline succeeds using Git push options
To set an existing merge request to
[merge when its pipeline succeeds](merge_when_pipeline_succeeds.md), use
the `merge_request.merge_when_pipeline_succeeds` push option:
```sh
git push -o merge_request.merge_when_pipeline_succeeds
```
You can also create a merge request and set it to merge when its
pipeline succeeds at the same time using a `-o` flag per push option:
```sh
git push -o merge_request.create -o merge_request.merge_when_pipeline_succeeds
```
### Set removing the source branch using Git push options
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) in GitLab 12.2.
To set an existing merge request to remove the source branch when the
merge request is merged, the
`merge_request.remove_source_branch` push option can be used:
```sh
git push -o merge_request.remove_source_branch
```
You can also use this push option in addition to the
`merge_request.create` push option.
### Set merge request title using Git push options
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) in GitLab 12.2.
To set the title of an existing merge request, use
the `merge_request.title` push option:
```sh
git push -o merge_request.title="The title I want"
```
You can also use this push option in addition to the
`merge_request.create` push option.
### Set merge request description using Git push options
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) in GitLab 12.2.
To set the description of an existing merge request, use
the `merge_request.description` push option:
```sh
git push -o merge_request.description="The description I want"
```
You can also use this push option in addition to the
`merge_request.create` push option.
### Add or remove labels using Git push options
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31831) in GitLab 12.3.
You can add or remove labels from merge requests using push options.
For example, to add two labels to an existing merge request, use the
`merge_request.label` push option:
```sh
git push -o merge_request.label="label1" -o merge_request.label="label2"
```
To remove two labels from an existing merge request, use
the `merge_request.unlabel` push option:
```sh
git push -o merge_request.unlabel="label1" -o merge_request.unlabel="label2"
```
You can also use these push options in addition to the
`merge_request.create` push option.
To create a merge request and add two labels to it, use:
```sh
git push -o merge_request.create -o merge_request.label="label1" -o merge_request.label="label2"
```
Use [Git push options](../push_options.md) to create or update merge requests when
pushing changes to GitLab with Git, without needing to use the GitLab interface.
## Find the merge request that introduced a change

10
doc/user/project/merge_requests/merge_request_approvals.md
View File

@ -66,13 +66,7 @@ suitable to your workflow:
## Editing approvals **(PREMIUM)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8.
CAUTION: **Caution:**
There was a [regression affecting this feature in 11.8](https://gitlab.com/gitlab-org/gitlab/merge_requests/9648). We recommend upgrading _at least_ to version 11.8.2. to avoid any issues.
NOTE: **Note:**
In 11.8 this feature does not work in [private groups](https://gitlab.com/gitlab-org/gitlab/issues/10356).
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
For GitLab Premium, [multiple approver rules](#multiple-approval-rules-premium) can be configured. To configure the merge
request approval rules:
@ -87,7 +81,7 @@ request approval rules:
## Multiple approval rules **(PREMIUM)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
For GitLab Premium, a merge request's overall approval status is determined by a set of rules. Each rule contains:

77
doc/user/project/push_options.md Normal file
View File

@ -0,0 +1,77 @@
---
type: reference
---
# Push Options
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/15643) in GitLab 11.7.
GitLab supports using [Git push options](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt)
to perform various actions at the same time as pushing changes.
Currently, there are push options available for:
- [Skipping CI jobs](#push-options-for-gitlab-cicd)
- [Merge requests](#push-options-for-merge-requests)
NOTE: **Note:**
Git push options are only available with Git 2.10 or newer.
For Git versions 2.10 to 2.17 use `--push-option`:
```shell
git push --push-option=<push_option>
```
For version 2.18 and later, you can use the above format, or the shorter `-o`:
```shell
git push -o <push_option>
```
## Push options for GitLab CI/CD
If the `ci.skip` push option is used, the commit will be pushed, but no [CI pipeline](../../ci/pipelines.md)
will be created.
| Push option | Description |
| ----------- | ----------- |
| `ci.skip` | Do not create a CI pipeline for the latest push. |
For example:
```shell
git push -o ci.skip
```
## Push options for merge requests
You can use Git push options to perform certain actions for merge requests at the same
time as pushing changes:
| Push option | Description | Introduced in version |
| -------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | --------------------- |
| `merge_request.create` | Create a new merge request for the pushed branch. | [11.10](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) |
| `merge_request.target=<branch_name>` | Set the target of the merge request to a particular branch. | [11.10](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) |
| `merge_request.merge_when_pipeline_succeeds` | Set the merge request to [merge when its pipeline succeeds](merge_requests/merge_when_pipeline_succeeds.md). | [11.10](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) |
| `merge_request.remove_source_branch` | Set the merge request to remove the source branch when it's merged. | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) |
| `merge_request.title="<title>"` | Set the title of the merge request. Ex: `git push -o merge_request.title="The title I want"`. | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) |
| `merge_request.description="<description>"` | Set the description of the merge request. Ex: `git push -o merge_request.description="The description I want"`. | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) |
| `merge_request.label="<label>"` | Add labels to the merge request. If the label does not exist, it will be created. For example, for two labels: `git push -o merge_request.label="label1" -o merge_request.label="label2"`. | [12.3](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31831) |
| `merge_request.unlabel="<label>"` | Remove labels from the merge request. For example, for two labels: `git push -o merge_request.unlabel="label1" -o merge_request.unlabel="label2"`. | [12.3](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31831) |
If you use a push option that requires text with spaces in it, you need to enclose it
in quotes (`"`). You can omit the quotes if there are no spaces. Some examples:
```shell
git push -o merge_request.label="Label with spaces"
git push -o merge_request.label=Label-with-no-spaces
```
You can combine push options to accomplish multiple tasks at once, by using
multiple `-o` (or `--push-option`) flags. For example, if you want to create a new
merge request, and target a branch named `my-target-branch`:
```shell
git push -o merge_request.create -o merge_request.target=my-target-branch
```

11
lib/event_filter.rb
View File

@ -9,12 +9,11 @@ class EventFilter
ISSUE = 'issue'
COMMENTS = 'comments'
TEAM = 'team'
FILTERS = [ALL, PUSH, MERGED, ISSUE, COMMENTS, TEAM].freeze
def initialize(filter)
# Split using comma to maintain backward compatibility Ex/ "filter1,filter2"
filter = filter.to_s.split(',')[0].to_s
@filter = FILTERS.include?(filter) ? filter : ALL
@filter = filters.include?(filter) ? filter : ALL
end
def active?(key)
@ -39,4 +38,12 @@ class EventFilter
end
end
# rubocop: enable CodeReuse/ActiveRecord
private
def filters
[ALL, PUSH, MERGED, ISSUE, COMMENTS, TEAM]
end
end
EventFilter.prepend_if_ee('EE::EventFilter')

4
lib/gitlab/database.rb
View File

@ -87,10 +87,6 @@ module Gitlab
version.to_f < 10
end
def self.join_lateral_supported?
version.to_f >= 9.3
end
def self.replication_slots_supported?
version.to_f >= 9.4
end

2
lib/gitlab/kubernetes/helm/client_command.rb
View File

@ -17,7 +17,7 @@ module Gitlab
# This is necessary to give Tiller time to restart after upgrade.
# Ideally we'd be able to use --wait but cannot because of
# https://github.com/helm/helm/issues/4855
"for i in $(seq 1 30); do #{helm_check} && break; sleep 1s; echo \"Retrying ($i)...\"; done"
"for i in $(seq 1 30); do #{helm_check} && break; sleep 1s; echo \"Retrying ($i)...\"; false; done"
end
def repository_command

6
locale/gitlab.pot
View File

@ -6162,6 +6162,9 @@ msgstr ""
msgid "Epic"
msgstr ""
msgid "Epic events"
msgstr ""
msgid "Epics"
msgstr ""
@ -6435,6 +6438,9 @@ msgstr ""
msgid "EventFilterBy|Filter by comments"
msgstr ""
msgid "EventFilterBy|Filter by epic events"
msgstr ""
msgid "EventFilterBy|Filter by issue events"
msgstr ""

4
scripts/lint-doc.sh
View File

@ -24,12 +24,12 @@ then
fi
# Make sure no files in doc/ are executable
EXEC_PERM_COUNT=$(find doc/ app/ -type f -perm 755 | wc -l)
EXEC_PERM_COUNT=$(find doc/ -type f -perm 755 | wc -l)
echo '=> Checking for executable permissions...'
if [ "${EXEC_PERM_COUNT}" -ne 0 ]
then
echo '✖ ERROR: Executable permissions should not be used in documentation! Use `chmod 644` to the files in question:' >&2
find doc/ app/ -type f -perm 755
find doc/ -type f -perm 755
exit 1
fi

2
spec/controllers/groups_controller_spec.rb
View File

@ -125,7 +125,7 @@ describe GroupsController do
end
context 'as json' do
it 'includes all projects from groups and subgroups in event feed' do
it 'includes events from all projects in group and subgroups' do
2.times do
project = create(:project, group: group)
create(:event, project: project)

2
spec/features/projects/features_visibility_spec.rb
View File

@ -211,7 +211,7 @@ describe 'Edit Project Settings' do
visit activity_project_path(project)
page.within(".event-filter") do
expect(page).to have_selector("a", count: 2)
expect(page).to have_content("All")
expect(page).not_to have_content("Push events")
expect(page).not_to have_content("Merge events")
expect(page).not_to have_content("Comments")

6
spec/lib/event_filter_spec.rb
View File

@ -3,12 +3,6 @@
require 'spec_helper'
describe EventFilter do
describe 'FILTERS' do
it 'returns a definite list of filters' do
expect(described_class::FILTERS).to eq(%w[all push merged issue comments team])
end
end
describe '#filter' do
it 'returns "all" if given filter is nil' do
expect(described_class.new(nil).filter).to eq(described_class::ALL)

14
spec/lib/gitlab/database_spec.rb
View File

@ -101,20 +101,6 @@ describe Gitlab::Database do
end
end
describe '.join_lateral_supported?' do
it 'returns false when using PostgreSQL 9.2' do
allow(described_class).to receive(:version).and_return('9.2.1')
expect(described_class.join_lateral_supported?).to eq(false)
end
it 'returns true when using PostgreSQL 9.3.0 or newer' do
allow(described_class).to receive(:version).and_return('9.3.0')
expect(described_class.join_lateral_supported?).to eq(true)
end
end
describe '.replication_slots_supported?' do
it 'returns false when using PostgreSQL 9.3' do
allow(described_class).to receive(:version).and_return('9.3.1')

4
spec/lib/gitlab/kubernetes/helm/delete_command_spec.rb
View File

@ -14,7 +14,7 @@ describe Gitlab::Kubernetes::Helm::DeleteCommand do
let(:commands) do
<<~EOS
helm init --upgrade
for i in $(seq 1 30); do helm version && break; sleep 1s; echo "Retrying ($i)..."; done
for i in $(seq 1 30); do helm version && break; sleep 1s; echo "Retrying ($i)..."; false; done
helm delete --purge app-name
EOS
end
@ -36,7 +36,7 @@ describe Gitlab::Kubernetes::Helm::DeleteCommand do
let(:commands) do
<<~EOS
helm init --upgrade
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; done
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
#{helm_delete_command}
EOS
end

14
spec/lib/gitlab/kubernetes/helm/install_command_spec.rb
View File

@ -36,7 +36,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
let(:commands) do
<<~EOS
helm init --upgrade
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; done
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
helm repo add app-name https://repository.example.com
helm repo update
#{helm_install_comand}
@ -64,7 +64,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
let(:commands) do
<<~EOS
helm init --upgrade
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; done
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
helm repo add app-name https://repository.example.com
helm repo update
#{helm_install_command}
@ -93,7 +93,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
let(:commands) do
<<~EOS
helm init --upgrade
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; done
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
#{helm_install_command}
EOS
end
@ -120,7 +120,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
let(:commands) do
<<~EOS
helm init --upgrade
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; done
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
helm repo add app-name https://repository.example.com
helm repo update
/bin/date
@ -151,7 +151,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
let(:commands) do
<<~EOS
helm init --upgrade
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; done
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
helm repo add app-name https://repository.example.com
helm repo update
#{helm_install_command}
@ -182,7 +182,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
let(:commands) do
<<~EOS
helm init --upgrade
for i in $(seq 1 30); do helm version && break; sleep 1s; echo "Retrying ($i)..."; done
for i in $(seq 1 30); do helm version && break; sleep 1s; echo "Retrying ($i)..."; false; done
helm repo add app-name https://repository.example.com
helm repo update
#{helm_install_command}
@ -210,7 +210,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
let(:commands) do
<<~EOS
helm init --upgrade
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; done
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
helm repo add app-name https://repository.example.com
helm repo update
#{helm_install_command}

2
spec/models/clusters/applications/cert_manager_spec.rb
View File

@ -54,7 +54,7 @@ describe Clusters::Applications::CertManager do
'kubectl label --overwrite namespace gitlab-managed-apps certmanager.k8s.io/disable-validation=true'
])
expect(subject.postinstall).to eq([
'for i in $(seq 1 30); do kubectl apply -f /data/helm/certmanager/config/cluster_issuer.yaml && break; sleep 1s; echo "Retrying ($i)..."; done'
'for i in $(seq 1 30); do kubectl apply -f /data/helm/certmanager/config/cluster_issuer.yaml && break; sleep 1s; echo "Retrying ($i)..."; false; done'
])
end

93
spec/models/event_collection_spec.rb
View File

@ -4,50 +4,75 @@ require 'spec_helper'
describe EventCollection do
describe '#to_a' do
let(:project) { create(:project_empty_repo) }
let(:projects) { Project.where(id: project.id) }
let(:user) { create(:user) }
set(:group) { create(:group) }
set(:project) { create(:project_empty_repo, group: group) }
set(:projects) { Project.where(id: project.id) }
set(:user) { create(:user) }
before do
20.times do
event = create(:push_event, project: project, author: user)
context 'with project events' do
before do
20.times do
event = create(:push_event, project: project, author: user)
create(:push_event_payload, event: event)
create(:push_event_payload, event: event)
end
create(:closed_issue_event, project: project, author: user)
end
create(:closed_issue_event, project: project, author: user)
it 'returns an Array of events' do
events = described_class.new(projects).to_a
expect(events).to be_an_instance_of(Array)
end
it 'applies a limit to the number of events' do
events = described_class.new(projects).to_a
expect(events.length).to eq(20)
end
it 'can paginate through events' do
events = described_class.new(projects, offset: 20).to_a
expect(events.length).to eq(1)
end
it 'returns an empty Array when crossing the maximum page number' do
events = described_class.new(projects, limit: 1, offset: 15).to_a
expect(events).to be_empty
end
it 'allows filtering of events using an EventFilter' do
filter = EventFilter.new(EventFilter::ISSUE)
events = described_class.new(projects, filter: filter).to_a
expect(events.length).to eq(1)
expect(events[0].action).to eq(Event::CLOSED)
end
end
it 'returns an Array of events' do
events = described_class.new(projects).to_a
context 'with group events' do
let(:groups) { group.self_and_descendants.public_or_visible_to_user(user) }
let(:subject) { described_class.new(projects, groups: groups).to_a }
expect(events).to be_an_instance_of(Array)
end
it 'includes also group events' do
subgroup = create(:group, parent: group)
event1 = create(:event, project: project, author: user)
event2 = create(:event, project: nil, group: group, author: user)
event3 = create(:event, project: nil, group: subgroup, author: user)
it 'applies a limit to the number of events' do
events = described_class.new(projects).to_a
expect(subject).to eq([event3, event2, event1])
end
expect(events.length).to eq(20)
end
it 'does not include events from inaccessible groups' do
subgroup = create(:group, :private, parent: group)
event1 = create(:event, project: nil, group: group, author: user)
create(:event, project: nil, group: subgroup, author: user)
it 'can paginate through events' do
events = described_class.new(projects, offset: 20).to_a
expect(events.length).to eq(1)
end
it 'returns an empty Array when crossing the maximum page number' do
events = described_class.new(projects, limit: 1, offset: 15).to_a
expect(events).to be_empty
end
it 'allows filtering of events using an EventFilter' do
filter = EventFilter.new(EventFilter::ISSUE)
events = described_class.new(projects, filter: filter).to_a
expect(events.length).to eq(1)
expect(events[0].action).to eq(Event::CLOSED)
expect(subject).to eq([event1])
end
end
end
end