kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2019-11-19 18:06:27 +00:00
parent 88542a5e96
commit d2801eda84
9 changed files with 49 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
app/assets/javascripts/helpers/monitor_helper.js
View File

@ -7,6 +7,7 @@
export const makeDataSeries = (queryResults, defaultConfig) =>
queryResults
.map(result => {
// NaN values may disrupt avg., max. & min. calculations in the legend, filter them out
const data = result.values.filter(([, value]) => !Number.isNaN(value));
if (!data.length) {
return null;

1
app/assets/javascripts/monitoring/components/charts/anomaly.vue
View File

@ -66,6 +66,7 @@ export default {
const values = query.result[0] ? query.result[0].values : [];
return {
label: query.label,
// NaN values may disrupt avg., max. & min. calculations in the legend, filter them out
data: values.filter(([, value]) => !Number.isNaN(value)),
};
});

5
app/models/concerns/reactive_caching.rb
View File

@ -129,14 +129,17 @@ module ReactiveCaching
def exclusively_update_reactive_cache!(*args)
locking_reactive_cache(*args) do
key = full_reactive_cache_key(*args)
if within_reactive_cache_lifetime?(*args)
enqueuing_update(*args) do
key = full_reactive_cache_key(*args)
new_value = calculate_reactive_cache(*args)
old_value = Rails.cache.read(key)
Rails.cache.write(key, new_value)
reactive_cache_updated(*args) if new_value != old_value
end
else
Rails.cache.delete(key)
end
end
end

5
changelogs/unreleased/reactive-caching-self-cleanup.yml Normal file
View File

@ -0,0 +1,5 @@
---
title: Remove reactive caching value keys once the alive key has expired
merge_request: 20111
author:
type: performance

10
doc/administration/auth/smartcard.md
View File

@ -51,10 +51,14 @@ This is an experimental feature. Smartcard authentication against local database
change or be removed completely in future releases.
To use a smartcard with an X.509 certificate to authenticate against a local
database with GitLab, at least one of the `subjectAltName` (SAN) extensions
need to define the user identity (`email`) within the GitLab instance (`URI`).
database with GitLab, in:
`URI`: needs to match `Gitlab.config.host.gitlab`.
- GitLab 12.4 and later, at least one of the `subjectAltName` (SAN) extensions
need to define the user identity (`email`) within the GitLab instance (`URI`).
`URI`: needs to match `Gitlab.config.host.gitlab`.
- From [GitLab 12.5](https://gitlab.com/gitlab-org/gitlab/issues/33907),
if your certificate contains only **one** SAN email entry, you don't need to
add or modify it to match the `email` with the `URI`.
For example:

26
doc/administration/gitaly/praefect.md
View File

@ -26,9 +26,9 @@ For this document, the following network topology is assumed:
graph TB
GitLab --> Gitaly;
GitLab --> Praefect;
Praefect --> Praefect-Gitaly-1;
Praefect --> Praefect-Gitaly-2;
Praefect --> Praefect-Gitaly-3;
Praefect --> Gitaly-1;
Praefect --> Gitaly-2;
Praefect --> Gitaly-3;
```
Where `GitLab` is the collection of clients that can request Git operations.
@ -70,7 +70,7 @@ We need to manage the following secrets and make them match across hosts:
On the Praefect node we disable all other services, including Gitaly. We list each
Gitaly node that will be connected to Praefect under `praefect['storage_nodes']`.
In the example below, the Gitaly nodes are named `praefect-gitaly-N`. Note that one
In the example below, the Gitaly nodes are named `gitaly-N`. Note that one
node is designated as primary by setting the primary to `true`.
```ruby
@ -89,7 +89,7 @@ gitaly['enable'] = false
##### Set up Praefect and its Gitaly nodes
In the example below, the Gitaly nodes are named `praefect-git-X`. Note that one node is designated as
In the example below, the Gitaly nodes are named `gitaly-X`. Note that one node is designated as
primary, by setting the primary to `true`:
```ruby
@ -114,17 +114,17 @@ praefect['auth_token'] = 'PRAEFECT_EXTERNAL_TOKEN'
# Replace each instance of PRAEFECT_INTERNAL_TOKEN below with a real
# secret, distinct from PRAEFECT_EXTERNAL_TOKEN.
praefect['storage_nodes'] = {
'praefect-gitaly-1' => {
'address' => 'tcp://praefect-git-1.internal:8075',
'gitaly-1' => {
'address' => 'tcp://gitaly-1.internal:8075',
'token' => 'PRAEFECT_INTERNAL_TOKEN',
'primary' => true
},
'praefect-gitaly-2' => {
'address' => 'tcp://praefect-git-2.internal:8075',
'gitaly-2' => {
'address' => 'tcp://gitaly-2.internal:8075',
'token' => 'PRAEFECT_INTERNAL_TOKEN'
},
'praefect-gitaly-3' => {
'address' => 'tcp://praefect-git-3.internal:8075',
'gitaly-3' => {
'address' => 'tcp://gitaly-3.internal:8075',
'token' => 'PRAEFECT_INTERNAL_TOKEN'
}
}
@ -138,7 +138,7 @@ Next we will configure each Gitaly server assigned to Praefect. Configuration f
is the same as a normal standalone Gitaly server, except that we use storage names and
auth tokens from Praefect instead of GitLab.
Below is an example configuration for `praefect-gitaly-1`, the only difference for the
Below is an example configuration for `gitaly-1`, the only difference for the
other Gitaly nodes is the storage name under `git_data_dirs`.
Note that `gitaly['auth_token']` matches the `token` value listed under `praefect['storage_nodes']`
@ -177,7 +177,7 @@ gitaly['auth_token'] = 'PRAEFECT_INTERNAL_TOKEN'
gitaly['listen_addr'] = "0.0.0.0:8075"
git_data_dirs({
"praefect-gitaly-1" => {
"gitaly-1" => {
"path" => "/var/opt/gitlab/git-data"
}
})

4
doc/administration/troubleshooting/elasticsearch.md
View File

@ -171,7 +171,7 @@ To do this:
pp s.search_objects.class.name
```
The ouput from the last command is the key here. If it shows:
The output from the last command is the key here. If it shows:
- `ActiveRecord::Relation`, **it is not** using Elasticsearch.
- `Kaminari::PaginatableArray`, **it is** using Elasticsearch.
@ -326,7 +326,7 @@ feel free to update that page with issues you encounter and solutions.
Setting up Elasticsearch isn't too bad, but it can be a bit finnicky and time consuming.
The eastiest 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.
The following is an example of running a docker container of Elasticsearch v7.2.0:

7
doc/integration/sourcegraph.md
View File

@ -108,9 +108,10 @@ When visiting one of these views, you can now hover over a code reference to see
Sourcegraph powered code intelligence will be incrementally rolled out on GitLab.com.
It will eventually become available for all public projects, but for now, it is only
available for some specific [`gitlab-org` projects](https://gitlab.com/gitlab-org/).
This means that you can see it working and use it to dig into the code of these projects,
but you cannot use it on your own project on GitLab.com yet.
available for some specific projects within the [`gitlab-org`](https://gitlab.com/gitlab-org/)
group, e.g., <https://gitlab.com/gitlab-org/gitlab>. This means that you can see
it working and use it to dig into the code of these projects, but you cannot use
it on your own project on GitLab.com yet.
If you would like to use it in your own projects as of GitLab 12.5, you can do so by
setting up a self-managed GitLab instance.

12
spec/models/concerns/reactive_caching_spec.rb
View File

@ -196,6 +196,12 @@ describe ReactiveCaching, :use_clean_rails_memory_store_caching do
2.times { instance.exclusively_update_reactive_cache! }
end
it 'does not delete the value key' do
expect(Rails.cache).to receive(:delete).with(cache_key).never
go!
end
context 'and #calculate_reactive_cache raises an exception' do
before do
stub_reactive_cache(instance, "preexisting")
@ -223,6 +229,12 @@ describe ReactiveCaching, :use_clean_rails_memory_store_caching do
go!
end
it 'deletes the value key' do
expect(Rails.cache).to receive(:delete).with(cache_key).once
go!
end
end
context 'when the lease is already taken' do