diff options
28 files changed, 76 insertions, 52 deletions
diff --git a/GITLAB_SHELL_VERSION b/GITLAB_SHELL_VERSION index 0719d810258..275283a18f9 100644 --- a/GITLAB_SHELL_VERSION +++ b/GITLAB_SHELL_VERSION @@ -1 +1 @@ -10.3.0 +11.0.0 @@ -389,7 +389,7 @@ group :development, :test do gem 'png_quantizator', '~> 0.2.1', require: false - gem 'parallel', '~> 1.17.0', require: false + gem 'parallel', '~> 1.19', require: false end # Gems required in omnibus-gitlab pipeline diff --git a/Gemfile.lock b/Gemfile.lock index 91376b5ee58..c5f3dc3e5a4 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -1287,7 +1287,7 @@ DEPENDENCIES omniauth_crowd (~> 2.2.0) omniauth_openid_connect (~> 0.3.3) org-ruby (~> 0.9.12) - parallel (~> 1.17.0) + parallel (~> 1.19) peek (~> 1.1) pg (~> 1.1) png_quantizator (~> 0.2.1) diff --git a/changelogs/unreleased/11678-conan-job-tokens.yml b/changelogs/unreleased/11678-conan-job-tokens.yml new file mode 100644 index 00000000000..8b341ac6f65 --- /dev/null +++ b/changelogs/unreleased/11678-conan-job-tokens.yml @@ -0,0 +1,5 @@ +--- +title: Allow CI_JOB_TOKENS for Conan package registry authentication +merge_request: 22184 +author: +type: added diff --git a/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md b/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md index 743893d984a..800bb28c664 100644 --- a/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md +++ b/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md @@ -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) - [OpenLDAP](http://www.openldap.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/) > 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. diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md index f762c0417f4..17e2b66ce40 100644 --- a/doc/administration/gitaly/index.md +++ b/doc/administration/gitaly/index.md @@ -45,7 +45,7 @@ requiring a shared NFS mount for Git repository data. Between 11.4 and 11.8 the exception was the [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 -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. 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. The limit is applied per repository. In the example above, each on the Gitaly server can have at most 20 simultaneous PostUploadPack calls in 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. You can observe the behavior of this queue via the Gitaly logs and via @@ -762,7 +762,7 @@ Git implementation itself. Because Rugged+Unicorn was so efficient, GitLab's application code ended 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. When we migrated these Git lookups to Gitaly calls, we were suddenly @@ -927,7 +927,7 @@ Confirm the following are all true: ``` - 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) 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 diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md index 6193a40ac4f..597be6cc97e 100644 --- a/doc/administration/gitaly/praefect.md +++ b/doc/administration/gitaly/praefect.md @@ -31,7 +31,7 @@ graph TB ``` 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`. Praefect may be enabled on its own node or can be run on the GitLab server. diff --git a/doc/administration/high_availability/consul.md b/doc/administration/high_availability/consul.md index 392b9b76c31..790296e8db9 100644 --- a/doc/administration/high_availability/consul.md +++ b/doc/administration/high_availability/consul.md @@ -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. -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 diff --git a/doc/administration/job_logs.md b/doc/administration/job_logs.md index 6042786d101..fc37fbb170d 100644 --- a/doc/administration/job_logs.md +++ b/doc/administration/job_logs.md @@ -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 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. -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`. diff --git a/doc/administration/lfs/lfs_administration.md b/doc/administration/lfs/lfs_administration.md index f3b8029f487..fbf48619854 100644 --- a/doc/administration/lfs/lfs_administration.md +++ b/doc/administration/lfs/lfs_administration.md @@ -238,8 +238,8 @@ and [projects APIs](../../api/projects.md). ## 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`), -Sidekiq workers may encouter this error. This is because the uploading timed out with very large files. +If LFS integration is configured with Google Cloud Storage and background uploads (`background_upload: true` and `direct_upload: false`), +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. ```shell diff --git a/doc/administration/monitoring/prometheus/gitlab_metrics.md b/doc/administration/monitoring/prometheus/gitlab_metrics.md index 1b542d95d21..b0f1a5736b5 100644 --- a/doc/administration/monitoring/prometheus/gitlab_metrics.md +++ b/doc/administration/monitoring/prometheus/gitlab_metrics.md @@ -26,7 +26,7 @@ The following metrics are available: | 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_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_operation_duration_seconds` | Histogram | 10.2 | Cache access time | | | `gitlab_cache_operations_total` | Counter | 12.2 | Cache operations by controller/action | controller, action, operation | @@ -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_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_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_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 | | diff --git a/doc/administration/troubleshooting/elasticsearch.md b/doc/administration/troubleshooting/elasticsearch.md index 560c6b2f53a..a582e07b141 100644 --- a/doc/administration/troubleshooting/elasticsearch.md +++ b/doc/administration/troubleshooting/elasticsearch.md @@ -325,7 +325,7 @@ feel free to update that page with issues you encounter and solutions. ## 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 bind ports 9200/9300 so it can be used. diff --git a/doc/administration/troubleshooting/postgresql.md b/doc/administration/troubleshooting/postgresql.md index 65c6952bf1c..ab302c919b2 100644 --- a/doc/administration/troubleshooting/postgresql.md +++ b/doc/administration/troubleshooting/postgresql.md @@ -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) - 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) diff --git a/doc/administration/troubleshooting/sidekiq.md b/doc/administration/troubleshooting/sidekiq.md index 41657368ea4..91361dddf02 100644 --- a/doc/administration/troubleshooting/sidekiq.md +++ b/doc/administration/troubleshooting/sidekiq.md @@ -174,7 +174,7 @@ the query details. ## Managing Sidekiq queues 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 admin interface is not suitable due to scale of installation. diff --git a/doc/ci/chatops/README.md b/doc/ci/chatops/README.md index d9236b47a9a..ec3d13e7500 100644 --- a/doc/ci/chatops/README.md +++ b/doc/ci/chatops/README.md @@ -61,7 +61,7 @@ ls: ## 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 -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 diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md index e58fe5e4604..2d1abed0dc5 100644 --- a/doc/ci/docker/using_docker_images.md +++ b/doc/ci/docker/using_docker_images.md @@ -513,7 +513,7 @@ To define which should be used, the GitLab Runner process reads the configuratio NOTE: **Note:** 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 runtime. diff --git a/doc/ci/examples/deployment/README.md b/doc/ci/examples/deployment/README.md index 7af797f1851..dca11c40524 100644 --- a/doc/ci/examples/deployment/README.md +++ b/doc/ci/examples/deployment/README.md @@ -4,7 +4,7 @@ type: tutorial # 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 used with GitLab CI. diff --git a/doc/ci/jenkins/index.md b/doc/ci/jenkins/index.md index 6e9e723feb5..92fc4de986c 100644 --- a/doc/ci/jenkins/index.md +++ b/doc/ci/jenkins/index.md @@ -26,7 +26,7 @@ There are some high level differences between the products worth mentioning: feature. - 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 - 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 container images to set up your build environment. @@ -207,7 +207,7 @@ Because GitLab is integrated tightly with Git, SCM polling options for triggers #### `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 be set up to automatically build these images as needed and deploy them to the [container registry](../../user/packages/container_registry/index.md). diff --git a/doc/ci/merge_request_pipelines/index.md b/doc/ci/merge_request_pipelines/index.md index 9ac41f88ff6..efb39dd1c55 100644 --- a/doc/ci/merge_request_pipelines/index.md +++ b/doc/ci/merge_request_pipelines/index.md @@ -136,7 +136,7 @@ Review App set up, helping to save resources. ## 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 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 diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index c0b0590716d..e4c45d37e6d 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -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, 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**, -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. With this configuration, care must be taken to check that the most recent pipeline diff --git a/doc/development/code_review.md b/doc/development/code_review.md index 445feba384b..4bc963222f2 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -314,7 +314,7 @@ experience, refactors the existing code). Then: - Ensure the target branch is not too far behind master. If [master is red](https://about.gitlab.com/handbook/engineering/workflow/#broken-master), 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 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 diff --git a/doc/user/packages/conan_repository/index.md b/doc/user/packages/conan_repository/index.md index bf822169de4..bcf2fea24e3 100644 --- a/doc/user/packages/conan_repository/index.md +++ b/doc/user/packages/conan_repository/index.md @@ -223,7 +223,7 @@ There are two ways to remove a Conan package from the GitLab Package Registry. ```sh conan remove Hello/0.2@user/channel --remote=gitlab ``` - + You need to explicitly include the remote in this command, otherwise the package will only be removed from your local system cache. @@ -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 info`: View the info on a given 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). diff --git a/doc/user/project/issues/index.md b/doc/user/project/issues/index.md index 6abd6fd7047..f540dfe0e51 100644 --- a/doc/user/project/issues/index.md +++ b/doc/user/project/issues/index.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 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 view, you can also make certain changes [in bulk](../bulk_editing.md) to the displayed issues. diff --git a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md index edc7b317c94..21c8b5c682b 100644 --- a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md +++ b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md @@ -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**. 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).  @@ -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. -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.  diff --git a/doc/user/search/img/group_issues_filter.png b/doc/user/search/img/group_issues_filter.png Binary files differdeleted file mode 100644 index 45eced79b99..00000000000 --- a/doc/user/search/img/group_issues_filter.png +++ /dev/null diff --git a/doc/user/search/img/issue_search_filter_v12_5.png b/doc/user/search/img/issue_search_filter_v12_5.png Binary files differdeleted file mode 100644 index 1e2dd3d98a3..00000000000 --- a/doc/user/search/img/issue_search_filter_v12_5.png +++ /dev/null diff --git a/doc/user/search/img/issue_search_filter_v12_7.png b/doc/user/search/img/issue_search_filter_v12_7.png Binary files differnew file mode 100644 index 00000000000..8a4d0165cb6 --- /dev/null +++ b/doc/user/search/img/issue_search_filter_v12_7.png diff --git a/doc/user/search/index.md b/doc/user/search/index.md index 68aef567270..d7ca43b1164 100644 --- a/doc/user/search/index.md +++ b/doc/user/search/index.md @@ -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 also filter the results using the search and filter field. This works in the same way as the ones found in the -per project pages described below. +You can also filter the results using the search and filter field, as described below in +[Filtering issue and merge request lists](#filtering-issue-and-merge-request-lists). ### 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:  -### 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 -a project's **Issues** tab, and click on the field **Search or filter results...**. It will -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. +Follow these steps to filter the **Issues** and **Merge Requests** list pages within projects and +groups: - +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, -and click **Search or filter results...**. Merge requests can be filtered by author, assignee, -approver, milestone, release, label, "my-reaction", "work in progess" status, and target branch. +For example, filtering by Author `=` Jane and Milestone `!=` 12.6 filters for the issues where Jane +is the author and the milestone is not 12.6. + + ### Filtering by **None** / **Any** @@ -66,16 +73,6 @@ You can filter issues and merge requests by specific terms included in titles or  -### 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. - - - -The same process is valid for merge requests. Navigate to your project's **Merge Requests** tab. - ## 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. |
