Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
2b3bfe8fc5
commit
30010b161d
28 changed files with 76 additions and 52 deletions
|
|
@ -1 +1 @@
|
|||
10.3.0
|
||||
11.0.0
|
||||
|
|
|
|||
2
Gemfile
2
Gemfile
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
5
changelogs/unreleased/11678-conan-job-tokens.yml
Normal file
5
changelogs/unreleased/11678-conan-job-tokens.yml
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
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
|
|||
- [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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 | |
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 44 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 493 KiB |
BIN
doc/user/search/img/issue_search_filter_v12_7.png
Normal file
BIN
doc/user/search/img/issue_search_filter_v12_7.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 182 KiB |
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue