Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
42e7c237bf
commit
35130a8688
|
|
@ -1,6 +1,5 @@
|
|||
<script>
|
||||
import { GlFormGroup, GlFormCheckbox, GlFormInput } from '@gitlab/ui';
|
||||
import { startCase } from 'lodash';
|
||||
import { mapGetters } from 'vuex';
|
||||
import { __ } from '~/locale';
|
||||
|
||||
|
|
@ -45,7 +44,6 @@ export default {
|
|||
fieldName(name) {
|
||||
return `service[${name}]`;
|
||||
},
|
||||
startCase,
|
||||
},
|
||||
};
|
||||
</script>
|
||||
|
|
@ -58,10 +56,10 @@ export default {
|
|||
data-testid="trigger-fields-group"
|
||||
>
|
||||
<div id="trigger-fields" class="gl-pt-3">
|
||||
<gl-form-group v-for="event in events" :key="event.title" :description="event.description">
|
||||
<gl-form-group v-for="event in events" :key="event.name" :description="event.description">
|
||||
<input :name="checkboxName(event.name)" type="hidden" :value="event.value || false" />
|
||||
<gl-form-checkbox v-model="event.value" :disabled="isInheriting">
|
||||
{{ startCase(event.title) }}
|
||||
{{ event.title }}
|
||||
</gl-form-checkbox>
|
||||
<gl-form-input
|
||||
v-if="event.field"
|
||||
|
|
|
|||
|
|
@ -1,6 +1,35 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module IntegrationsHelper
|
||||
def integration_event_title(event)
|
||||
case event
|
||||
when "push", "push_events"
|
||||
_("Push")
|
||||
when "tag_push", "tag_push_events"
|
||||
_("Tag push")
|
||||
when "note", "note_events"
|
||||
_("Note")
|
||||
when "confidential_note", "confidential_note_events"
|
||||
_("Confidential note")
|
||||
when "issue", "issue_events"
|
||||
_("Issue")
|
||||
when "confidential_issue", "confidential_issue_events"
|
||||
_("Confidential issue")
|
||||
when "merge_request", "merge_request_events"
|
||||
_("Merge request")
|
||||
when "pipeline", "pipeline_events"
|
||||
_("Pipeline")
|
||||
when "wiki_page", "wiki_page_events"
|
||||
_("Wiki page")
|
||||
when "commit", "commit_events"
|
||||
_("Commit")
|
||||
when "deployment"
|
||||
_("Deployment")
|
||||
when "alert"
|
||||
_("Alert")
|
||||
end
|
||||
end
|
||||
|
||||
def integration_event_description(integration, event)
|
||||
case integration
|
||||
when Integrations::Jira
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ class ServiceEventEntity < Grape::Entity
|
|||
include RequestAwareEntity
|
||||
|
||||
expose :title do |event|
|
||||
event
|
||||
IntegrationsHelper.integration_event_title(event)
|
||||
end
|
||||
|
||||
expose :event_field_name, as: :name
|
||||
|
|
|
|||
|
|
@ -831,9 +831,9 @@ for the changes to take effect.
|
|||
## Reverting to Basic Search
|
||||
|
||||
Sometimes there may be issues with your Elasticsearch index data and as such
|
||||
GitLab will allow you to revert to "basic search" when there are no search
|
||||
GitLab allows you to revert to "basic search" when there are no search
|
||||
results and assuming that basic search is supported in that scope. This "basic
|
||||
search" will behave as though you don't have Advanced Search enabled at all for
|
||||
search" behaves as though you don't have Advanced Search enabled at all for
|
||||
your instance and search using other data sources (such as PostgreSQL data and Git
|
||||
data).
|
||||
|
||||
|
|
@ -847,7 +847,7 @@ the Elasticsearch data store is ever corrupted for whatever reason, you can rein
|
|||
## Troubleshooting
|
||||
|
||||
One of the most valuable tools for identifying issues with the Elasticsearch
|
||||
integration will be logs. The most relevant logs for this integration are:
|
||||
integration are logs. The most relevant logs for this integration are:
|
||||
|
||||
1. [`sidekiq.log`](../administration/logs.md#sidekiqlog) - All of the
|
||||
indexing happens in Sidekiq, so much of the relevant logs for the
|
||||
|
|
@ -863,7 +863,7 @@ Here are some common pitfalls and how to overcome them.
|
|||
|
||||
There are a couple of ways to achieve that:
|
||||
|
||||
- Whenever you perform a search there will be a link on the search results page
|
||||
- Whenever you perform a search there is a link on the search results page
|
||||
in the top right hand corner saying "Advanced search functionality is enabled".
|
||||
This is always correctly identifying whether the current project/namespace
|
||||
being searched is using Elasticsearch.
|
||||
|
|
@ -923,7 +923,7 @@ See [Elasticsearch Index Scopes](#advanced-search-index-scopes) for more informa
|
|||
|
||||
### I indexed all the repositories but then switched Elasticsearch servers and now I can't find anything
|
||||
|
||||
You will need to re-run all the Rake tasks to reindex the database, repositories, and wikis.
|
||||
You must re-run all the Rake tasks to reindex the database, repositories, and wikis.
|
||||
|
||||
### The indexing process is taking a very long time
|
||||
|
||||
|
|
@ -938,7 +938,7 @@ You can run `sudo gitlab-rake gitlab:elastic:projects_not_indexed` to display pr
|
|||
NOTE:
|
||||
This was [fixed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35936) in GitLab 13.2 and the Rake task is not available for versions greater than that.
|
||||
|
||||
When performing the initial indexing of blobs, we lock all projects until the project finishes indexing. It could happen that an error during the process causes one or multiple projects to remain locked. In order to unlock them, run:
|
||||
When performing the initial indexing of blobs, we lock all projects until the project finishes indexing. It could happen that an error during the process causes one or multiple projects to remain locked. To unlock them, run:
|
||||
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:elastic:clear_locked_projects
|
||||
|
|
@ -946,8 +946,8 @@ sudo gitlab-rake gitlab:elastic:clear_locked_projects
|
|||
|
||||
### `Can't specify parent if no parent field has been configured` error
|
||||
|
||||
If you enabled Elasticsearch before GitLab 8.12 and have not rebuilt indexes you will get
|
||||
exception in lots of different cases:
|
||||
If you enabled Elasticsearch before GitLab 8.12 and have not rebuilt indexes, you get
|
||||
exceptions in lots of different cases:
|
||||
|
||||
```plaintext
|
||||
Elasticsearch::Transport::Transport::Errors::BadRequest([400] {
|
||||
|
|
@ -983,12 +983,12 @@ AWS has [fixed limits](https://docs.aws.amazon.com/opensearch-service/latest/dev
|
|||
|
||||
### My single node Elasticsearch cluster status never goes from `yellow` to `green` even though everything seems to be running properly
|
||||
|
||||
**For a single node Elasticsearch cluster the functional cluster health status will be yellow** (never green) because the primary shard is allocated but replicas cannot be as there is no other node to which Elasticsearch can assign a replica. This also applies if you are using the [Amazon OpenSearch](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/aes-handling-errors.html#aes-handling-errors-yellow-cluster-status) service.
|
||||
**For a single node Elasticsearch cluster the functional cluster health status is yellow** (never green) because the primary shard is allocated but replicas cannot be as there is no other node to which Elasticsearch can assign a replica. This also applies if you are using the [Amazon OpenSearch](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/aes-handling-errors.html#aes-handling-errors-yellow-cluster-status) service.
|
||||
|
||||
WARNING:
|
||||
Setting the number of replicas to `0` is discouraged (this is not allowed in the GitLab Elasticsearch Integration menu). If you are planning to add more Elasticsearch nodes (for a total of more than 1 Elasticsearch) the number of replicas will need to be set to an integer value larger than `0`. Failure to do so will result in lack of redundancy (losing one node will corrupt the index).
|
||||
Setting the number of replicas to `0` is discouraged (this is not allowed in the GitLab Elasticsearch Integration menu). If you are planning to add more Elasticsearch nodes (for a total of more than 1 Elasticsearch) the number of replicas needs to be set to an integer value larger than `0`. Failure to do so results in lack of redundancy (losing one node corrupts the index).
|
||||
|
||||
If you have a **hard requirement to have a green status for your single node Elasticsearch cluster**, please make sure you understand the risks outlined in the previous paragraph and then run the following query to set the number of replicas to `0`(the cluster will no longer try to create any shard replicas):
|
||||
If you have a **hard requirement to have a green status for your single node Elasticsearch cluster**, please make sure you understand the risks outlined in the previous paragraph and then run the following query to set the number of replicas to `0`(the cluster no longer tries to create any shard replicas):
|
||||
|
||||
```shell
|
||||
curl --request PUT localhost:9200/gitlab-production/_settings --header 'Content-Type: application/json' \
|
||||
|
|
@ -1008,7 +1008,7 @@ Gitlab::Elastic::Indexer::Error: time="2020-01-23T09:13:00Z" level=fatal msg="he
|
|||
```
|
||||
|
||||
You probably have not used either `http://` or `https://` as part of your value in the **"URL"** field of the Elasticsearch Integration Menu. Please make sure you are using either `http://` or `https://` in this field as the [Elasticsearch client for Go](https://github.com/olivere/elastic) that we are using [needs the prefix for the URL to be accepted as valid](https://github.com/olivere/elastic/commit/a80af35aa41856dc2c986204e2b64eab81ccac3a).
|
||||
Once you have corrected the formatting of the URL, delete the index (via the [dedicated Rake task](#gitlab-advanced-search-rake-tasks)) and [reindex the content of your instance](#enable-advanced-search).
|
||||
After you have corrected the formatting of the URL, delete the index (via the [dedicated Rake task](#gitlab-advanced-search-rake-tasks)) and [reindex the content of your instance](#enable-advanced-search).
|
||||
|
||||
### My Elasticsearch cluster has a plugin and the integration is not working
|
||||
|
||||
|
|
@ -1041,8 +1041,8 @@ using the above [troubleshooting](#troubleshooting) steps.
|
|||
If there are no other options, then you always have the option of recreating the
|
||||
entire index from scratch. If you have a small GitLab installation, this can
|
||||
sometimes be a quick way to resolve a problem, but if you have a large GitLab
|
||||
installation, then this will likely take a very long time to complete. Until the
|
||||
index is fully recreated, your index will not be serving correct search results,
|
||||
installation, then this might take a very long time to complete. Until the
|
||||
index is fully recreated, your index does not serve correct search results,
|
||||
so you may want to disable **Search with Elasticsearch** while it is running.
|
||||
|
||||
If you are sure you've read the above caveats and want to proceed, then you
|
||||
|
|
@ -1065,9 +1065,9 @@ sudo -u git -H bundle exec rake gitlab:elastic:index
|
|||
|
||||
### How does Advanced Search handle private projects?
|
||||
|
||||
Advanced Search will store all the projects in the same Elasticsearch indexes,
|
||||
however searches will only surface results that can be viewed by the user.
|
||||
Advanced Search will honor all permission checks in the application by
|
||||
Advanced Search stores all the projects in the same Elasticsearch indexes,
|
||||
however, searches only surface results that can be viewed by the user.
|
||||
Advanced Search honors all permission checks in the application by
|
||||
filtering out projects that a user does not have access to at search time.
|
||||
|
||||
### Indexing fails with `error: elastic: Error 429 (Too Many Requests)`
|
||||
|
|
|
|||
|
|
@ -3150,6 +3150,9 @@ msgstr ""
|
|||
msgid "Akismet helps prevent the creation of spam issues in public projects."
|
||||
msgstr ""
|
||||
|
||||
msgid "Alert"
|
||||
msgstr ""
|
||||
|
||||
msgid "AlertManagement|Acknowledged"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -9110,6 +9113,12 @@ msgstr ""
|
|||
msgid "Confidential"
|
||||
msgstr ""
|
||||
|
||||
msgid "Confidential issue"
|
||||
msgstr ""
|
||||
|
||||
msgid "Confidential note"
|
||||
msgstr ""
|
||||
|
||||
msgid "Confidentiality"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -12194,6 +12203,9 @@ msgstr ""
|
|||
msgid "Deploying to AWS is easy with GitLab"
|
||||
msgstr ""
|
||||
|
||||
msgid "Deployment"
|
||||
msgstr ""
|
||||
|
||||
msgid "Deployment Frequency"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -35822,6 +35834,9 @@ msgstr ""
|
|||
msgid "Tag name is required"
|
||||
msgstr ""
|
||||
|
||||
msgid "Tag push"
|
||||
msgstr ""
|
||||
|
||||
msgid "Tag push events"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -40564,6 +40579,9 @@ msgstr ""
|
|||
msgid "Vulnerabilities over time"
|
||||
msgstr ""
|
||||
|
||||
msgid "Vulnerability"
|
||||
msgstr ""
|
||||
|
||||
msgid "Vulnerability Report"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -41373,6 +41391,9 @@ msgstr ""
|
|||
msgid "Wiki"
|
||||
msgstr ""
|
||||
|
||||
msgid "Wiki page"
|
||||
msgstr ""
|
||||
|
||||
msgid "Wiki page was successfully created."
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ RSpec.describe 'User activates JetBrains TeamCity CI' do
|
|||
it 'activates integration', :js do
|
||||
visit_project_integration('JetBrains TeamCity')
|
||||
check('Push')
|
||||
check('Merge Request')
|
||||
check('Merge request')
|
||||
fill_in('TeamCity server URL', with: 'http://teamcity.example.com')
|
||||
fill_in('Build type', with: 'GitlabTest_Build')
|
||||
fill_in('Username', with: 'user')
|
||||
|
|
|
|||
|
|
@ -40,13 +40,13 @@ describe('TriggerFields', () => {
|
|||
describe('events without field property', () => {
|
||||
const events = [
|
||||
{
|
||||
title: 'push',
|
||||
title: 'Push',
|
||||
name: 'push_event',
|
||||
description: 'Event on push',
|
||||
value: true,
|
||||
},
|
||||
{
|
||||
title: 'merge_request',
|
||||
title: 'Merge request',
|
||||
name: 'merge_requests_event',
|
||||
description: 'Event on merge_request',
|
||||
value: false,
|
||||
|
|
@ -81,7 +81,7 @@ describe('TriggerFields', () => {
|
|||
const checkboxes = findAllGlFormGroups();
|
||||
const expectedResults = [
|
||||
{ labelText: 'Push', inputName: 'service[push_event]' },
|
||||
{ labelText: 'Merge Request', inputName: 'service[merge_requests_event]' },
|
||||
{ labelText: 'Merge request', inputName: 'service[merge_requests_event]' },
|
||||
];
|
||||
expect(checkboxes).toHaveLength(2);
|
||||
|
||||
|
|
|
|||
|
|
@ -3,17 +3,41 @@
|
|||
require 'spec_helper'
|
||||
|
||||
RSpec.describe IntegrationsHelper do
|
||||
shared_examples 'is defined for each integration event' do
|
||||
Integration.available_integration_names.each do |integration|
|
||||
events = Integration.integration_name_to_model(integration).new.configurable_events
|
||||
events.each do |event|
|
||||
context "when integration is #{integration}, event is #{event}" do
|
||||
let(:integration) { integration }
|
||||
let(:event) { event }
|
||||
|
||||
it { is_expected.not_to be_nil }
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe '#integration_event_title' do
|
||||
subject { helper.integration_event_title(event) }
|
||||
|
||||
it_behaves_like 'is defined for each integration event'
|
||||
end
|
||||
|
||||
describe '#integration_event_description' do
|
||||
subject(:description) { helper.integration_event_description(integration, 'merge_request_events') }
|
||||
subject { helper.integration_event_description(integration, event) }
|
||||
|
||||
it_behaves_like 'is defined for each integration event'
|
||||
|
||||
context 'when integration is Jira' do
|
||||
let(:integration) { Integrations::Jira.new }
|
||||
let(:event) { 'merge_request_events' }
|
||||
|
||||
it { is_expected.to include('Jira') }
|
||||
end
|
||||
|
||||
context 'when integration is Team City' do
|
||||
let(:integration) { Integrations::Teamcity.new }
|
||||
let(:event) { 'merge_request_events' }
|
||||
|
||||
it { is_expected.to include('TeamCity') }
|
||||
end
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ RSpec.describe ServiceEventEntity do
|
|||
it 'exposes correct attributes' do
|
||||
expect(subject[:description]).to eq('Trigger event for pushes to the repository.')
|
||||
expect(subject[:name]).to eq('push_events')
|
||||
expect(subject[:title]).to eq('push')
|
||||
expect(subject[:title]).to eq('Push')
|
||||
expect(subject[:value]).to be(true)
|
||||
end
|
||||
end
|
||||
|
|
@ -31,7 +31,7 @@ RSpec.describe ServiceEventEntity do
|
|||
it 'exposes correct attributes' do
|
||||
expect(subject[:description]).to eq('Trigger event for new comments.')
|
||||
expect(subject[:name]).to eq('note_events')
|
||||
expect(subject[:title]).to eq('note')
|
||||
expect(subject[:title]).to eq('Note')
|
||||
expect(subject[:value]).to eq(false)
|
||||
expect(subject[:field][:name]).to eq('note_channel')
|
||||
expect(subject[:field][:value]).to eq('note-channel')
|
||||
|
|
|
|||
|
|
@ -22,10 +22,7 @@ RSpec.shared_examples 'integration settings form' do
|
|||
|
||||
events = parse_json(trigger_events_for_integration(integration))
|
||||
events.each do |trigger|
|
||||
# normalizing the title because capybara location is case sensitive
|
||||
title = normalize_title trigger[:title], integration
|
||||
|
||||
expect(page).to have_field(title, type: 'checkbox', wait: 0),
|
||||
expect(page).to have_field(trigger[:title], type: 'checkbox', wait: 0),
|
||||
"#{integration.title} field #{title} checkbox not present"
|
||||
end
|
||||
end
|
||||
|
|
@ -35,12 +32,6 @@ RSpec.shared_examples 'integration settings form' do
|
|||
|
||||
private
|
||||
|
||||
def normalize_title(title, integration)
|
||||
return 'Merge request' if integration.is_a?(Integrations::Jira) && title == 'merge_request'
|
||||
|
||||
title.titlecase
|
||||
end
|
||||
|
||||
def parse_json(json)
|
||||
Gitlab::Json.parse(json, symbolize_names: true)
|
||||
end
|
||||
|
|
|
|||
Loading…
Reference in New Issue