Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
parent
88542a5e96
commit
d2801eda84
|
@ -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;
|
||||
|
|
|
@ -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)),
|
||||
};
|
||||
});
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Remove reactive caching value keys once the alive key has expired
|
||||
merge_request: 20111
|
||||
author:
|
||||
type: performance
|
|
@ -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:
|
||||
|
||||
- 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,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"
|
||||
}
|
||||
})
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue