Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
b51f959ffa
commit
7bea85341e
|
|
@ -500,7 +500,6 @@ RSpec/NamedSubject:
|
|||
- 'ee/spec/lib/gitlab/search/aggregation_parser_spec.rb'
|
||||
- 'ee/spec/lib/gitlab/search/aggregation_spec.rb'
|
||||
- 'ee/spec/lib/gitlab/search/client_spec.rb'
|
||||
- 'ee/spec/lib/gitlab/search/zoekt/client_spec.rb'
|
||||
- 'ee/spec/lib/gitlab/search_context/builder_spec.rb'
|
||||
- 'ee/spec/lib/gitlab/sitemaps/generator_spec.rb'
|
||||
- 'ee/spec/lib/gitlab/sitemaps/sitemap_file_spec.rb'
|
||||
|
|
|
|||
2
Gemfile
2
Gemfile
|
|
@ -28,7 +28,7 @@ gem 'rails', '~> 7.0.8' # rubocop:todo Gemfile/MissingFeatureCategory
|
|||
|
||||
gem 'activerecord-gitlab', path: 'gems/activerecord-gitlab' # rubocop:todo Gemfile/MissingFeatureCategory
|
||||
|
||||
gem 'bootsnap', '~> 1.18.1', require: false # rubocop:todo Gemfile/MissingFeatureCategory
|
||||
gem 'bootsnap', '~> 1.17.1', require: false # rubocop:todo Gemfile/MissingFeatureCategory
|
||||
|
||||
gem 'openssl', '~> 3.0' # rubocop:todo Gemfile/MissingFeatureCategory
|
||||
gem 'ipaddr', '~> 1.2.5' # rubocop:todo Gemfile/MissingFeatureCategory
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@
|
|||
{"name":"better_errors","version":"2.10.1","platform":"ruby","checksum":"f798f1bac93f3e775925b7fcb24cffbcf0bb62ee2210f5350f161a6b75fc0a73"},
|
||||
{"name":"bindata","version":"2.4.11","platform":"ruby","checksum":"c38e0c99ffcd80c10a0a7ae6c8586d2fe26bf245cbefac90bec8764523220f6a"},
|
||||
{"name":"binding_of_caller","version":"1.0.0","platform":"ruby","checksum":"3aad25d1d538fc6e7972978f9bf512ccd992784009947c81633bea776713161d"},
|
||||
{"name":"bootsnap","version":"1.18.1","platform":"ruby","checksum":"8fca5d4b1f98cf29e4f512ea1809c0cd903424d0330d1d2c4fd78adb5d11b8a6"},
|
||||
{"name":"bootsnap","version":"1.17.1","platform":"ruby","checksum":"dbb2c6d4d594b0c87854f34a9073c9114a0c9a1023b8579e2eaaeb28848b1809"},
|
||||
{"name":"browser","version":"5.3.1","platform":"ruby","checksum":"62745301701ff2c6c5d32d077bb12532b20be261929dcb52c6781ed0d5658b3c"},
|
||||
{"name":"builder","version":"3.2.4","platform":"ruby","checksum":"99caf08af60c8d7f3a6b004029c4c3c0bdaebced6c949165fe98f1db27fbbc10"},
|
||||
{"name":"bullet","version":"7.1.2","platform":"ruby","checksum":"429725c174cb74ca0ae99b9720bf22cab80be59ee9401805f7ecc9ac62cbb3bb"},
|
||||
|
|
|
|||
|
|
@ -355,7 +355,7 @@ GEM
|
|||
bindata (2.4.11)
|
||||
binding_of_caller (1.0.0)
|
||||
debug_inspector (>= 0.0.1)
|
||||
bootsnap (1.18.1)
|
||||
bootsnap (1.17.1)
|
||||
msgpack (~> 1.2)
|
||||
browser (5.3.1)
|
||||
builder (3.2.4)
|
||||
|
|
@ -1836,7 +1836,7 @@ DEPENDENCIES
|
|||
benchmark-ips (~> 2.11.0)
|
||||
benchmark-memory (~> 0.1)
|
||||
better_errors (~> 2.10.1)
|
||||
bootsnap (~> 1.18.1)
|
||||
bootsnap (~> 1.17.1)
|
||||
browser (~> 5.3.1)
|
||||
bullet (~> 7.1.2)
|
||||
bundler-audit (~> 0.9.1)
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ import { isValidDate } from '~/lib/utils/datetime_utility';
|
|||
import * as Sentry from '~/sentry/sentry_browser_wrapper';
|
||||
import axios from '~/lib/utils/axios_utils';
|
||||
import { logError } from '~/lib/logger';
|
||||
import { DEFAULT_SORTING_OPTION, SORTING_OPTIONS } from './constants';
|
||||
import { DEFAULT_SORTING_OPTION, SORTING_OPTIONS, CUSTOM_DATE_RANGE_OPTION } from './constants';
|
||||
|
||||
function reportErrorAndThrow(e) {
|
||||
logError(e);
|
||||
|
|
@ -358,7 +358,7 @@ function addMetricsDateRangeFilterToQueryParams(dateRangeFilter, params) {
|
|||
if (!dateRangeFilter || !params) return;
|
||||
|
||||
const { value, endDate, startDate } = dateRangeFilter;
|
||||
if (value === 'custom') {
|
||||
if (value === CUSTOM_DATE_RANGE_OPTION) {
|
||||
if (isValidDate(startDate) && isValidDate(endDate)) {
|
||||
params.append('start_time', startDate.toISOString());
|
||||
params.append('end_time', endDate.toISOString());
|
||||
|
|
|
|||
|
|
@ -9,17 +9,30 @@ export const SORTING_OPTIONS = {
|
|||
Object.freeze(SORTING_OPTIONS);
|
||||
export const DEFAULT_SORTING_OPTION = SORTING_OPTIONS.TIMESTAMP_DESC;
|
||||
|
||||
export const TIME_RANGE_OPTIONS_VALUES = {
|
||||
FIVE_MIN: '5m',
|
||||
FIFTEEN_MIN: '15m',
|
||||
THIRTY_MIN: '30m',
|
||||
ONE_HOUR: '1h',
|
||||
FOUR_HOURS: '4h',
|
||||
TWELVE_HOURS: '12h',
|
||||
ONE_DAY: '24h',
|
||||
ONE_WEEK: '7d',
|
||||
TWO_WEEKS: '14d',
|
||||
ONE_MONTH: '30d',
|
||||
};
|
||||
|
||||
export const TIME_RANGE_OPTIONS = [
|
||||
{ value: '5m', title: s__('Observability|Last 5 minutes') },
|
||||
{ value: '15m', title: s__('Observability|Last 15 minutes') },
|
||||
{ value: '30m', title: s__('Observability|Last 30 minutes') },
|
||||
{ value: '1h', title: s__('Observability|Last 1 hour') },
|
||||
{ value: '4h', title: s__('Observability|Last 4 hours') },
|
||||
{ value: '12h', title: s__('Observability|Last 12 hours') },
|
||||
{ value: '24h', title: s__('Observability|Last 24 hours') },
|
||||
{ value: '7d', title: s__('Observability|Last 7 days') },
|
||||
{ value: '14d', title: s__('Observability|Last 14 days') },
|
||||
{ value: '30d', title: s__('Observability|Last 30 days') },
|
||||
{ value: TIME_RANGE_OPTIONS_VALUES.FIVE_MIN, title: s__('Observability|Last 5 minutes') },
|
||||
{ value: TIME_RANGE_OPTIONS_VALUES.FIFTEEN_MIN, title: s__('Observability|Last 15 minutes') },
|
||||
{ value: TIME_RANGE_OPTIONS_VALUES.THIRTY_MIN, title: s__('Observability|Last 30 minutes') },
|
||||
{ value: TIME_RANGE_OPTIONS_VALUES.ONE_HOUR, title: s__('Observability|Last 1 hour') },
|
||||
{ value: TIME_RANGE_OPTIONS_VALUES.FOUR_HOURS, title: s__('Observability|Last 4 hours') },
|
||||
{ value: TIME_RANGE_OPTIONS_VALUES.TWELVE_HOURS, title: s__('Observability|Last 12 hours') },
|
||||
{ value: TIME_RANGE_OPTIONS_VALUES.ONE_DAY, title: s__('Observability|Last 24 hours') },
|
||||
{ value: TIME_RANGE_OPTIONS_VALUES.ONE_WEEK, title: s__('Observability|Last 7 days') },
|
||||
{ value: TIME_RANGE_OPTIONS_VALUES.TWO_WEEKS, title: s__('Observability|Last 14 days') },
|
||||
{ value: TIME_RANGE_OPTIONS_VALUES.ONE_MONTH, title: s__('Observability|Last 30 days') },
|
||||
];
|
||||
Object.freeze(TIME_RANGE_OPTIONS);
|
||||
|
||||
|
|
@ -31,3 +44,5 @@ const OPERERATOR_NOT_LIKE_TEXT = s__('ObservabilityMetrics|is not like');
|
|||
const OPERATORS_LIKE = [{ value: OPERERATOR_LIKE, description: OPERERATOR_LIKE_TEXT }];
|
||||
const OPERATORS_NOT_LIKE = [{ value: OPERERATOR_NOT_LIKE, description: OPERERATOR_NOT_LIKE_TEXT }];
|
||||
export const OPERATORS_LIKE_NOT = [...OPERATORS_LIKE, ...OPERATORS_NOT_LIKE];
|
||||
|
||||
export const CUSTOM_DATE_RANGE_OPTION = 'custom';
|
||||
|
|
|
|||
|
|
@ -67,6 +67,13 @@ class IssuesFinder < IssuableFinder
|
|||
super.with_projects_matching_search_data
|
||||
end
|
||||
|
||||
override :use_full_text_search?
|
||||
def use_full_text_search?
|
||||
return false if include_namespace_level_work_items?
|
||||
|
||||
super
|
||||
end
|
||||
|
||||
override :by_parent
|
||||
def by_parent(items)
|
||||
return super unless include_namespace_level_work_items?
|
||||
|
|
|
|||
|
|
@ -8,3 +8,12 @@ description: Stores unit test failure data produced from builds.
|
|||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56137
|
||||
milestone: '13.11'
|
||||
gitlab_schema: gitlab_ci
|
||||
desired_sharding_key:
|
||||
project_id:
|
||||
references: projects
|
||||
backfill_via:
|
||||
parent:
|
||||
foreign_key: unit_test_id
|
||||
table: ci_unit_tests
|
||||
sharding_key: project_id
|
||||
belongs_to: unit_test
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
stage: Data Stores
|
||||
stage: Systems
|
||||
group: Cloud Connector
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
stage: Data Stores
|
||||
stage: Systems
|
||||
group: Cloud Connector
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
stage: Data Stores
|
||||
stage: Systems
|
||||
group: Cloud Connector
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
stage: Data Stores
|
||||
stage: Systems
|
||||
group: Cloud Connector
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
stage: Data Stores
|
||||
stage: Systems
|
||||
group: Cloud Connector
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
stage: Data Stores
|
||||
stage: Systems
|
||||
group: Cloud Connector
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
|
|
|||
|
|
@ -136,7 +136,8 @@ The GitLab Support team can then look up why this is failing in the GitLab.com s
|
|||
NOTE:
|
||||
These steps can only be completed by GitLab Support.
|
||||
|
||||
In Kibana, the logs should be filtered for `json.meta.caller_id: JiraConnect::InstallationsController#update` and `NOT json.status: 200`.
|
||||
[In Kibana](https://log.gprd.gitlab.net/app/r/s/0FdPP), the logs should be filtered for
|
||||
`json.meta.caller_id: JiraConnect::InstallationsController#update` and `NOT json.status: 200`.
|
||||
If you have been provided the `X-Request-Id` value, you can use that against `json.correlation_id` to narrow down the results.
|
||||
|
||||
Each `GET` request to the Jira Connect Proxy URL `https://gitlab.com/-/jira_connect/installations` generates two log entries.
|
||||
|
|
@ -146,12 +147,17 @@ For the first log:
|
|||
- `json.status` is `422`.
|
||||
- `json.params.value` should match the GitLab self-managed URL `[[FILTERED], {"instance_url"=>"https://gitlab.example.com"}]`.
|
||||
|
||||
For the second log:
|
||||
For the second log, you might have one of the following scenarios:
|
||||
|
||||
- `json.message` is `Proxy lifecycle event received error response` or similar.
|
||||
- `json.jira_status_code` and `json.jira_body` might contain details on why GitLab.com wasn't able to connect back to the self-managed instance.
|
||||
- If `json.jira_status_code` is `401` and `json.jira_body` is empty, [**Jira Connect Proxy URL**](jira_cloud_app.md#set-up-your-instance) might not be set to
|
||||
- Scenario 1:
|
||||
- `json.message`, `json.jira_status_code`, and `json.jira_body` are present.
|
||||
- `json.message` is `Proxy lifecycle event received error response` or similar.
|
||||
- `json.jira_status_code` and `json.jira_body` might contain the response received from the self-managed instance or a proxy in front of the instance.
|
||||
- If `json.jira_status_code` is `401` and `json.jira_body` is empty, [**Jira Connect Proxy URL**](jira_cloud_app.md#set-up-your-instance) might not be set to
|
||||
`https://gitlab.com`.
|
||||
- Scenario 2:
|
||||
- `json.exception.class` and `json.exception.message` are present.
|
||||
- `json.exception.class` and `json.exception.message` contain whether an issue occurred while contacting the self-managed instance.
|
||||
|
||||
## Error when connecting the app
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
stage: Data Stores
|
||||
stage: Systems
|
||||
group: Cloud Connector
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
|
|
|||
|
|
@ -351,7 +351,7 @@ def replenish_table_seq(table, lower_limit, count)
|
|||
return if max_id - last_id > lower_limit
|
||||
|
||||
new_start, new_limit = post("/api/v4/internal/cells/database/claim", { table: table, count: count })
|
||||
execute("ALTER SEQUENCE START ? MAXVALUE ?", new_start, new_limit)
|
||||
execute("ALTER SEQUENCE RESTART ? MAXVALUE ?", new_start, new_limit)
|
||||
end
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ Consider the following workflow:
|
|||
|
||||
## How it works
|
||||
|
||||
First, GitLab Runner uploads all [JUnit report format XML files](https://www.ibm.com/docs/en/adfz/developer-for-zos/14.1.0?topic=formats-junit-xml-format)
|
||||
First, GitLab Runner uploads all [JUnit report format XML files](https://www.ibm.com/docs/en/developer-for-zos/16.0?topic=formats-junit-xml-format)
|
||||
as [artifacts](../yaml/artifacts_reports.md#artifactsreportsjunit) to GitLab. Then, when you visit a merge request, GitLab starts
|
||||
comparing the head and base branch's JUnit report format XML files, where:
|
||||
|
||||
|
|
|
|||
|
|
@ -283,7 +283,7 @@ The exceptions to the [original dotenv rules](https://github.com/motdotla/dotenv
|
|||
|
||||
## `artifacts:reports:junit`
|
||||
|
||||
The `junit` report collects [JUnit report format XML files](https://www.ibm.com/docs/en/adfz/developer-for-zos/14.1.0?topic=formats-junit-xml-format).
|
||||
The `junit` report collects [JUnit report format XML files](https://www.ibm.com/docs/en/developer-for-zos/16.0?topic=formats-junit-xml-format).
|
||||
The collected Unit test reports upload to GitLab as an artifact. Although JUnit was originally developed in Java, there
|
||||
are many third-party ports for other languages such as JavaScript, Python, and Ruby.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
stage: Data Stores
|
||||
stage: Systems
|
||||
group: Cloud Connector
|
||||
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
stage: Data Stores
|
||||
stage: Systems
|
||||
group: Cloud Connector
|
||||
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
|
||||
---
|
||||
|
|
|
|||
|
|
@ -64,28 +64,48 @@ On our SaaS instance both individual events and pre-computed metrics are availab
|
|||
Additionally for SaaS page views are automatically instrumented.
|
||||
For self-managed only the metrics instrumented on the version installed on the instance are available.
|
||||
|
||||
### Events
|
||||
|
||||
Events are collected in real-time but processed in an asynchronous manner.
|
||||
In general events are available in the data warehouse at the latest 48 hours after being fired but can already be available earlier.
|
||||
|
||||
### Metrics
|
||||
|
||||
Metrics are being computed and sent once per week for every instance. On GitLab.com this happens on Sunday and newest values become available throughout Monday.
|
||||
On self-managed this depends on the particular instance. In general, only the metrics instrumented for the installed GitLab version will be sent.
|
||||
|
||||
## Data discovery
|
||||
|
||||
The data visualization tools [Sisense](https://about.gitlab.com/handbook/business-technology/data-team/platform/sisensecdt/) and [Tableau](https://about.gitlab.com/handbook/business-technology/data-team/platform/tableau/),
|
||||
which have access to our Data Warehouse, can be used to query the internal analytics data.
|
||||
Event and metrics data is ultimately stored in our [Snowflake data warehouse](https://handbook.gitlab.com/handbook/business-technology/data-team/platform/snowflake/).
|
||||
It can either be accessed directly via SQL in Snowflake for [ad-hoc analyses](https://handbook.gitlab.com/handbook/business-technology/data-team/platform/#snowflake-analyst) or visualized in our data visualization tool
|
||||
[Tableau](https://about.gitlab.com/handbook/business-technology/data-team/platform/tableau/), which has access to Snowflake.
|
||||
Both platforms need an access request ([Snowflake](https://handbook.gitlab.com/handbook/business-technology/data-team/platform/#warehouse-access), [Tableau](https://handbook.gitlab.com/handbook/business-technology/data-team/platform/tableau/#tableau-online-access)).
|
||||
|
||||
### Querying metrics
|
||||
### Tableau
|
||||
|
||||
The following example query returns all values reported for `count_distinct_user_id_from_feature_used_7d` within the last six months and the according `instance_id`:
|
||||
Tableau is a data visualization platform and allows building dashboards and GUI based discovery of events and metrics.
|
||||
This method of discovery is most suited for users who are familiar with business intelligence tooling, basic verifications
|
||||
and for creating persisted, shareable dashboards and visualizations.
|
||||
Access to Tableau requires an [access request](https://handbook.gitlab.com/handbook/business-technology/data-team/platform/tableau/#tableau-online-access).
|
||||
|
||||
```sql
|
||||
SELECT
|
||||
date_trunc('week', ping_created_at),
|
||||
dim_instance_id,
|
||||
metric_value
|
||||
FROM common.fct_ping_instance_metric_rolling_6_months --model limited to last 6 months for performance
|
||||
WHERE metrics_path = 'counts.users_visiting_dashboard_weekly' --set to metric of interest
|
||||
ORDER BY ping_created_at DESC
|
||||
```
|
||||
#### Checking events
|
||||
|
||||
For a list of other metrics tables refer to the [Data Models Cheat Sheet](https://handbook.gitlab.com/handbook/product/product-analysis/data-model-cheat-sheet/#commonly-used-data-models).
|
||||
Visit the [Snowplow event exploration dashboard](https://10az.online.tableau.com/#/site/gitlab/views/SnowplowEventExplorationLast30Days/SnowplowEventExplorationLast30D?:iid=1).
|
||||
This dashboard shows you event counts as well as the most fired events.
|
||||
You can scroll down to the "Structured Events Firing in Production Last 30 Days" chart and filter for your specific event action. The filter only works with exact names.
|
||||
|
||||
### Querying events
|
||||
#### Checking metrics
|
||||
|
||||
You can visit the [Metrics exploration dashboard](https://10az.online.tableau.com/#/site/gitlab/views/PDServicePingExplorationDashboard/MetricsExploration).
|
||||
On the side there is a filter for metric path which is the `key_path` of your metric and a filter for the installation ID including guidance on how to filter for GitLab.com.
|
||||
|
||||
### Snowflake
|
||||
|
||||
Snowflake allows direct querying of relevant tables in the warehouse within their UI with the [Snowflake SQL dialect](https://docs.snowflake.com/en/sql-reference-commands).
|
||||
This method of discovery is most suited to users who are familiar with SQL and for quick and flexible checks whether data is correctly propagated.
|
||||
Access to Snowflake requires an [access request](https://handbook.gitlab.com/handbook/business-technology/data-team/platform/#warehouse-access).
|
||||
|
||||
#### Querying events
|
||||
|
||||
The following example query returns the number of daily event occurrences for the `feature_used` event.
|
||||
|
||||
|
|
@ -100,7 +120,23 @@ AND app_id='gitlab' -- use gitlab for production events and gitlab-staging for e
|
|||
GROUP BY 1 ORDER BY 1 desc
|
||||
```
|
||||
|
||||
For a list of other event tables refer to the [Data Models Cheat Sheet](https://handbook.gitlab.com/handbook/product/product-analysis/data-model-cheat-sheet/#commonly-used-data-models-2).
|
||||
For a list of other metrics tables refer to the [Data Models Cheat Sheet](https://handbook.gitlab.com/handbook/product/product-analysis/data-model-cheat-sheet/#commonly-used-data-models).
|
||||
|
||||
#### Querying metrics
|
||||
|
||||
The following example query returns all values reported for `count_distinct_user_id_from_feature_used_7d` within the last six months and the according `instance_id`:
|
||||
|
||||
```sql
|
||||
SELECT
|
||||
date_trunc('week', ping_created_at),
|
||||
dim_instance_id,
|
||||
metric_value
|
||||
FROM common.fct_ping_instance_metric_rolling_6_months --model limited to last 6 months for performance
|
||||
WHERE metrics_path = 'counts.users_visiting_dashboard_weekly' --set to metric of interest
|
||||
ORDER BY ping_created_at DESC
|
||||
```
|
||||
|
||||
For a list of other metrics tables refer to the [Data Models Cheat Sheet](https://about.gitlab.com/handbook/product/product-analysis/data-model-cheat-sheet/#commonly-used-data-models).
|
||||
|
||||
## Data flow
|
||||
|
||||
|
|
@ -131,8 +167,8 @@ flowchart LR;
|
|||
end
|
||||
end
|
||||
snowplow[\Snowplow Pipeline\]
|
||||
snowflake[(Data Warehouse)]
|
||||
vis[Dashboards in Sisense/Tableau]
|
||||
snowflake[(Snowflake Data Warehouse)]
|
||||
vis[Dashboards in Tableau]
|
||||
```
|
||||
|
||||
## Data Privacy
|
||||
|
|
|
|||
|
|
@ -162,7 +162,3 @@ To use a metric definition to manage [performance indicator](https://handbook.gi
|
|||
[Metrics Dictionary is a separate application](https://gitlab.com/gitlab-org/analytics-section/analytics-instrumentation/metric-dictionary).
|
||||
|
||||
All metrics available in Service Ping are in the [Metrics Dictionary](https://metrics.gitlab.com/).
|
||||
|
||||
### Copy query to clipboard
|
||||
|
||||
To check if a metric has data in Sisense, use the copy query to clipboard feature. This copies a query that's ready to use in Sisense. The query gets the last five service ping data for GitLab.com for a given metric. For information about how to check if a Service Ping metric has data in Sisense, see this [demo](https://www.youtube.com/watch?v=n4o65ivta48).
|
||||
|
|
|
|||
|
|
@ -33,12 +33,12 @@ Currently, the [Metrics Dictionary](https://metrics.gitlab.com/) is built automa
|
|||
## Remove a metric
|
||||
|
||||
WARNING:
|
||||
If a metric is not used in Sisense or any other system after 6 months, the
|
||||
If a metric is not used in Tableau or any other system after 6 months, the
|
||||
Analytics Instrumentation team marks it as inactive and assigns it to the group owner for review.
|
||||
|
||||
We are working on automating this process. See [this epic](https://gitlab.com/groups/gitlab-org/-/epics/8988) for details.
|
||||
|
||||
Analytics Instrumentation removes metrics from Service Ping if they are not used in any Sisense dashboard.
|
||||
Analytics Instrumentation removes metrics from Service Ping if they are not used in any Tableau dashboard.
|
||||
|
||||
For an example of the metric removal process, see this [example issue](https://gitlab.com/gitlab-org/gitlab/-/issues/388236).
|
||||
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ We use the following terminology to describe the Service Ping components:
|
|||
|
||||
## Service Ping request flow
|
||||
|
||||
The following example shows a basic request/response flow between a GitLab instance, the Versions Application, the License Application, Salesforce, the GitLab S3 Bucket, the GitLab Snowflake Data Warehouse, and Sisense:
|
||||
The following example shows a basic request/response flow between a GitLab instance, the Versions Application, the License Application, Salesforce, the GitLab S3 Bucket, the GitLab Snowflake Data Warehouse, and Tableau:
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
|
|
@ -53,7 +53,7 @@ sequenceDiagram
|
|||
participant Salesforce
|
||||
participant S3 Bucket
|
||||
participant Snowflake DW
|
||||
participant Sisense Dashboards
|
||||
participant Tableau Dashboards
|
||||
GitLab Instance->>Versions Application: Send Service Ping
|
||||
loop Process usage data
|
||||
Versions Application->>Versions Application: Parse usage data
|
||||
|
|
@ -70,7 +70,7 @@ sequenceDiagram
|
|||
Versions Application->>S3 Bucket: Export Versions database
|
||||
S3 Bucket->>Snowflake DW: Import data
|
||||
Snowflake DW->>Snowflake DW: Transform data using dbt
|
||||
Snowflake DW->>Sisense Dashboards: Data available for querying
|
||||
Snowflake DW->>Tableau Dashboards: Data available for querying
|
||||
Versions Application->>GitLab Instance: DevOps Score (Conversational Development Index)
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
stage: Data Stores
|
||||
stage: Systems
|
||||
group: Cloud Connector
|
||||
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
|
||||
---
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ module Gitlab
|
|||
return unless should_run_validations?
|
||||
return if commits.empty?
|
||||
|
||||
paths = project.repository.find_changed_paths(treeish_objects, merge_commit_diff_mode: :all_parents)
|
||||
paths = project.repository.find_changed_paths(commits, merge_commit_diff_mode: :all_parents)
|
||||
paths.each do |path|
|
||||
validate_path(path)
|
||||
end
|
||||
|
|
@ -28,28 +28,6 @@ module Gitlab
|
|||
|
||||
private
|
||||
|
||||
def treeish_objects
|
||||
objects = commits
|
||||
|
||||
return objects unless project.repository.empty?
|
||||
|
||||
# It's a special case for the push to the empty repository
|
||||
#
|
||||
# Git doesn't display a diff of the initial commit of the repository
|
||||
# if we just provide a commit sha.
|
||||
#
|
||||
# To fix that we can use TreeRequest to check the difference
|
||||
# between empty tree sha and the tree sha of the initial commit
|
||||
#
|
||||
# `commits` are sorted in reverse order, the initial commit is the last one.
|
||||
init_commit = objects.last
|
||||
|
||||
diff_tree = Gitlab::Git::DiffTree.from_commit(init_commit)
|
||||
return [diff_tree] + objects if diff_tree
|
||||
|
||||
objects
|
||||
end
|
||||
|
||||
def validate_lfs_file_locks?
|
||||
strong_memoize(:validate_lfs_file_locks) do
|
||||
project.lfs_enabled? && project.any_lfs_file_locks?
|
||||
|
|
|
|||
|
|
@ -24,7 +24,8 @@ RSpec.describe 'getting a work_item list for a group', feature_category: :team_p
|
|||
create(
|
||||
:work_item,
|
||||
namespace: group,
|
||||
author: reporter
|
||||
author: reporter,
|
||||
title: 'search_term'
|
||||
)
|
||||
end
|
||||
|
||||
|
|
@ -56,6 +57,16 @@ RSpec.describe 'getting a work_item list for a group', feature_category: :team_p
|
|||
end
|
||||
end
|
||||
|
||||
context 'when filtering by search' do
|
||||
let(:item_filter_params) { { search: 'search_term' } }
|
||||
|
||||
it 'returns matching work items' do
|
||||
post_graphql(query, current_user: current_user)
|
||||
|
||||
expect(work_item_ids).to contain_exactly(group_work_item.to_global_id.to_s)
|
||||
end
|
||||
end
|
||||
|
||||
context 'when the user can not see confidential work_items' do
|
||||
it_behaves_like 'a working graphql query' do
|
||||
before do
|
||||
|
|
|
|||
Loading…
Reference in New Issue