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 2021-09-10 18:10:58 +00:00
parent 6a6824a5ce
commit 147194556a
17 changed files with 161 additions and 76 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
app/assets/javascripts/issue_show/components/description.vue
View File

@ -123,6 +123,7 @@ export default {
}
},
},
safeHtmlConfig: { ADD_TAGS: ['gl-emoji'] },
};
</script>
@ -136,7 +137,7 @@ export default {
>
<div
ref="gfm-content"
v-safe-html="descriptionHtml"
v-safe-html:[$options.safeHtmlConfig]="descriptionHtml"
:class="{
'issue-realtime-pre-pulse': preAnimation,
'issue-realtime-trigger-pulse': pulseAnimation,

2
app/assets/javascripts/lib/dompurify.js
View File

@ -3,7 +3,7 @@ import { getBaseURL, relativePathToAbsolute } from '~/lib/utils/url_utility';
const defaultConfig = {
// Safely allow SVG <use> tags
ADD_TAGS: ['use'],
ADD_TAGS: ['use', 'gl-emoji'],
// Prevent possible XSS attacks with data-* attributes used by @rails/ujs
// See https://gitlab.com/gitlab-org/gitlab-ui/-/issues/1421
FORBID_ATTR: ['data-remote', 'data-url', 'data-type', 'data-method'],

2
app/assets/stylesheets/pages/note_form.scss
View File

@ -37,7 +37,7 @@
.note-textarea {
display: block;
padding: 10px 0;
padding: 10px 1px;
color: $gl-text-color;
font-family: $regular-font;
border: 0;

35
doc/administration/geo/replication/version_specific_updates.md
View File

@ -11,6 +11,41 @@ Review this page for update instructions for your version. These steps
accompany the [general steps](updating_the_geo_sites.md#general-update-steps)
for updating Geo nodes.
## Updating to 14.1, 14.2, 14.3
We found an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336013) where the Container Registry replication wasn't fully working if you used multi-arch images. In case of a multi-arch image, only the primary architecture (for example `amd64`) would be replicated to the secondary node. This has been [fixed in GitLab 14.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67624) and was backported to 14.2 and 14.1, but manual steps are required to force a re-sync.
You can check if you are affected by running:
```shell
docker manifest inspect <SECONDARY_IMAGE_LOCATION> | jq '.mediaType'
```
Where `<SECONDARY_IMAGE_LOCATION>` is a container image on your secondary node.
If the output matches `application/vnd.docker.distribution.manifest.list.v2+json`
(there can be a `mediaType` entry at several levels, we only care about the top level entry),
then you don't need to do anything.
Otherwise, on all your **secondary** nodes, in a [Rails console](../../operations/rails_console.md), run the following:
```ruby
list_type = 'application/vnd.docker.distribution.manifest.list.v2+json'
Geo::ContainerRepositoryRegistry.synced.each do |gcr|
cr = gcr.container_repository
primary = Geo::ContainerRepositorySync.new(cr)
cr.tags.each do |tag|
primary_manifest = JSON.parse(primary.send(:client).repository_raw_manifest(cr.path, tag.name))
next unless primary_manifest['mediaType'].eql?(list_type)
cr.delete_tag_by_name(tag.name)
end
primary.execute
end
```
If you are running a version prior to 14.1 and are using Geo and multi-arch containers in your Container Registry, we recommend [upgrading](updating_the_geo_sites.md) to at least GitLab 14.1.
## Updating to GitLab 14.0/14.1
We found an issue where [Primary sites can not be removed from the UI](https://gitlab.com/gitlab-org/gitlab/-/issues/338231).

2
doc/administration/packages/container_registry.md
View File

@ -321,7 +321,7 @@ The different supported drivers are:
| Driver | Description |
|--------------|--------------------------------------|
| `filesystem` | Uses a path on the local file system |
| `Azure` | Microsoft Azure Blob Storage |
| `azure` | Microsoft Azure Blob Storage |
| `gcs` | Google Cloud Storage |
| `s3` | Amazon Simple Storage Service. Be sure to configure your storage bucket with the correct [S3 Permission Scopes](https://docs.docker.com/registry/storage-drivers/s3/#s3-permission-scopes). |
| `swift` | OpenStack Swift Object Storage |

18
doc/administration/pages/index.md
View File

@ -486,7 +486,7 @@ Authority (CA) in the system certificate store.
For Omnibus, this is fixed by [installing a custom CA in Omnibus GitLab](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
### Zip serving and cache configuration
### ZIP serving and cache configuration
> [Introduced](https://gitlab.com/gitlab-org/gitlab-pages/-/merge_requests/392) in GitLab 13.7.
@ -494,19 +494,19 @@ WARNING:
These are advanced settings. The recommended default values are set inside GitLab Pages. You should
change these settings only if absolutely necessary. Use extreme caution.
GitLab Pages can serve content from zip archives through object storage (an
GitLab Pages can serve content from ZIP archives through object storage (an
[issue](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/485) exists for supporting disk storage
as well). It uses an in-memory cache to increase the performance when serving content from a zip
as well). It uses an in-memory cache to increase the performance when serving content from a ZIP
archive. You can modify the cache behavior by changing the following configuration flags.
| Setting | Description |
| ------- | ----------- |
| `zip_cache_expiration` | The cache expiration interval of zip archives. Must be greater than zero to avoid serving stale content. Default is 60s. |
| `zip_cache_expiration` | The cache expiration interval of ZIP archives. Must be greater than zero to avoid serving stale content. Default is 60s. |
| `zip_cache_cleanup` | The interval at which archives are cleaned from memory if they have already expired. Default is 30s. |
| `zip_cache_refresh` | The time interval in which an archive is extended in memory if accessed before `zip_cache_expiration`. This works together with `zip_cache_expiration` to determine if an archive is extended in memory. See the [example below](#zip-cache-refresh-example) for important details. Default is 30s. |
| `zip_open_timeout` | The maximum time allowed to open a zip archive. Increase this time for big archives or slow network connections, as doing so may affect the latency of serving Pages. Default is 30s. |
| `zip_open_timeout` | The maximum time allowed to open a ZIP archive. Increase this time for big archives or slow network connections, as doing so may affect the latency of serving Pages. Default is 30s. |
#### Zip cache refresh example
#### ZIP cache refresh example
Archives are refreshed in the cache (extending the time they are held in memory) if they're accessed
before `zip_cache_expiration`, and the time left before expiring is less than or equal to
@ -520,7 +520,7 @@ opened) it's refreshed. This extends the time the archive remains in memory from
After an archive reaches `zip_cache_expiration`, it's marked as expired and removed on the next
`zip_cache_cleanup` interval.
![Zip cache configuration](img/zip_cache_configuration.png)
![ZIP cache configuration](img/zip_cache_configuration.png)
## Activate verbose logging for daemon
@ -1014,7 +1014,7 @@ If you use [object storage](#using-object-storage), you can disable local storag
Starting from GitLab 13.12, this setting also disables the [legacy storage](#migrate-legacy-storage-to-zip-storage), so if you were using NFS to serve Pages, you can completely disconnect from it.
## Migrate GitLab Pages to 14.0
## Prepare GitLab Pages for 14.0
In GitLab 14.0 a number of breaking changes were introduced which may require some user intervention.
The steps below describe the best way to migrate without causing any downtime for your GitLab instance.
@ -1372,7 +1372,7 @@ both servers.
GitLab 14.0 introduces a number of changes to GitLab Pages which may require manual intervention.
1. Firstly [follow the migration guide](#migrate-gitlab-pages-to-140).
1. Firstly [follow the migration guide](#prepare-gitlab-pages-for-140).
1. Try to upgrade to GitLab 14.3 or above. Some of the issues were fixed in GitLab 14.1, 14.2 and 14.3.
1. If it doesn't work, see [GitLab Pages logs](#how-to-see-gitlab-pages-logs), and if you see any errors there then search them on this page.

8
doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
View File

@ -243,7 +243,7 @@ project.update!(repository_read_only: true)
### Transfer project from one namespace to another
```ruby
p= Project.find_by_full_path('<project_path>')
p = Project.find_by_full_path('<project_path>')
# To set the owner of the project
current_user= p.creator
@ -416,7 +416,7 @@ p.create_wiki ### creates the wiki project on the filesystem
### In case of issue boards not loading properly and it's getting time out. We need to call the Issue Rebalancing service to fix this
```ruby
p=Project.find_by_full_path('PROJECT PATH')
p = Project.find_by_full_path('PROJECT PATH')
IssueRebalancingService.new(p.issues.take).execute
```
@ -999,8 +999,8 @@ This content has been moved to the [Troubleshooting Sidekiq docs](sidekiq.md).
### Get information about LFS objects and associated project
```ruby
o=LfsObject.find_by(oid: "<oid>")
p=Project.find(LfsObjectsProject.find_by_lfs_object_id(o.id).project_id)
o = LfsObject.find_by(oid: "<oid>")
p = Project.find(LfsObjectsProject.find_by_lfs_object_id(o.id).project_id)
```
You can then delete these records from the database with:

6
doc/administration/troubleshooting/postgresql.md
View File

@ -116,7 +116,7 @@ References:
ERROR: deadlock detected
```
Three applicable timeouts are identified in the issue [#1](https://gitlab.com/gitlab-org/gitlab/-/issues/30528); our recommended settings are as follows:
Three applicable timeouts are identified in the issue [#30528](https://gitlab.com/gitlab-org/gitlab/-/issues/30528); our recommended settings are as follows:
```ini
deadlock_timeout = 5s
@ -124,7 +124,7 @@ statement_timeout = 15s
idle_in_transaction_session_timeout = 60s
```
Quoting from issue [#1](https://gitlab.com/gitlab-org/gitlab/-/issues/30528):
Quoting from issue [#30528](https://gitlab.com/gitlab-org/gitlab/-/issues/30528):
> "If a deadlock is hit, and we resolve it through aborting the transaction after a short period, then the retry mechanisms we already have will make the deadlocked piece of work try again, and it's unlikely we'll deadlock multiple times in a row."
@ -146,7 +146,7 @@ PostgresSQL defaults:
- `statement_timeout = 0` (never)
- `idle_in_transaction_session_timeout = 0` (never)
Comments in issue [#1](https://gitlab.com/gitlab-org/gitlab/-/issues/30528)
Comments in issue [#30528](https://gitlab.com/gitlab-org/gitlab/-/issues/30528)
indicate that these should both be set to at least a number of minutes for all
Omnibus GitLab installations (so they don't hang indefinitely). However, 15s
for statement_timeout is very short, and will only be effective if the

2
doc/ci/caching/index.md
View File

@ -45,7 +45,7 @@ can't link to files outside it.
To ensure maximum availability of the cache, do one or more of the following:
- [Tag your runners](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
- [Tag your runners](../runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run) and use the tag on jobs
that share the cache.
- [Use runners that are only available to a particular project](../runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects).
- [Use a `key`](../yaml/index.md#cachekey) that fits your workflow. For example,

4
doc/ci/migration/jenkins.md
View File

@ -130,7 +130,7 @@ There are some important differences in the way runners work in comparison to ag
- Runners can be set up as [shared across an instance, be added at the group level, or set up at the project level](../runners/runners_scope.md).
They self-select jobs from the scopes you've defined automatically.
- You can also [use tags](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) for finer control, and
- You can also [use tags](../runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run) for finer control, and
associate runners with specific jobs. For example, you can use a tag for jobs that
require dedicated, more powerful, or specific hardware.
- GitLab has [autoscaling for runners](https://docs.gitlab.com/runner/configuration/autoscale.html).
@ -230,7 +230,7 @@ and is meant to be a mapping of concepts there to concepts in GitLab.
The agent section is used to define how a pipeline executes. For GitLab, we use [runners](../runners/index.md)
to provide this capability. You can configure your own runners in Kubernetes or on any host, or take advantage
of our shared runner fleet (note that the shared runner fleet is only available for GitLab.com users).
We also support using [tags](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) to direct different jobs
We also support using [tags](../runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run) to direct different jobs
to different runners (execution agents).
The `agent` section also allows you to define which Docker images should be used for execution, for which we use

48
doc/ci/runners/configure_runners.md
View File

@ -169,13 +169,13 @@ project.
![specific runner IP address](img/specific_runner_ip_address.png)
## Use tags to limit the number of jobs using the runner
## Use tags to control which jobs a runner can run
You must set up a runner to be able to run all the different types of jobs
that it may encounter on the projects it's shared over. This would be
problematic for large amounts of projects, if it weren't for tags.
GitLab CI tags are not the same as Git tags. GitLab CI tags are associated with runners.
GitLab CI/CD tags are not the same as Git tags. GitLab CI/CD tags are associated with runners.
Git tags are associated with commits.
By tagging a runner for the types of jobs it can handle, you can make sure
@ -184,6 +184,8 @@ shared runners will [only run the jobs they are equipped to run](../yaml/index.m
For instance, at GitLab we have runners tagged with `rails` if they contain
the appropriate dependencies to run Rails test suites.
### Set a runner to run untagged jobs
When you [register a runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick**
[tagged jobs](../yaml/index.md#tags).
To change this, you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project.
@ -238,6 +240,48 @@ Example 2:
1. A job that has no tags defined is executed and run.
1. A second job that has a `docker` tag defined is stuck.
### Use tags to run jobs on different platforms
You can use tags to run different jobs on different platforms. For
example, if you have an OS X runner with tag `osx` and a Windows runner with tag
`windows`, you can run a job on each platform:
```yaml
windows job:
stage:
- build
tags:
- windows
script:
- echo Hello, %USERNAME%!
osx job:
stage:
- build
tags:
- osx
script:
- echo "Hello, $USER!"
```
### Use CI/CD variables in tags
> Introduced in [GitLab 14.1](https://gitlab.com/gitlab-org/gitlab/-/issues/35742).
You can use [CI/CD variables](../variables/index.md) with `tags` for dynamic runner selection:
```yaml
variables:
KUBERNETES_RUNNER: kubernetes
job:
tags:
- docker
- $KUBERNETES_RUNNER
script:
- echo "Hello runner selector feature"
```
## Configure runner behavior with variables
You can use [CI/CD variables](../variables/index.md) to configure runner Git behavior

75
doc/ci/yaml/index.md
View File

@ -1830,16 +1830,22 @@ rspec:
> - A limit of 50 tags per job [enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/338929) in GitLab 14.3.
> - A limit of 50 tags per job [enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/339855) in GitLab 14.3.
In [GitLab 14.3](https://gitlab.com/gitlab-org/gitlab/-/issues/338479) and later, the number of tags must be less than `50`.
Use `tags` to select a specific runner from the list of all runners that are
available for the project.
When you register a runner, you can specify the runner's tags, for
example `ruby`, `postgres`, `development`.
example `ruby`, `postgres`, or `development`. To pick up and run a job, a runner must
be assigned every tag listed in the job.
In the following example, the job is run by a runner that
has both `ruby` and `postgres` tags defined.
**Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#custom-default-keyword-values).
**Possible inputs**:
- An array of tag names.
- [CI/CD variables](../runners/configure_runners.md#use-cicd-variables-in-tags) in GitLab 14.1 and later.
**Example of `tags`**:
```yaml
job:
@ -1848,42 +1854,16 @@ job:
- postgres
```
You can use tags to run different jobs on different platforms. For
example, if you have an OS X runner with tag `osx` and a Windows runner with tag
`windows`, you can run a job on each platform:
In this example, only runners with *both* the `ruby` and `postgres` tags can run the job.
```yaml
windows job:
stage:
- build
tags:
- windows
script:
- echo Hello, %USERNAME%!
**Additional details**:
osx job:
stage:
- build
tags:
- osx
script:
- echo "Hello, $USER!"
```
- In [GitLab 14.3](https://gitlab.com/gitlab-org/gitlab/-/issues/338479) and later,
the number of tags must be less than `50`.
In [GitLab 14.1 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/35742), you can
use [CI/CD variables](../variables/index.md) with `tags` for dynamic runner selection:
**Related topics**:
```yaml
variables:
KUBERNETES_RUNNER: kubernetes
job:
tags:
- docker
- $KUBERNETES_RUNNER
script:
- echo "Hello runner selector feature"
```
- [Use tags to control which jobs a runner can run](../runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run).
### `allow_failure`
@ -3403,7 +3383,22 @@ You can specify the number of [retry attempts for certain stages of job executio
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14887) in GitLab 12.3.
Use `timeout` to configure a timeout for a specific job. For example:
Use `timeout` to configure a timeout for a specific job. If the job runs for longer
than the timeout, the job fails.
The job-level timeout can be longer than the [project-level timeout](../pipelines/settings.md#set-a-limit-for-how-long-jobs-can-run).
but can't be longer than the [runner's timeout](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner).
**Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#custom-default-keyword-values).
**Possible inputs**: A period of time written in natural language. For example, these are all equivalent:
- `3600 seconds`
- `60 minutes`
- `one hour`
**Example of `timeout`**:
```yaml
build:
@ -3415,10 +3410,6 @@ test:
timeout: 3h 30m
```
The job-level timeout can exceed the
[project-level timeout](../pipelines/settings.md#set-a-limit-for-how-long-jobs-can-run) but can't
exceed the runner-specific timeout.
### `parallel`
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/21480) in GitLab 11.5.

2
lib/gitlab/database/load_balancing/host.rb
View File

@ -163,8 +163,6 @@ module Gitlab
def primary_write_location
load_balancer.primary_write_location
ensure
load_balancer.release_primary_connection
end
def database_replica_location

5
lib/gitlab/database/load_balancing/primary_host.rb
View File

@ -16,7 +16,8 @@ module Gitlab
end
def release_connection
@load_balancer.release_primary_connection
# no-op as releasing primary connections isn't needed.
nil
end
def enable_query_cache!
@ -51,8 +52,6 @@ module Gitlab
def primary_write_location
@load_balancer.primary_write_location
ensure
@load_balancer.release_primary_connection
end
def database_replica_location

15
spec/features/issues/issue_detail_spec.rb
View File

@ -32,6 +32,21 @@ RSpec.describe 'Issue Detail', :js do
end
end
context 'when issue description has emojis' do
let(:issue) { create(:issue, project: project, author: user, description: 'hello world :100:') }
before do
sign_in(user)
visit project_issue_path(project, issue)
end
it 'renders gl-emoji tag' do
page.within('.description') do
expect(page).to have_selector('gl-emoji', count: 1)
end
end
end
context 'when issue description has xss snippet' do
before do
issue.update!(description: '![xss" onload=alert(1);//](a)')

4
spec/frontend/lib/dompurify_spec.js
View File

@ -65,6 +65,10 @@ describe('~/lib/dompurify', () => {
expect(sanitize(htmlXlink)).toBe(htmlXlink);
});
it("doesn't sanitize gl-emoji", () => {
expect(sanitize('<p><gl-emoji>💯</gl-emoji></p>')).toBe('<p><gl-emoji>💯</gl-emoji></p>');
});
describe.each`
type | gon
${'root'} | ${rootGon}

6
spec/lib/gitlab/database/load_balancing/primary_host_spec.rb
View File

@ -20,10 +20,8 @@ RSpec.describe Gitlab::Database::LoadBalancing::PrimaryHost do
end
describe '#release_connection' do
it 'releases a connection from the pool' do
expect(load_balancer).to receive(:release_primary_connection)
host.release_connection
it 'does nothing' do
expect(host.release_connection).to be_nil
end
end