Commit 30010b16 authored by GitLab Bot's avatar GitLab Bot

Add latest changes from gitlab-org/gitlab@master

parent 2b3bfe8f
...@@ -389,7 +389,7 @@ group :development, :test do ...@@ -389,7 +389,7 @@ group :development, :test do
gem 'png_quantizator', '~> 0.2.1', require: false gem 'png_quantizator', '~> 0.2.1', require: false
gem 'parallel', '~> 1.17.0', require: false gem 'parallel', '~> 1.19', require: false
end end
# Gems required in omnibus-gitlab pipeline # Gems required in omnibus-gitlab pipeline
......
...@@ -1287,7 +1287,7 @@ DEPENDENCIES ...@@ -1287,7 +1287,7 @@ DEPENDENCIES
omniauth_crowd (~> 2.2.0) omniauth_crowd (~> 2.2.0)
omniauth_openid_connect (~> 0.3.3) omniauth_openid_connect (~> 0.3.3)
org-ruby (~> 0.9.12) org-ruby (~> 0.9.12)
parallel (~> 1.17.0) parallel (~> 1.19)
peek (~> 1.1) peek (~> 1.1)
pg (~> 1.1) pg (~> 1.1)
png_quantizator (~> 0.2.1) png_quantizator (~> 0.2.1)
......
---
title: Allow CI_JOB_TOKENS for Conan package registry authentication
merge_request: 22184
author:
type: added
...@@ -23,7 +23,7 @@ For example, [Active Directory](https://docs.microsoft.com/en-us/previous-versio ...@@ -23,7 +23,7 @@ For example, [Active Directory](https://docs.microsoft.com/en-us/previous-versio
- [Oracle Internet Directory](https://www.oracle.com/middleware/technologies/internet-directory.html) - [Oracle Internet Directory](https://www.oracle.com/middleware/technologies/internet-directory.html)
- [OpenLDAP](http://www.openldap.org/) - [OpenLDAP](http://www.openldap.org/)
- [389 Directory](http://directory.fedoraproject.org/) - [389 Directory](http://directory.fedoraproject.org/)
- [OpenDJ (Renamed to Foregerock Directory Services)](https://www.forgerock.com/platform/directory-services) - [OpenDJ (Renamed to Forgerock Directory Services)](https://www.forgerock.com/platform/directory-services)
- [ApacheDS](https://directory.apache.org/) - [ApacheDS](https://directory.apache.org/)
> GitLab uses the [Net::LDAP](https://rubygems.org/gems/net-ldap) library under the hood. This means it supports all [IETF](https://tools.ietf.org/html/rfc2251) compliant LDAPv3 servers. > GitLab uses the [Net::LDAP](https://rubygems.org/gems/net-ldap) library under the hood. This means it supports all [IETF](https://tools.ietf.org/html/rfc2251) compliant LDAPv3 servers.
......
...@@ -45,7 +45,7 @@ requiring a shared NFS mount for Git repository data. ...@@ -45,7 +45,7 @@ requiring a shared NFS mount for Git repository data.
Between 11.4 and 11.8 the exception was the Between 11.4 and 11.8 the exception was the
[Elasticsearch indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). [Elasticsearch indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer).
But since 11.8 the indexer uses Gitaly for data access as well. NFS can still But since 11.8 the indexer uses Gitaly for data access as well. NFS can still
be leveraged for redudancy on block level of the Git data. But only has to be leveraged for redundancy on block level of the Git data. But only has to
be mounted on the Gitaly server. be mounted on the Gitaly server.
From GitLab v11.8 to v12.2, it is possible to use Elasticsearch in conjunction with From GitLab v11.8 to v12.2, it is possible to use Elasticsearch in conjunction with
...@@ -618,7 +618,7 @@ This will limit the number of in-flight RPC calls for the given RPC's. ...@@ -618,7 +618,7 @@ This will limit the number of in-flight RPC calls for the given RPC's.
The limit is applied per repository. In the example above, each on the The limit is applied per repository. In the example above, each on the
Gitaly server can have at most 20 simultaneous PostUploadPack calls in Gitaly server can have at most 20 simultaneous PostUploadPack calls in
flight, and the same for SSHUploadPack. If another request comes in for flight, and the same for SSHUploadPack. If another request comes in for
a repository that hase used up its 20 slots, that request will get a repository that has used up its 20 slots, that request will get
queued. queued.
You can observe the behavior of this queue via the Gitaly logs and via You can observe the behavior of this queue via the Gitaly logs and via
...@@ -762,7 +762,7 @@ Git implementation itself. ...@@ -762,7 +762,7 @@ Git implementation itself.
Because Rugged+Unicorn was so efficient, GitLab's application code ended Because Rugged+Unicorn was so efficient, GitLab's application code ended
up with lots of duplicate Git object lookups (like looking up the up with lots of duplicate Git object lookups (like looking up the
`master` commmit a dozen times in one request). We could write `master` commit a dozen times in one request). We could write
inefficient code without being punished for it. inefficient code without being punished for it.
When we migrated these Git lookups to Gitaly calls, we were suddenly When we migrated these Git lookups to Gitaly calls, we were suddenly
...@@ -927,7 +927,7 @@ Confirm the following are all true: ...@@ -927,7 +927,7 @@ Confirm the following are all true:
``` ```
- When any user adds or modifies a file from the repository using the GitLab - When any user adds or modifies a file from the repository using the GitLab
UI, it immediatley fails with a red `401 Unauthorized` banner. UI, it immediately fails with a red `401 Unauthorized` banner.
- Creating a new project and [initializing it with a README](../../gitlab-basics/create-project.md#blank-projects) - Creating a new project and [initializing it with a README](../../gitlab-basics/create-project.md#blank-projects)
successfully creates the project but doesn't create the README. successfully creates the project but doesn't create the README.
- When [tailing the logs](https://docs.gitlab.com/omnibus/settings/logs.html#tail-logs-in-a-console-on-the-server) on an app node and reproducing the error, you get `401` errors - When [tailing the logs](https://docs.gitlab.com/omnibus/settings/logs.html#tail-logs-in-a-console-on-the-server) on an app node and reproducing the error, you get `401` errors
......
...@@ -31,7 +31,7 @@ graph TB ...@@ -31,7 +31,7 @@ graph TB
``` ```
Where `GitLab` is the collection of clients that can request Git operations. Where `GitLab` is the collection of clients that can request Git operations.
The Praefect node has threestorage nodes attached. Praefect itself doesn't The Praefect node has three storage nodes attached. Praefect itself doesn't
store data, but connects to three Gitaly nodes, `Gitaly-1`, `Gitaly-2`, and `Gitaly-3`. store data, but connects to three Gitaly nodes, `Gitaly-1`, `Gitaly-2`, and `Gitaly-3`.
Praefect may be enabled on its own node or can be run on the GitLab server. Praefect may be enabled on its own node or can be run on the GitLab server.
......
...@@ -100,7 +100,7 @@ If it is necessary to restart the server cluster, it is important to do this in ...@@ -100,7 +100,7 @@ If it is necessary to restart the server cluster, it is important to do this in
To be safe, we recommend you only restart one server agent at a time to ensure the cluster remains intact. To be safe, we recommend you only restart one server agent at a time to ensure the cluster remains intact.
For larger clusters, it is possible to restart multiple agents at a time. See the [Consul consensus document](https://www.consul.io/docs/internals/consensus.html#deployment-table) for how many failures it can tolerate. This will be the number of simulateneous restarts it can sustain. For larger clusters, it is possible to restart multiple agents at a time. See the [Consul consensus document](https://www.consul.io/docs/internals/consensus.html#deployment-table) for how many failures it can tolerate. This will be the number of simultaneous restarts it can sustain.
## Upgrades for bundled Consul ## Upgrades for bundled Consul
......
...@@ -81,7 +81,7 @@ with one change: _the stored path of the first two phases is different_. This in ...@@ -81,7 +81,7 @@ with one change: _the stored path of the first two phases is different_. This in
log architecture stores chunks of logs in Redis and a persistent store (object storage or database) instead of log architecture stores chunks of logs in Redis and a persistent store (object storage or database) instead of
file storage. Redis is used as first-class storage, and it stores up-to 128KB file storage. Redis is used as first-class storage, and it stores up-to 128KB
of data. Once the full chunk is sent, it is flushed to a persistent store, either object storage (temporary directory) or database. of data. Once the full chunk is sent, it is flushed to a persistent store, either object storage (temporary directory) or database.
After a while, the data in Redis and a persitent store will be archived to [object storage](#uploading-logs-to-object-storage). After a while, the data in Redis and a persistent store will be archived to [object storage](#uploading-logs-to-object-storage).
The data are stored in the following Redis namespace: `Gitlab::Redis::SharedState`. The data are stored in the following Redis namespace: `Gitlab::Redis::SharedState`.
......
...@@ -238,8 +238,8 @@ and [projects APIs](../../api/projects.md). ...@@ -238,8 +238,8 @@ and [projects APIs](../../api/projects.md).
## Troubleshooting: `Google::Apis::TransmissionError: execution expired` ## Troubleshooting: `Google::Apis::TransmissionError: execution expired`
If LFS integration is configred with Google Cloud Storage and background uploads (`background_upload: true` and `direct_upload: false`), If LFS integration is configured with Google Cloud Storage and background uploads (`background_upload: true` and `direct_upload: false`),
Sidekiq workers may encouter this error. This is because the uploading timed out with very large files. Sidekiq workers may encounter this error. This is because the uploading timed out with very large files.
LFS files up to 6Gb can be uploaded without any extra steps, otherwise you need to use the following workaround. LFS files up to 6Gb can be uploaded without any extra steps, otherwise you need to use the following workaround.
```shell ```shell
......
...@@ -26,7 +26,7 @@ The following metrics are available: ...@@ -26,7 +26,7 @@ The following metrics are available:
| Metric | Type | Since | Description | Labels | | Metric | Type | Since | Description | Labels |
|:---------------------------------------------------------------|:----------|-----------------------:|:----------------------------------------------------------------------------------------------------|:----------------------------------------------------| |:---------------------------------------------------------------|:----------|-----------------------:|:----------------------------------------------------------------------------------------------------|:----------------------------------------------------|
| `gitlab_banzai_cached_render_real_duration_seconds` | Histogram | 9.4 | Duration of rendering Markdown into HTML when cached output exists | controller, action | | `gitlab_banzai_cached_render_real_duration_seconds` | Histogram | 9.4 | Duration of rendering Markdown into HTML when cached output exists | controller, action |
| `gitlab_banzai_cacheless_render_real_duration_seconds` | Histogram | 9.4 | Duration of rendering Markdown into HTML when cached outupt does not exist | controller, action | | `gitlab_banzai_cacheless_render_real_duration_seconds` | Histogram | 9.4 | Duration of rendering Markdown into HTML when cached output does not exist | controller, action |
| `gitlab_cache_misses_total` | Counter | 10.2 | Cache read miss | controller, action | | `gitlab_cache_misses_total` | Counter | 10.2 | Cache read miss | controller, action |
| `gitlab_cache_operation_duration_seconds` | Histogram | 10.2 | Cache access time | | | `gitlab_cache_operation_duration_seconds` | Histogram | 10.2 | Cache access time | |
| `gitlab_cache_operations_total` | Counter | 12.2 | Cache operations by controller/action | controller, action, operation | | `gitlab_cache_operations_total` | Counter | 12.2 | Cache operations by controller/action | controller, action, operation |
...@@ -59,7 +59,7 @@ The following metrics are available: ...@@ -59,7 +59,7 @@ The following metrics are available:
| `gitlab_transaction_event_push_commit_total` | Counter | 9.4 | Counter for commits | branch | | `gitlab_transaction_event_push_commit_total` | Counter | 9.4 | Counter for commits | branch |
| `gitlab_transaction_event_push_tag_total` | Counter | 9.4 | Counter for tag pushes | | | `gitlab_transaction_event_push_tag_total` | Counter | 9.4 | Counter for tag pushes | |
| `gitlab_transaction_event_rails_exception_total` | Counter | 9.4 | Counter for number of rails exceptions | | | `gitlab_transaction_event_rails_exception_total` | Counter | 9.4 | Counter for number of rails exceptions | |
| `gitlab_transaction_event_receive_email_total` | Counter | 9.4 | Counter for recieved emails | handler | | `gitlab_transaction_event_receive_email_total` | Counter | 9.4 | Counter for received emails | handler |
| `gitlab_transaction_event_remote_mirrors_failed_total` | Counter | 10.8 | Counter for failed remote mirrors | | | `gitlab_transaction_event_remote_mirrors_failed_total` | Counter | 10.8 | Counter for failed remote mirrors | |
| `gitlab_transaction_event_remote_mirrors_finished_total` | Counter | 10.8 | Counter for finished remote mirrors | | | `gitlab_transaction_event_remote_mirrors_finished_total` | Counter | 10.8 | Counter for finished remote mirrors | |
| `gitlab_transaction_event_remote_mirrors_running_total` | Counter | 10.8 | Counter for running remote mirrors | | | `gitlab_transaction_event_remote_mirrors_running_total` | Counter | 10.8 | Counter for running remote mirrors | |
......
...@@ -325,7 +325,7 @@ feel free to update that page with issues you encounter and solutions. ...@@ -325,7 +325,7 @@ feel free to update that page with issues you encounter and solutions.
## Replication ## Replication
Setting up Elasticsearch isn't too bad, but it can be a bit finnicky and time consuming. Setting up Elasticsearch isn't too bad, but it can be a bit finicky and time consuming.
The easiest method is to spin up a docker container with the required version and The easiest method is to spin up a docker container with the required version and
bind ports 9200/9300 so it can be used. bind ports 9200/9300 so it can be used.
......
...@@ -41,7 +41,7 @@ This section is for links to information elsewhere in the GitLab documentation. ...@@ -41,7 +41,7 @@ This section is for links to information elsewhere in the GitLab documentation.
- [Using Slony to update PostgreSQL](../../update/upgrading_postgresql_using_slony.md) - [Using Slony to update PostgreSQL](../../update/upgrading_postgresql_using_slony.md)
- Uses replication to handle PostgreSQL upgrades - providing the schemas are the same. - Uses replication to handle PostgreSQL upgrades - providing the schemas are the same.
- Reduces downtime to a short window for swinging over to the newer vewrsion. - Reduces downtime to a short window for swinging over to the newer version.
- Managing Omnibus PostgreSQL versions [from the development docs](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions.html) - Managing Omnibus PostgreSQL versions [from the development docs](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions.html)
......
...@@ -174,7 +174,7 @@ the query details. ...@@ -174,7 +174,7 @@ the query details.
## Managing Sidekiq queues ## Managing Sidekiq queues
It is possible to use [Sidekiq API](https://github.com/mperham/sidekiq/wiki/API) It is possible to use [Sidekiq API](https://github.com/mperham/sidekiq/wiki/API)
to perform a number of troubleshoting on Sidekiq. to perform a number of troubleshooting on Sidekiq.
These are the administrative commands and it should only be used if currently These are the administrative commands and it should only be used if currently
admin interface is not suitable due to scale of installation. admin interface is not suitable due to scale of installation.
......
...@@ -61,7 +61,7 @@ ls: ...@@ -61,7 +61,7 @@ ls:
## GitLab ChatOps Examples ## GitLab ChatOps Examples
The GitLab.com team created a repository of [common ChatOps scripts they use to interact with our Production instance of GitLab](https://gitlab.com/gitlab-com/chatops). They are likely useful The GitLab.com team created a repository of [common ChatOps scripts they use to interact with our Production instance of GitLab](https://gitlab.com/gitlab-com/chatops). They are likely useful
to other adminstrators of GitLab instances and can serve as inspiration for ChatOps scripts you can write to interact with your own applications. to other administrators of GitLab instances and can serve as inspiration for ChatOps scripts you can write to interact with your own applications.
## GitLab ChatOps icon ## GitLab ChatOps icon
......
...@@ -513,7 +513,7 @@ To define which should be used, the GitLab Runner process reads the configuratio ...@@ -513,7 +513,7 @@ To define which should be used, the GitLab Runner process reads the configuratio
NOTE: **Note:** NOTE: **Note:**
GitLab Runner reads this configuration **only** from `config.toml` and ignores it if GitLab Runner reads this configuration **only** from `config.toml` and ignores it if
it's provided as an environment variable. This is because GitLab Runnner uses **only** it's provided as an environment variable. This is because GitLab Runner uses **only**
`config.toml` configuration and doesn't interpolate **ANY** environment variables at `config.toml` configuration and doesn't interpolate **ANY** environment variables at
runtime. runtime.
......
...@@ -4,7 +4,7 @@ type: tutorial ...@@ -4,7 +4,7 @@ type: tutorial
# Using Dpl as deployment tool # Using Dpl as deployment tool
[Dpl](https://github.com/travis-ci/dpl) (prouncounced like the letters D-P-L) is a deploy tool made for [Dpl](https://github.com/travis-ci/dpl) (pronounced like the letters D-P-L) is a deploy tool made for
continuous deployment that's developed and used by Travis CI, but can also be continuous deployment that's developed and used by Travis CI, but can also be
used with GitLab CI. used with GitLab CI.
......
...@@ -26,7 +26,7 @@ There are some high level differences between the products worth mentioning: ...@@ -26,7 +26,7 @@ There are some high level differences between the products worth mentioning:
feature. feature.
- The `.gitlab-ci.yml` file is checked in to the root of your repository, much like a Jenkinsfile, but - The `.gitlab-ci.yml` file is checked in to the root of your repository, much like a Jenkinsfile, but
is in the YAML format (see [complete reference](../yaml/README.md)) instead of a Groovy DSL. It's most is in the YAML format (see [complete reference](../yaml/README.md)) instead of a Groovy DSL. It's most
analagous to the declarative Jenkinsfile format. analogous to the declarative Jenkinsfile format.
- GitLab comes with a [container registry](../../user/packages/container_registry/index.md), and we recommend using - GitLab comes with a [container registry](../../user/packages/container_registry/index.md), and we recommend using
container images to set up your build environment. container images to set up your build environment.
...@@ -207,7 +207,7 @@ Because GitLab is integrated tightly with Git, SCM polling options for triggers ...@@ -207,7 +207,7 @@ Because GitLab is integrated tightly with Git, SCM polling options for triggers
#### `tools` #### `tools`
GitLab does not support a separate `tools` directive. Our best-practice reccomendation is to use pre-built GitLab does not support a separate `tools` directive. Our best-practice recommendation is to use pre-built
container images, which can be cached, and can be built to already contain the tools you need for your pipelines. Pipelines can container images, which can be cached, and can be built to already contain the tools you need for your pipelines. Pipelines can
be set up to automatically build these images as needed and deploy them to the [container registry](../../user/packages/container_registry/index.md). be set up to automatically build these images as needed and deploy them to the [container registry](../../user/packages/container_registry/index.md).
......
...@@ -136,7 +136,7 @@ Review App set up, helping to save resources. ...@@ -136,7 +136,7 @@ Review App set up, helping to save resources.
## Excluding certain branches ## Excluding certain branches
Pipelines for merge requests require special treatement when Pipelines for merge requests require special treatment when
using [`only`/`except`](../yaml/README.md#onlyexcept-basic). Unlike ordinary using [`only`/`except`](../yaml/README.md#onlyexcept-basic). Unlike ordinary
branch refs (for example `refs/heads/my-feature-branch`), merge request refs branch refs (for example `refs/heads/my-feature-branch`), merge request refs
use a special Git reference that looks like `refs/merge-requests/:iid/head`. Because use a special Git reference that looks like `refs/merge-requests/:iid/head`. Because
......
...@@ -830,7 +830,7 @@ In the example above, a pipeline could fail due to changes to a file in `service ...@@ -830,7 +830,7 @@ In the example above, a pipeline could fail due to changes to a file in `service
A later commit could then be pushed that does not include any changes to this file, A later commit could then be pushed that does not include any changes to this file,
but includes changes to the `Dockerfile`, and this pipeline could pass because it is only but includes changes to the `Dockerfile`, and this pipeline could pass because it is only
testing the changes to the `Dockerfile`. GitLab checks the **most recent pipeline**, testing the changes to the `Dockerfile`. GitLab checks the **most recent pipeline**,
that **passed**, and will show the merge request as mergable, despite the earlier that **passed**, and will show the merge request as mergeable, despite the earlier
failed pipeline caused by a change that was not yet corrected. failed pipeline caused by a change that was not yet corrected.
With this configuration, care must be taken to check that the most recent pipeline With this configuration, care must be taken to check that the most recent pipeline
......
...@@ -314,7 +314,7 @@ experience, refactors the existing code). Then: ...@@ -314,7 +314,7 @@ experience, refactors the existing code). Then:
- Ensure the target branch is not too far behind master. If - Ensure the target branch is not too far behind master. If
[master is red](https://about.gitlab.com/handbook/engineering/workflow/#broken-master), [master is red](https://about.gitlab.com/handbook/engineering/workflow/#broken-master),
it should be no more than 100 commits behind. it should be no more than 100 commits behind.
- Consider warnings and errors from danger bot, codequality, and other reports. - Consider warnings and errors from danger bot, code quality, and other reports.
Unless a strong case can be made for the violation, these should be resolved Unless a strong case can be made for the violation, these should be resolved
before merge. before merge.
- Ensure a passing CI pipeline or if [master is broken](https://about.gitlab.com/handbook/engineering/workflow/#broken-master), post a comment mentioning the failure happens in master with a - Ensure a passing CI pipeline or if [master is broken](https://about.gitlab.com/handbook/engineering/workflow/#broken-master), post a comment mentioning the failure happens in master with a
......
...@@ -263,3 +263,25 @@ The GitLab Conan repository supports the following Conan CLI commands: ...@@ -263,3 +263,25 @@ The GitLab Conan repository supports the following Conan CLI commands:
- `conan search`: Search the GitLab Package Registry for public packages, and private packages you have permission to view. - `conan search`: Search the GitLab Package Registry for public packages, and private packages you have permission to view.
- `conan info`: View the info on a given package from the GitLab Package Registry. - `conan info`: View the info on a given package from the GitLab Package Registry.
- `conan remove`: Delete the package from the GitLab Package Registry. - `conan remove`: Delete the package from the GitLab Package Registry.
## Using GitLab CI with Conan packages
To work with Conan commands within [GitLab CI](./../../../ci/README.md), you can use
`CI_JOB_TOKEN` in place of the personal access token in your commands.
It is easiest to provide the `CONAN_LOGIN_USERNAME` and `CONAN_PASSWORD` with each
Conan command in your `.gitlab-ci.yml` file:
```yml
image: conanio/gcc7
create_package:
stage: deploy
script:
- conan remote add gitlab https://gitlab.example.com/api/v4/packages/conan
- conan create . my-group+my-project/beta
- CONAN_LOGIN_USERNAME=ci_user CONAN_PASSWORD=${CI_JOB_TOKEN} conan upload Hello/0.1@root+ci-conan/beta1 --all --remote=gitlab
```
You can find additional Conan images to use as the base of your CI file
in the [Conan docs](https://docs.conan.io/en/latest/howtos/run_conan_in_docker.html#available-docker-images).
...@@ -97,7 +97,7 @@ and modify them if you have the necessary [permissions](../../permissions.md). ...@@ -97,7 +97,7 @@ and modify them if you have the necessary [permissions](../../permissions.md).
On the Issues List, you can view all issues in the current project, or from multiple On the Issues List, you can view all issues in the current project, or from multiple
projects when opening the Issues List from the higher-level group context. Filter the projects when opening the Issues List from the higher-level group context. Filter the
issue list with a [search query](../../search/index.md#issues-and-merge-requests-per-project), issue list with a [search query](../../search/index.md#filtering-issue-and-merge-request-lists),
including specific metadata, such as label(s), assignees(s), status, and more. From this including specific metadata, such as label(s), assignees(s), status, and more. From this
view, you can also make certain changes [in bulk](../bulk_editing.md) to the displayed issues. view, you can also make certain changes [in bulk](../bulk_editing.md) to the displayed issues.
......
...@@ -13,7 +13,7 @@ which is then reviewed, and accepted (or rejected). ...@@ -13,7 +13,7 @@ which is then reviewed, and accepted (or rejected).
View all the merge requests within a project by navigating to **Project > Merge Requests**. View all the merge requests within a project by navigating to **Project > Merge Requests**.
When you access your project's merge requests, GitLab will present them in a list, When you access your project's merge requests, GitLab will present them in a list,
and you can use the tabs available to quickly filter by open and closed. You can also [search and filter the results](../../search/index.md#issues-and-merge-requests-per-project). and you can use the tabs available to quickly filter by open and closed. You can also [search and filter the results](../../search/index.md#filtering-issue-and-merge-request-lists).
![Project merge requests list view](img/project_merge_requests_list_view.png) ![Project merge requests list view](img/project_merge_requests_list_view.png)
...@@ -21,7 +21,7 @@ and you can use the tabs available to quickly filter by open and closed. You can ...@@ -21,7 +21,7 @@ and you can use the tabs available to quickly filter by open and closed. You can
View merge requests in all projects in the group, including all projects of all descendant subgroups of the group. Navigate to **Group > Merge Requests** to view these merge requests. This view also has the open and closed merge requests tabs. View merge requests in all projects in the group, including all projects of all descendant subgroups of the group. Navigate to **Group > Merge Requests** to view these merge requests. This view also has the open and closed merge requests tabs.
You can [search and filter the results](../../search/index.md#issues-and-merge-requests-per-group) from here. You can [search and filter the results](../../search/index.md#filtering-issue-and-merge-request-lists) from here.
![Group Issues list view](img/group_merge_requests_list_view.png) ![Group Issues list view](img/group_merge_requests_list_view.png)
......
...@@ -17,8 +17,8 @@ When you click **Issues**, you'll see the opened issues assigned to you straight ...@@ -17,8 +17,8 @@ When you click **Issues**, you'll see the opened issues assigned to you straight
You can search through **Open**, **Closed**, or **All** issues. You can search through **Open**, **Closed**, or **All** issues.
You can also filter the results using the search and filter field. This works in the same way as the ones found in the You can also filter the results using the search and filter field, as described below in
per project pages described below. [Filtering issue and merge request lists](#filtering-issue-and-merge-request-lists).
### Issues and MRs assigned to you or created by you ### Issues and MRs assigned to you or created by you
...@@ -27,19 +27,26 @@ on the search field on the top-right of your screen: ...@@ -27,19 +27,26 @@ on the search field on the top-right of your screen:
![shortcut to your issues and mrs](img/issues_mrs_shortcut.png) ![shortcut to your issues and mrs](img/issues_mrs_shortcut.png)
### Issues and merge requests per project ### Filtering issue and merge request lists
If you want to search for issues present in a specific project, navigate to Follow these steps to filter the **Issues** and **Merge Requests** list pages within projects and
a project's **Issues** tab, and click on the field **Search or filter results...**. It will groups:
display a dropdown menu, from which you can add filters per author, assignee, milestone,
release, label, weight, confidentiality, and "my-reaction" (based on your emoji votes).
When done, press **Enter** on your keyboard to filter the issues.
![filter issues in a project](img/issue_search_filter_v12_5.png) 1. Click in the field **Search or filter results...**.
1. In the dropdown menu that appears, select the attribute you wish to filter by (for example,
author, assignee, milestone, and so on).
1. Select or type the operator to use for filtering the attribute. The following operators are
available:
- `=`: Is
- `!=`: Is not ([Introduced](https://gitlab.com/gitlab-org/gitlab/issues/18059) in GitLab 12.7)
1. Enter the text to filter the attribute by.
1. Repeat this process to filter by multiple attributes. Multiple attributes are joined by a logical
`AND`.
The same process is valid for merge requests. Navigate to your project's **Merge Requests** tab, For example, filtering by Author `=` Jane and Milestone `!=` 12.6 filters for the issues where Jane
and click **Search or filter results...**. Merge requests can be filtered by author, assignee, is the author and the milestone is not 12.6.
approver, milestone, release, label, "my-reaction", "work in progess" status, and target branch.
![filter issues in a project](img/issue_search_filter_v12_7.png)
### Filtering by **None** / **Any** ### Filtering by **None** / **Any**
...@@ -66,16 +73,6 @@ You can filter issues and merge requests by specific terms included in titles or ...@@ -66,16 +73,6 @@ You can filter issues and merge requests by specific terms included in titles or
![filter issues by specific terms](img/issue_search_by_term.png) ![filter issues by specific terms](img/issue_search_by_term.png)
### Issues and merge requests per group
Similar to **Issues and merge requests per project**, you can also search for issues
within a group. Navigate to a group's **Issues** tab and query search results in
the same way as you do for projects.
![filter issues in a group](img/group_issues_filter.png)
The same process is valid for merge requests. Navigate to your project's **Merge Requests** tab.
## Search history ## Search history
You can view recent searches by clicking on the little arrow-clock icon, which is to the left of the search input. Click the search entry to run that search again. This feature is available for issues and merge requests. Searches are stored locally in your browser. You can view recent searches by clicking on the little arrow-clock icon, which is to the left of the search input. Click the search entry to run that search again. This feature is available for issues and merge requests. Searches are stored locally in your browser.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment