Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2022-10-31 18:09:25 +00:00
parent a551969356
commit 30b8ea126f
150 changed files with 1675 additions and 798 deletions

View File

@ -18,7 +18,7 @@ build-qa-image:
- ./scripts/build_qa_image
# This image is used by:
# - The `CNG` pipelines (via the `review-build-cng` job): https://gitlab.com/gitlab-org/build/CNG/-/blob/cfc67136d711e1c8c409bf8e57427a644393da2f/.gitlab-ci.yml#L335
# - The `CNG` downstream pipelines (we pass the image tag via the `review-build-cng` job): https://gitlab.com/gitlab-org/gitlab/-/blob/c34e0834b01cd45c1f69a01b5e38dd6bc505f903/.gitlab/ci/review-apps/main.gitlab-ci.yml#L69
# - The `omnibus-gitlab` pipelines (via the `e2e:package-and-test` job): https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/dfd1ad475868fc84e91ab7b5706aa03e46dc3a86/.gitlab-ci.yml#L130
build-assets-image:
extends:
@ -27,7 +27,10 @@ build-assets-image:
stage: build-images
needs: ["compile-production-assets"]
script:
# TODO: Change the image tag to be the MD5 of assets files and skip image building if the image exists
# We'll also need to pass GITLAB_ASSETS_TAG to the trigerred omnibus-gitlab pipeline similarly to how we do it for trigerred CNG pipelines
# https://gitlab.com/gitlab-org/gitlab/issues/208389
- run_timed_command "scripts/build_assets_image"
artifacts:
expire_in: 7 days
paths:
# The `cached-assets-hash.txt` file is used in `review-build-cng-env` (`.gitlab/ci/review-apps/main.gitlab-ci.yml`)
# to pass the assets image tag to the CNG downstream pipeline.
- cached-assets-hash.txt

View File

@ -23,6 +23,7 @@
gitlab_assets_archive_doesnt_exist || run_timed_command "download_and_extract_gitlab_assets"
fi
- assets_compile_script
- echo -n "${GITLAB_ASSETS_HASH}" > "cached-assets-hash.txt"
compile-production-assets:
extends:
@ -38,6 +39,7 @@ compile-production-assets:
# These assets are used in multiple locations:
# - in `build-assets-image` job to create assets image for packaging systems
# - GitLab UI for integration tests: https://gitlab.com/gitlab-org/gitlab-ui/-/blob/e88493b3c855aea30bf60baee692a64606b0eb1e/.storybook/preview-head.pug#L1
- cached-assets-hash.txt
- public/assets/
- "${WEBPACK_COMPILE_LOG_PATH}"
when: always
@ -68,9 +70,6 @@ update-assets-compile-production-cache:
- .assets-compile-cache-push
- .shared:rules:update-cache
stage: prepare
script:
- !reference [compile-production-assets, script]
- echo -n "${GITLAB_ASSETS_HASH}" > "cached-assets-hash.txt"
artifacts: {} # This job's purpose is only to update the cache.
update-assets-compile-test-cache:

View File

@ -4,6 +4,7 @@ default:
interruptible: true
include:
- local: .gitlab/ci/global.gitlab-ci.yml
- local: .gitlab/ci/package-and-test/rules.gitlab-ci.yml
- local: .gitlab/ci/package-and-test/variables.gitlab-ci.yml
- project: gitlab-org/quality/pipeline-common
@ -38,23 +39,6 @@ stages:
extends:
- .gitlab-qa-install
.omnibus-env:
variables:
BUILD_ENV: build.env
script:
- |
SECURITY_SOURCES=$([[ ! "$CI_PROJECT_NAMESPACE" =~ ^gitlab-org\/security ]] || echo "true")
echo "SECURITY_SOURCES=${SECURITY_SOURCES:-false}" > $BUILD_ENV
echo "OMNIBUS_GITLAB_CACHE_UPDATE=${OMNIBUS_GITLAB_CACHE_UPDATE:-false}" >> $BUILD_ENV
for version_file in *_VERSION; do echo "$version_file=$(cat $version_file)" >> $BUILD_ENV; done
echo "OMNIBUS_GITLAB_RUBY3_BUILD=${OMNIBUS_GITLAB_RUBY3_BUILD:-false}" >> $BUILD_ENV
echo "OMNIBUS_GITLAB_CACHE_EDITION=${OMNIBUS_GITLAB_CACHE_EDITION:-GITLAB}" >> $BUILD_ENV
echo "Built environment file for omnibus build:"
cat $BUILD_ENV
artifacts:
reports:
dotenv: $BUILD_ENV
.update-script:
script:
- export QA_COMMAND="bundle exec gitlab-qa Test::Omnibus::UpdateFromPrevious $RELEASE $GITLAB_VERSION $UPDATE_TYPE -- $QA_RSPEC_TAGS $RSPEC_REPORT_OPTS"
@ -108,9 +92,29 @@ dont-interrupt-me:
trigger-omnibus-env:
extends:
- .omnibus-env
- .default-utils-before_script
- .rules:omnibus-build
stage: .pre
needs:
# We need this job because we need its `cached-assets-hash.txt` artifact, so that we can pass the assets image tag to the downstream omnibus-gitlab pipeline.
- pipeline: $PARENT_PIPELINE_ID
job: build-assets-image
variables:
BUILD_ENV: build.env
script:
- |
SECURITY_SOURCES=$([[ ! "$CI_PROJECT_NAMESPACE" =~ ^gitlab-org\/security ]] || echo "true")
echo "SECURITY_SOURCES=${SECURITY_SOURCES:-false}" > $BUILD_ENV
echo "OMNIBUS_GITLAB_CACHE_UPDATE=${OMNIBUS_GITLAB_CACHE_UPDATE:-false}" >> $BUILD_ENV
for version_file in *_VERSION; do echo "$version_file=$(cat $version_file)" >> $BUILD_ENV; done
echo "OMNIBUS_GITLAB_RUBY3_BUILD=${OMNIBUS_GITLAB_RUBY3_BUILD:-false}" >> $BUILD_ENV
echo "OMNIBUS_GITLAB_CACHE_EDITION=${OMNIBUS_GITLAB_CACHE_EDITION:-GITLAB}" >> $BUILD_ENV
echo "GITLAB_ASSETS_TAG=$(assets_image_tag)" >> $BUILD_ENV
echo "Built environment file for omnibus build:"
cat $BUILD_ENV
artifacts:
reports:
dotenv: $BUILD_ENV
trigger-omnibus:
extends: .rules:omnibus-build
@ -128,6 +132,7 @@ trigger-omnibus:
GITLAB_SHELL_VERSION: $GITLAB_SHELL_VERSION
GITLAB_WORKHORSE_VERSION: $GITLAB_WORKHORSE_VERSION
GITLAB_VERSION: $CI_COMMIT_SHA
GITLAB_ASSETS_TAG: $GITLAB_ASSETS_TAG
IMAGE_TAG: $CI_COMMIT_SHA
TOP_UPSTREAM_SOURCE_PROJECT: $CI_PROJECT_PATH
SECURITY_SOURCES: $SECURITY_SOURCES

View File

@ -75,6 +75,8 @@ e2e:package-and-test:
- build-qa-image
- e2e-test-pipeline-generate
variables:
# This is needed by `trigger-omnibus-env` (`.gitlab/ci/package-and-test/main.gitlab-ci.yml`).
PARENT_PIPELINE_ID: $CI_PIPELINE_ID
SKIP_MESSAGE: Skipping package-and-test due to mr containing only quarantine changes!
RELEASE: "${REGISTRY_HOST}/${REGISTRY_GROUP}/build/omnibus-gitlab-mirror/gitlab-ee:${CI_COMMIT_SHA}"
GITLAB_QA_IMAGE: "${CI_REGISTRY_IMAGE}/gitlab-ee-qa:${CI_COMMIT_SHA}"

View File

@ -34,7 +34,10 @@ review-build-cng-env:
- .review:rules:review-build-cng
image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}ruby:3.0-alpine3.13
stage: prepare
needs: []
needs:
# We need this job because we need its `cached-assets-hash.txt` artifact, so that we can pass the assets image tag to the downstream CNG pipeline.
- pipeline: $PARENT_PIPELINE_ID
job: build-assets-image
before_script:
- source ./scripts/utils.sh
- install_gitlab_gem

View File

@ -33,6 +33,8 @@ start-review-app-pipeline:
# They need to be explicitly passed on to the child pipeline.
# https://docs.gitlab.com/ee/ci/pipelines/multi_project_pipelines.html#pass-cicd-variables-to-a-downstream-pipeline-by-using-the-variables-keyword
variables:
# This is needed by `review-build-cng-env` (`.gitlab/ci/review-apps/main.gitlab-ci.yml`).
PARENT_PIPELINE_ID: $CI_PIPELINE_ID
SCHEDULE_TYPE: $SCHEDULE_TYPE
DAST_RUN: $DAST_RUN
SKIP_MESSAGE: Skipping review-app due to mr containing only quarantine changes!

View File

@ -1,4 +1,4 @@
# Simple container to store assets for later use
FROM scratch
ADD public/assets /assets/
COPY public/assets /assets/
CMD /bin/true

View File

@ -1,15 +0,0 @@
import { defaultDataIdFromObject } from '@apollo/client/core';
import createDefaultClient from '~/lib/graphql';
export const gqlClient = createDefaultClient(
{},
{
cacheConfig: {
dataIdFromObject: (object) => {
// eslint-disable-next-line no-underscore-dangle
return object.__typename === 'BoardList' ? object.iid : defaultDataIdFromObject(object);
},
},
batchMax: 2,
},
);

View File

@ -12,14 +12,14 @@ import {
convertObjectPropsToCamelCase,
} from '~/lib/utils/common_utils';
import { queryToObject } from '~/lib/utils/url_utility';
import { defaultClient } from '~/graphql_shared/issuable_client';
import { fullBoardId } from './boards_util';
import { gqlClient } from './graphql';
Vue.use(VueApollo);
Vue.use(PortalVue);
const apolloProvider = new VueApollo({
defaultClient: gqlClient,
defaultClient,
});
function mountBoardApp(el) {

View File

@ -34,11 +34,11 @@ import issueMoveListMutation from 'ee_else_ce/boards/graphql/issue_move_list.mut
import totalCountAndWeightQuery from 'ee_else_ce/boards/graphql/board_lists_deferred.query.graphql';
import { fetchPolicies } from '~/lib/graphql';
import { getIdFromGraphQLId } from '~/graphql_shared/utils';
import { defaultClient as gqlClient } from '~/graphql_shared/issuable_client';
import { convertObjectPropsToCamelCase } from '~/lib/utils/common_utils';
import { queryToObject } from '~/lib/utils/url_utility';
import { s__ } from '~/locale';
import eventHub from '../eventhub';
import { gqlClient } from '../graphql';
import projectBoardQuery from '../graphql/project_board.query.graphql';
import groupBoardQuery from '../graphql/group_board.query.graphql';
import boardLabelsQuery from '../graphql/board_labels.query.graphql';
@ -149,6 +149,9 @@ export default {
query: listsQuery[issuableType].query,
variables,
...(resetLists ? { fetchPolicy: fetchPolicies.NO_CACHE } : {}),
context: {
isSingleRequest: true,
},
})
.then(({ data }) => {
const { lists, hideBacklogList } = data[boardType].board;

View File

@ -1,14 +1,21 @@
import produce from 'immer';
import VueApollo from 'vue-apollo';
import { defaultDataIdFromObject } from '@apollo/client/core';
import { concatPagination } from '@apollo/client/utilities';
import getIssueStateQuery from '~/issues/show/queries/get_issue_state.query.graphql';
import createDefaultClient from '~/lib/graphql';
import typeDefs from '~/work_items/graphql/typedefs.graphql';
import { WIDGET_TYPE_MILESTONE } from '~/work_items/constants';
export const temporaryConfig = {
export const config = {
typeDefs,
cacheConfig: {
// included temporarily until Vuex is removed from boards app
dataIdFromObject: (object) => {
// eslint-disable-next-line no-underscore-dangle
return object.__typename === 'BoardList' ? object.iid : defaultDataIdFromObject(object);
},
possibleTypes: {
LocalWorkItemWidget: ['LocalWorkItemMilestone'],
},
@ -78,7 +85,7 @@ export const resolvers = {
},
};
export const defaultClient = createDefaultClient(resolvers, temporaryConfig);
export const defaultClient = createDefaultClient(resolvers, config);
export const apolloProvider = new VueApollo({
defaultClient,

View File

@ -0,0 +1,36 @@
<script>
import { GlTable } from '@gitlab/ui';
import IncubationAlert from './incubation_alert.vue';
export default {
name: 'ShowMlExperiment',
components: {
GlTable,
IncubationAlert,
},
inject: ['candidates', 'metricNames', 'paramNames'],
computed: {
fields() {
return [...this.paramNames, ...this.metricNames];
},
},
};
</script>
<template>
<div>
<incubation-alert />
<h3>
{{ __('Experiment Candidates') }}
</h3>
<gl-table
:fields="fields"
:items="candidates"
:empty-text="__('This Experiment has no logged Candidates')"
show-empty
class="gl-mt-0!"
/>
</div>
</template>

View File

@ -0,0 +1,48 @@
<script>
import { GlAlert, GlLink } from '@gitlab/ui';
import { __ } from '~/locale';
export default {
i18n: {
titleLabel: __('Machine Learning Experiment Tracking is in Incubating Phase'),
contentLabel: __(
'GitLab incubates features to explore new use cases. These features are updated regularly, and support is limited',
),
learnMoreLabel: __('Learn More'),
feedbackLabel: __('Feedback and Updates'),
},
name: 'MlopsIncubationAlert',
components: { GlAlert, GlLink },
data() {
return {
isAlertDismissed: false,
};
},
computed: {
shouldShowAlert() {
return !this.isAlertDismissed;
},
},
methods: {
dismissAlert() {
this.isAlertDismissed = true;
},
},
};
</script>
<template>
<gl-alert
v-if="shouldShowAlert"
:title="$options.i18n.titleLabel"
variant="warning"
:primary-button-text="$options.i18n.feedbackLabel"
primary-button-link="https://gitlab.com/groups/gitlab-org/-/epics/8560"
@dismiss="dismissAlert"
>
{{ $options.i18n.contentLabel }}
<gl-link href="https://about.gitlab.com/handbook/engineering/incubation/" target="_blank">{{
$options.i18n.learnMoreLabel
}}</gl-link>
</gl-alert>
</template>

View File

@ -0,0 +1,31 @@
import Vue from 'vue';
import ShowExperiment from '~/ml/experiment_tracking/components/experiment.vue';
const initShowExperiment = () => {
const element = document.querySelector('#js-show-ml-experiment');
if (!element) {
return;
}
const container = document.createElement('div');
element.appendChild(container);
const candidates = JSON.parse(element.dataset.candidates);
const metricNames = JSON.parse(element.dataset.metrics);
const paramNames = JSON.parse(element.dataset.params);
// eslint-disable-next-line no-new
new Vue({
el: container,
provide: {
candidates,
metricNames,
paramNames,
},
render(h) {
return h(ShowExperiment);
},
});
};
initShowExperiment();

View File

@ -137,25 +137,19 @@ export default {
:is-active="isDropdownOpen"
:size="24"
:status="stage.status"
class="gl-align-items-center gl-border gl-display-inline-flex gl-z-index-1"
class="gl-display-inline-flex gl-align-items-center gl-border gl-z-index-1"
/>
</template>
<div
v-if="isLoading"
class="gl-display-flex gl-justify-content-center gl-p-2"
data-testid="pipeline-stage-loading-state"
>
<div v-if="isLoading" class="gl--flex-center gl-p-2" data-testid="pipeline-stage-loading-state">
<gl-loading-icon size="sm" class="gl-mr-3" />
<p class="gl-mb-0">{{ $options.i18n.loadingText }}</p>
<p class="gl-line-height-normal gl-mb-0">{{ $options.i18n.loadingText }}</p>
</div>
<ul
v-else
class="js-builds-dropdown-list scrollable-menu"
data-testid="mini-pipeline-graph-dropdown-menu-list"
>
<div
class="gl-align-items-center gl-border-b gl-display-flex gl-font-weight-bold gl-justify-content-center gl-pb-3"
>
<div class="gl--flex-center gl-border-b gl-font-weight-bold gl-pb-3">
<span class="gl-mr-1">{{ $options.i18n.stage }}</span>
<span data-testid="pipeline-stage-dropdown-menu-title">{{ stageName }}</span>
</div>

View File

@ -8,6 +8,7 @@
@import './pages/issues';
@import './pages/labels';
@import './pages/login';
@import './pages/ml_experiment_tracking';
@import './pages/merge_requests';
@import './pages/monitor';
@import './pages/note_form';

View File

@ -0,0 +1,16 @@
@import '../page_bundles/mixins_and_variables_and_functions';
.ml-experiment-row {
.title {
margin-bottom: $gl-spacing-scale-1;
font-weight: $gl-font-weight-bold;
}
.ml-experiment-info {
color: $gl-text-color-secondary;
}
a {
color: $gl-text-color;
}
}

View File

@ -52,13 +52,6 @@ input[type='checkbox']:hover {
.global-search-container {
flex-grow: 1;
}
@include media-breakpoint-down(lg) {
.title-container {
flex: 0;
overflow: hidden;
}
}
}
}

View File

@ -0,0 +1,32 @@
# frozen_string_literal: true
module Projects
module Ml
class ExperimentsController < ::Projects::ApplicationController
include Projects::Ml::ExperimentsHelper
before_action :check_feature_flag
feature_category :mlops
MAX_PER_PAGE = 20
def index
@experiments = ::Ml::Experiment.by_project_id(@project.id).page(params[:page]).per(MAX_PER_PAGE)
end
def show
@experiment = ::Ml::Experiment.by_project_id_and_iid(@project.id, params[:id])
return redirect_to project_ml_experiments_path(@project) unless @experiment.present?
@candidates = @experiment.candidates&.including_metrics_and_params
end
private
def check_feature_flag
render_404 unless Feature.enabled?(:ml_experiment_tracking)
end
end
end
end

View File

@ -6,12 +6,6 @@ module MarkupHelper
include ActionView::Helpers::TextHelper
include ActionView::Context
# Let's increase the render timeout
# For a smaller one, a test that renders the blob content statically fails
# We can consider removing this custom timeout when markup_rendering_timeout FF is removed:
# https://gitlab.com/gitlab-org/gitlab/-/issues/365358
RENDER_TIMEOUT = 5.seconds
# Use this in places where you would normally use link_to(gfm(...), ...).
def link_to_markdown(body, url, html_options = {})
return '' if body.blank?
@ -97,8 +91,9 @@ module MarkupHelper
context[:project] ||= @project
context[:group] ||= @group
html = markdown_unsafe(text, context)
prepare_for_rendering(html, context)
html = Markup::RenderingService.new(text, context: context, postprocess_context: postprocess_context).execute
Hamlit::RailsHelpers.preserve(html)
end
def markdown_field(object, field, context = {})
@ -114,8 +109,13 @@ module MarkupHelper
def markup(file_name, text, context = {})
context[:project] ||= @project
context[:text_source] ||= :blob
html = context.delete(:rendered) || markup_unsafe(file_name, text, context)
prepare_for_rendering(html, context)
prepare_asciidoc_context(file_name, context)
html = Markup::RenderingService
.new(text, file_name: file_name, context: context, postprocess_context: postprocess_context)
.execute
Hamlit::RailsHelpers.preserve(html)
end
def render_wiki_content(wiki_page, context = {})
@ -123,35 +123,13 @@ module MarkupHelper
return '' unless text.present?
context = render_wiki_content_context(wiki_page.wiki, wiki_page, context)
html = markup_unsafe(wiki_page.path, text, context)
prepare_asciidoc_context(wiki_page.path, context)
prepare_for_rendering(html, context)
end
html = Markup::RenderingService
.new(text, file_name: wiki_page.path, context: context, postprocess_context: postprocess_context)
.execute
def markup_unsafe(file_name, text, context = {})
return '' unless text.present?
markup = proc do
if Gitlab::MarkupHelper.gitlab_markdown?(file_name)
markdown_unsafe(text, context)
elsif Gitlab::MarkupHelper.asciidoc?(file_name)
asciidoc_unsafe(text, context)
elsif Gitlab::MarkupHelper.plain?(file_name)
plain_unsafe(text)
else
other_markup_unsafe(file_name, text, context)
end
end
if Feature.enabled?(:markup_rendering_timeout, @project)
Gitlab::RenderTimeout.timeout(foreground: RENDER_TIMEOUT, &markup)
else
markup.call
end
rescue StandardError => e
Gitlab::ErrorTracking.track_exception(e, project_id: @project&.id, file_name: file_name)
simple_format(text)
Hamlit::RailsHelpers.preserve(html)
end
# Returns the text necessary to reference `entity` across projects
@ -214,29 +192,6 @@ module MarkupHelper
end
end
def markdown_unsafe(text, context = {})
Banzai.render(text, context)
end
def asciidoc_unsafe(text, context = {})
context.reverse_merge!(
commit: @commit,
ref: @ref,
requested_path: @path
)
Gitlab::Asciidoc.render(text, context)
end
def plain_unsafe(text)
content_tag :pre, class: 'plain-readme' do
text
end
end
def other_markup_unsafe(file_name, text, context = {})
Gitlab::OtherMarkup.render(file_name, text, context)
end
def render_markdown_field(object, field, context = {})
post_process = context.delete(:post_process)
post_process = true if post_process.nil?
@ -257,7 +212,15 @@ module MarkupHelper
def prepare_for_rendering(html, context = {})
return '' unless html.present?
context.reverse_merge!(
context.reverse_merge!(postprocess_context)
html = Banzai.post_process(html, context)
Hamlit::RailsHelpers.preserve(html)
end
def postprocess_context
{
current_user: (current_user if defined?(current_user)),
# RepositoryLinkFilter and UploadLinkFilter
@ -265,11 +228,13 @@ module MarkupHelper
wiki: @wiki,
ref: @ref,
requested_path: @path
)
}
end
html = Banzai.post_process(html, context)
def prepare_asciidoc_context(file_name, context)
return unless Gitlab::MarkupHelper.asciidoc?(file_name)
Hamlit::RailsHelpers.preserve(html)
context.reverse_merge!(commit: @commit, ref: @ref, requested_path: @path)
end
extend self

View File

@ -0,0 +1,24 @@
# frozen_string_literal: true
module Projects
module Ml
module ExperimentsHelper
require 'json'
include ActionView::Helpers::NumberHelper
def candidates_table_items(candidates)
items = candidates.map do |candidate|
{
**candidate.params.to_h { |p| [p.name, p.value] },
**candidate.latest_metrics.to_h { |m| [m.name, number_with_precision(m.value, precision: 4)] }
}
end
Gitlab::Json.generate(items)
end
def unique_logged_names(candidates, &selector)
Gitlab::Json.generate(candidates.flat_map(&selector).map(&:name).uniq)
end
end
end
end

View File

@ -11,9 +11,12 @@ module Ml
belongs_to :user
has_many :metrics, class_name: 'Ml::CandidateMetric'
has_many :params, class_name: 'Ml::CandidateParam'
has_many :latest_metrics, -> { latest }, class_name: 'Ml::CandidateMetric', inverse_of: :candidate
default_value_for(:iid) { SecureRandom.uuid }
scope :including_metrics_and_params, -> { includes(:latest_metrics, :params) }
def artifact_root
"/ml_candidate_#{iid}/-/"
end

View File

@ -6,5 +6,7 @@ module Ml
validates :name, length: { maximum: 250 }, presence: true
belongs_to :candidate, class_name: 'Ml::Candidate'
scope :latest, -> { select('DISTINCT ON (candidate_id, name) *').order('candidate_id, name, id DESC') }
end
end

View File

@ -23,7 +23,7 @@ module Ml
end
def by_project_id(project_id)
where(project_id: project_id)
where(project_id: project_id).order(id: :desc)
end
end
end

View File

@ -0,0 +1,79 @@
# frozen_string_literal: true
module Markup
class RenderingService
include ActionView::Helpers::TextHelper
# Let's increase the render timeout
# For a smaller one, a test that renders the blob content statically fails
# We can consider removing this custom timeout when markup_rendering_timeout FF is removed:
# https://gitlab.com/gitlab-org/gitlab/-/issues/365358
RENDER_TIMEOUT = 5.seconds
def initialize(text, file_name: nil, context: {}, postprocess_context: {})
@text = text
@file_name = file_name
@context = context
@postprocess_context = postprocess_context
end
def execute
return '' unless text.present?
return context.delete(:rendered) if context.has_key?(:rendered)
html = file_name ? markup_unsafe : markdown_unsafe
return '' unless html.present?
postprocess_context ? postprocess(html) : html
end
private
def markup_unsafe
markup = proc do
if Gitlab::MarkupHelper.gitlab_markdown?(file_name)
markdown_unsafe
elsif Gitlab::MarkupHelper.asciidoc?(file_name)
asciidoc_unsafe
elsif Gitlab::MarkupHelper.plain?(file_name)
plain_unsafe
else
other_markup_unsafe
end
end
if Feature.enabled?(:markup_rendering_timeout, context[:project])
Gitlab::RenderTimeout.timeout(foreground: RENDER_TIMEOUT, &markup)
else
markup.call
end
rescue StandardError => e
Gitlab::ErrorTracking.track_exception(e, project_id: context[:project]&.id, file_name: file_name)
simple_format(text)
end
def markdown_unsafe
Banzai.render(text, context)
end
def asciidoc_unsafe
Gitlab::Asciidoc.render(text, context)
end
def plain_unsafe
"<pre class=\"plain-readme\">#{text}</pre>"
end
def other_markup_unsafe
Gitlab::OtherMarkup.render(file_name, text, context)
end
def postprocess(html)
Banzai.post_process(html, context.reverse_merge(postprocess_context))
end
attr_reader :text, :file_name, :context, :postprocess_context
end
end

View File

@ -25,7 +25,8 @@ module Packages
epoch: package_tags[:epoch] || '0',
changelogs: build_changelogs,
requirements: build_requirements,
provides: build_provides
provides: build_provides,
directories: package_tags[:dirnames]
}.merge(extract_static_attributes)
end

View File

@ -0,0 +1,39 @@
# frozen_string_literal: true
module Packages
module Rpm
module RepositoryMetadata
class BuildFilelistXmlService < BuildXmlBaseService
ROOT_TAG = 'filelists'
ROOT_ATTRIBUTES = {
xmlns: 'http://linux.duke.edu/metadata/filelists',
packages: '0'
}.freeze
def execute
super do |xml|
xml.package(pkgid: data[:pkgid], name: data[:name], arch: data[:arch]) do
xml.version epoch: data[:epoch], ver: data[:version], rel: data[:release]
build_file_nodes(xml)
end
end
end
private
def build_file_nodes(xml)
data[:files].each do |path|
attributes = dir?(path) ? { type: 'dir' } : {}
xml.file path, **attributes
end
end
def dir?(path)
# Add trailing slash to path to check
# if it exists in directories list
data[:directories].include? File.join(path, '')
end
end
end
end
end

View File

@ -2,32 +2,24 @@
module Packages
module Rpm
module RepositoryMetadata
class BuildOtherXmlService
class BuildOtherXmlService < BuildXmlBaseService
ROOT_TAG = 'otherdata'
ROOT_ATTRIBUTES = {
xmlns: 'http://linux.duke.edu/metadata/other',
packages: '0'
}.freeze
def initialize(data)
@data = data
end
def execute
builder = Nokogiri::XML::Builder.new do |xml|
super do |xml|
xml.package(pkgid: data[:pkgid], name: data[:name], arch: data[:arch]) do
xml.version epoch: data[:epoch], ver: data[:version], rel: data[:release]
build_changelog_nodes(xml)
end
end
Nokogiri::XML(builder.to_xml).at('package')
end
private
attr_reader :data
def build_changelog_nodes(xml)
data[:changelogs].each do |changelog|
xml.changelog changelog[:changelogtext], date: changelog[:changelogtime]

View File

@ -2,7 +2,7 @@
module Packages
module Rpm
module RepositoryMetadata
class BuildPrimaryXmlService
class BuildPrimaryXmlService < BuildXmlBaseService
ROOT_TAG = 'metadata'
ROOT_ATTRIBUTES = {
xmlns: 'http://linux.duke.edu/metadata/common',
@ -14,12 +14,8 @@ module Packages
BASE_ATTRIBUTES = %i[name arch summary description url packager].freeze
FORMAT_NODE_BASE_ATTRIBUTES = %i[license vendor group buildhost sourcerpm].freeze
def initialize(data)
@data = data
end
def execute
builder = Nokogiri::XML::Builder.new do |xml|
super do |xml|
xml.package(type: :rpm, 'xmlns:rpm': 'http://linux.duke.edu/metadata/rpm') do
build_base_attributes(xml)
xml.version epoch: data[:epoch], ver: data[:version], rel: data[:release]
@ -30,14 +26,10 @@ module Packages
build_format_node(xml)
end
end
Nokogiri::XML(builder.to_xml).at('package')
end
private
attr_reader :data
def build_base_attributes(xml)
BASE_ATTRIBUTES.each do |attribute|
xml.method_missing(attribute, data[attribute]) if data[attribute].present?

View File

@ -3,8 +3,6 @@ module Packages
module Rpm
module RepositoryMetadata
class BuildRepomdXmlService
attr_reader :data
ROOT_ATTRIBUTES = {
xmlns: 'http://linux.duke.edu/metadata/repo',
'xmlns:rpm': 'http://linux.duke.edu/metadata/rpm'
@ -26,12 +24,6 @@ module Packages
end
def execute
build_repomd
end
private
def build_repomd
Nokogiri::XML::Builder.new(encoding: 'UTF-8') do |xml|
xml.repomd(ROOT_ATTRIBUTES) do
xml.revision Time.now.to_i
@ -40,6 +32,10 @@ module Packages
end.to_xml
end
private
attr_reader :data
def build_data_info(xml)
data.each do |filename, info|
xml.data(type: filename) do

View File

@ -0,0 +1,22 @@
# frozen_string_literal: true
module Packages
module Rpm
module RepositoryMetadata
class BuildXmlBaseService
def initialize(data)
@data = data
end
def execute
builder = Nokogiri::XML::Builder.new { |xml| yield xml } # rubocop:disable Style/ExplicitBlockArgument
Nokogiri::XML(builder.to_xml).at('package')
end
private
attr_reader :data
end
end
end
end

View File

@ -5,7 +5,8 @@ module Packages
class UpdateXmlService
BUILDERS = {
other: ::Packages::Rpm::RepositoryMetadata::BuildOtherXmlService,
primary: ::Packages::Rpm::RepositoryMetadata::BuildPrimaryXmlService
primary: ::Packages::Rpm::RepositoryMetadata::BuildPrimaryXmlService,
filelist: ::Packages::Rpm::RepositoryMetadata::BuildFilelistXmlService
}.freeze
def initialize(filename:, xml: nil, data: {})

View File

@ -0,0 +1,3 @@
%li.ml-experiment-row.py-3
= link_to project_ml_experiment_path(@project, experiment.iid), class: "title" do
= experiment.name

View File

@ -0,0 +1,7 @@
- if experiments.blank?
.nothing-here-block= s_('MlExperimentsEmptyState|No Experiments to Show')
- else
.ml-experiments-list-holder
%ul.content-list
= render partial: 'experiment', collection: experiments, as: :experiment
= paginate_collection @experiments

View File

@ -0,0 +1,8 @@
= render Pajamas::AlertComponent.new(variant: :warning,
title: _('Machine Learning Experiment Tracking is in Incubating Phase'),
alert_options: { class: 'gl-my-3' }) do |c|
= c.body do
= _('GitLab incubates features to explore new use cases. These features are updated regularly, and support is limited')
= link_to _('Learn more.'), 'https://about.gitlab.com/handbook/engineering/incubation/', target: "_blank"
= c.actions do
= link_to _('Feedback and Updates'), 'https://gitlab.com/groups/gitlab-org/-/epics/8560', target: "_blank"

View File

@ -0,0 +1,11 @@
- breadcrumb_title _('ML Experiments')
- page_title _('ML Experiments')
.page-title-holder.d-flex.align-items-center
%h1.page-title.gl-font-size-h-display= _('Machine Learning Experiments')
= render "incubation_banner"
%div{ class: container_class }
.content-list.builds-content-list
= render "experiment_list", experiments: @experiments, project: @project

View File

@ -0,0 +1,14 @@
- add_to_breadcrumbs _("Experiments"), project_ml_experiments_path(@project)
- breadcrumb_title @experiment.name
- page_title @experiment.name
- items = candidates_table_items(@candidates)
- metrics = unique_logged_names(@candidates, &:latest_metrics)
- params = unique_logged_names(@candidates, &:params)
.page-title-holder.d-flex.align-items-center
%h1.page-title.gl-font-size-h-display= @experiment.name
#js-show-ml-experiment{ data: {
candidates: items,
metrics: metrics,
params: params } }

View File

@ -22,9 +22,13 @@ metadata:
description: Operations related to merge requests
- name: deploy_keys
description: Operations related to deploy keys
- name: deploy_tokens
description: Operations related to deploy tokens
- name: deployments
description: Operations related to deployments
- name: features
description: Operations related to managing Flipper-based feature flags
- name: freeze_periods
description: Operations related to deploy freeze periods
- name: release_links
description: Operations related to release assets (links)

View File

@ -471,6 +471,10 @@ constraints(::Constraints::ProjectUrlConstrainer.new) do
end
end
end
namespace :ml do
resources :experiments, only: [:index, :show], controller: 'experiments'
end
end
# End of the /-/ scope.

View File

@ -11434,7 +11434,6 @@ CREATE TABLE application_settings (
inactive_projects_min_size_mb integer DEFAULT 0 NOT NULL,
inactive_projects_send_warning_email_after_months integer DEFAULT 1 NOT NULL,
delayed_group_deletion boolean DEFAULT true NOT NULL,
maven_package_requests_forwarding boolean DEFAULT true NOT NULL,
arkose_labs_namespace text DEFAULT 'client'::text NOT NULL,
max_export_size integer DEFAULT 0,
encrypted_slack_app_signing_secret bytea,
@ -11473,17 +11472,18 @@ CREATE TABLE application_settings (
cube_api_base_url text,
encrypted_cube_api_key bytea,
encrypted_cube_api_key_iv bytea,
maven_package_requests_forwarding boolean DEFAULT true NOT NULL,
dashboard_limit_enabled boolean DEFAULT false NOT NULL,
dashboard_limit integer DEFAULT 0 NOT NULL,
dashboard_notification_limit integer DEFAULT 0 NOT NULL,
dashboard_enforcement_limit integer DEFAULT 0 NOT NULL,
dashboard_limit_new_namespace_creation_enforcement_date date,
jitsu_host text,
jitsu_project_xid text,
clickhouse_connection_string text,
jitsu_administrator_email text,
encrypted_jitsu_administrator_password bytea,
encrypted_jitsu_administrator_password_iv bytea,
dashboard_limit_enabled boolean DEFAULT false NOT NULL,
dashboard_limit integer DEFAULT 0 NOT NULL,
dashboard_notification_limit integer DEFAULT 0 NOT NULL,
dashboard_enforcement_limit integer DEFAULT 0 NOT NULL,
dashboard_limit_new_namespace_creation_enforcement_date date,
can_create_group boolean DEFAULT true NOT NULL,
lock_maven_package_requests_forwarding boolean DEFAULT false NOT NULL,
lock_pypi_package_requests_forwarding boolean DEFAULT false NOT NULL,
@ -20192,8 +20192,8 @@ CREATE TABLE project_settings (
selective_code_owner_removals boolean DEFAULT false NOT NULL,
issue_branch_template text,
show_diff_preview_in_email boolean DEFAULT true NOT NULL,
jitsu_key text,
suggested_reviewers_enabled boolean DEFAULT false NOT NULL,
jitsu_key text,
only_allow_merge_if_all_status_checks_passed boolean DEFAULT false NOT NULL,
CONSTRAINT check_2981f15877 CHECK ((char_length(jitsu_key) <= 100)),
CONSTRAINT check_3a03e7557a CHECK ((char_length(previous_default_branch) <= 4096)),
@ -28242,10 +28242,6 @@ CREATE UNIQUE INDEX p_ci_builds_metadata_build_id_partition_id_idx ON ONLY p_ci_
CREATE UNIQUE INDEX index_ci_builds_metadata_on_build_id_partition_id_unique ON ci_builds_metadata USING btree (build_id, partition_id);
CREATE UNIQUE INDEX p_ci_builds_metadata_id_partition_id_idx ON ONLY p_ci_builds_metadata USING btree (id, partition_id);
CREATE UNIQUE INDEX index_ci_builds_metadata_on_id_partition_id_unique ON ci_builds_metadata USING btree (id, partition_id);
CREATE INDEX p_ci_builds_metadata_project_id_idx ON ONLY p_ci_builds_metadata USING btree (project_id);
CREATE INDEX index_ci_builds_metadata_on_project_id ON ci_builds_metadata USING btree (project_id);
@ -32484,8 +32480,6 @@ ALTER INDEX p_ci_builds_metadata_build_id_id_idx ATTACH PARTITION index_ci_build
ALTER INDEX p_ci_builds_metadata_build_id_partition_id_idx ATTACH PARTITION index_ci_builds_metadata_on_build_id_partition_id_unique;
ALTER INDEX p_ci_builds_metadata_id_partition_id_idx ATTACH PARTITION index_ci_builds_metadata_on_id_partition_id_unique;
ALTER INDEX p_ci_builds_metadata_project_id_idx ATTACH PARTITION index_ci_builds_metadata_on_project_id;
CREATE TRIGGER chat_names_loose_fk_trigger AFTER DELETE ON chat_names REFERENCING OLD TABLE AS old_table FOR EACH STATEMENT EXECUTE FUNCTION insert_into_loose_foreign_keys_deleted_records();

View File

@ -249,5 +249,5 @@ Shortly after that, the client agents should rejoin as well.
If you have taken advantage of Consul to store other data and want to restore
the failed node, follow the
[Consul guide](https://learn.hashicorp.com/tutorials/consul/recovery-outage)
[Consul guide](https://developer.hashicorp.com/consul/tutorials/datacenter-operations/recovery-outage)
to recover a failed cluster.

View File

@ -1,11 +0,0 @@
---
redirect_to: 'container_registry.md'
remove_date: '2022-10-29'
---
This document was moved to [another location](container_registry.md).
<!-- This redirect file can be deleted after <2022-10-29>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

View File

@ -22,7 +22,7 @@ For each project to sync:
1. Geo issues a `git fetch geo --mirror` to get the latest information from the **primary** site.
If there are no changes, the sync is fast. Otherwise, it has to pull the latest commits.
1. The **secondary** site updates the tracking database to store the fact that it has synced projects A, B, C, and so on.
1. The **secondary** site updates the tracking database to store the fact that it has synced projects by name.
1. Repeat until all projects are synced.
When someone pushes a commit to the **primary** site, it generates an event in the GitLab database that the repository has changed.
@ -45,8 +45,8 @@ Read the documentation for [Disaster Recovery](../disaster_recovery/index.md).
## What data is replicated to a **secondary** site?
We currently replicate project repositories, LFS objects, generated
attachments and avatars, and the whole database. This means user accounts,
issues, merge requests, groups, project data, and so on, are available for
attachments and avatars, and the whole database. This means information such as user accounts,
issues, merge requests, groups, and project data are available for
query.
For more details, see the [supported Geo data types](datatypes.md).
@ -58,8 +58,8 @@ Pushing directly to a **secondary** site (for both HTTP and SSH, including Git L
## How long does it take to have a commit replicated to a **secondary** site?
All replication operations are asynchronous and are queued to be dispatched. Therefore, it depends on a lot of
factors including the amount of traffic, how big your commit is, the
connectivity between your sites, your hardware, and so on.
factors such as the amount of traffic, how big your commit is, the
connectivity between your sites, and your hardware.
## What if the SSH server runs at a different port?

View File

@ -25,8 +25,8 @@ from [owasp.org](https://owasp.org/).
### What data does the application receive, produce, and process?
- Geo streams almost all data held by a GitLab instance between sites. This
includes full database replication, most files (user-uploaded attachments,
and so on) and repository + wiki data. In a typical configuration, this will
includes full database replication, most files such as user-uploaded attachments,
and repository + wiki data. In a typical configuration, this will
happen across the public Internet, and be TLS-encrypted.
- PostgreSQL replication is TLS-encrypted.
- See also: [only TLSv1.2 should be supported](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/2948)
@ -37,7 +37,7 @@ from [owasp.org](https://owasp.org/).
private projects. Geo replicates them all indiscriminately. "Selective sync"
exists for files and repositories (but not database content), which would permit
only less-sensitive projects to be replicated to a **secondary** site if desired.
- See also: [GitLab data classification policy](https://about.gitlab.com/handbook/engineering/security/data-classification-standard.html).
- See also: [GitLab data classification policy](https://about.gitlab.com/handbook/security/data-classification-standard.html).
### What data backup and retention requirements have been defined for the application?
@ -59,8 +59,8 @@ from [owasp.org](https://owasp.org/).
(notably a HTTP/HTTPS web application, and HTTP/HTTPS or SSH Git repository
access), but is constrained to read-only activities. The principal use case is
envisioned to be cloning Git repositories from the **secondary** site in favor of the
**primary** site, but end-users may use the GitLab web interface to view projects,
issues, merge requests, snippets, and so on.
**primary** site, but end-users may use the GitLab web interface to view information like projects,
issues, merge requests, and snippets.
### What security expectations do the endusers have?

View File

@ -1218,7 +1218,8 @@ If you set up a new secondary from scratch, you must also [remove the old site f
The most common problems that prevent the database from replicating correctly are:
- **Secondary** sites cannot reach the **primary** site. Check credentials, [firewall rules](../index.md#firewall-rules), and so on.
- **Secondary** sites cannot reach the **primary** site. Check credentials and
[firewall rules](../index.md#firewall-rules).
- SSL certificate problems. Make sure you copied `/etc/gitlab/gitlab-secrets.json` from the **primary** site.
- Database storage disk is full.
- Database replication slot is misconfigured.

View File

@ -62,7 +62,7 @@ developed and tested. We aim to be compatible with most external
To set up an external database, you can either:
- Set up [streaming replication](https://www.postgresql.org/docs/12/warm-standby.html#STREAMING-REPLICATION-SLOTS) yourself (for example Amazon RDS, bare metal not managed by Omnibus, and so on).
- Set up [streaming replication](https://www.postgresql.org/docs/12/warm-standby.html#STREAMING-REPLICATION-SLOTS) yourself (for example Amazon RDS, or bare metal not managed by Omnibus).
- Perform the Omnibus configuration manually as follows.
#### Leverage your cloud provider's tools to replicate the primary database

View File

@ -1100,8 +1100,8 @@ benefit from it. It is orthogonal to:
- The transport (HTTP or SSH).
- Git protocol version (v0 or v2).
- The type of fetch (full clones, incremental fetches, shallow clones,
partial clones, and so on).
- The type of fetch, such as full clones, incremental fetches, shallow clones,
or partial clones.
The strength of this cache is its ability to deduplicate concurrent
identical fetches. It:

View File

@ -1,11 +0,0 @@
---
redirect_to: 'logs/index.md'
remove_date: '2022-10-23'
---
This document was moved to [another location](logs/index.md).
<!-- This redirect file can be deleted after <2022-10-23>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

View File

@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2149) in GitLab 13.9.
Maintenance Mode allows administrators to reduce write operations to a minimum while maintenance tasks are performed. The main goal is to block all external actions that change the internal state, including the PostgreSQL database, but especially files, Git repositories, Container repositories, and so on.
Maintenance Mode allows administrators to reduce write operations to a minimum while maintenance tasks are performed. The main goal is to block all external actions that change the internal state, including the PostgreSQL database, but especially files, Git repositories, and Container repositories.
Once Maintenance Mode is enabled, in-progress actions finish relatively quickly since no new actions are coming in, and internal state changes are minimal.
In that state, various maintenance tasks are easier, and services can be stopped completely or be

View File

@ -41,7 +41,7 @@ Two types of metrics are collected:
Transaction metrics are metrics that can be associated with a single
transaction. This includes statistics such as the transaction duration, timings
of any executed SQL queries, time spent rendering HAML views, and so on. These metrics
of any executed SQL queries, and time spent rendering HAML views. These metrics
are collected for every Rack request and Sidekiq job processed.
### Sampled Metrics

View File

@ -401,7 +401,7 @@ These client metrics are meant to complement Redis server metrics.
These metrics are broken down per
[Redis instance](https://docs.gitlab.com/omnibus/settings/redis.html#running-with-multiple-redis-instances).
These metrics all have a `storage` label which indicates the Redis
instance (`cache`, `shared_state`, and so on).
instance. For example, `cache` or `shared_state`.
| Metric | Type | Since | Description |
|:--------------------------------- |:------- |:----- |:----------- |

View File

@ -10,7 +10,7 @@ type: reference
NFS can be used as an alternative for object storage but this isn't typically
recommended for performance reasons.
For data objects such as LFS, Uploads, Artifacts, and so on, an [Object Storage service](object_storage.md)
For data objects such as LFS, Uploads, and Artifacts, an [Object Storage service](object_storage.md)
is recommended over NFS where possible, due to better performance.
When eliminating the usage of NFS, there are [additional steps you need to take](object_storage.md#other-alternatives-to-file-system-storage)
in addition to moving to Object Storage.
@ -338,7 +338,7 @@ following are the 4 locations need to be shared:
| -------- | ----------- | --------------------- |
| `/var/opt/gitlab/git-data` | Git repository data. This accounts for a large portion of your data | `git_data_dirs({"default" => { "path" => "/var/opt/gitlab/git-data"} })`
| `/var/opt/gitlab/gitlab-rails/uploads` | User uploaded attachments | `gitlab_rails['uploads_directory'] = '/var/opt/gitlab/gitlab-rails/uploads'`
| `/var/opt/gitlab/gitlab-rails/shared` | Build artifacts, GitLab Pages, LFS objects, temp files, and so on. If you're using LFS this may also account for a large portion of your data | `gitlab_rails['shared_path'] = '/var/opt/gitlab/gitlab-rails/shared'`
| `/var/opt/gitlab/gitlab-rails/shared` | Objects such as build artifacts, GitLab Pages, LFS objects, and temp files. If you're using LFS this may also account for a large portion of your data | `gitlab_rails['shared_path'] = '/var/opt/gitlab/gitlab-rails/shared'`
| `/var/opt/gitlab/gitlab-ci/builds` | GitLab CI/CD build traces | `gitlab_ci['builds_directory'] = '/var/opt/gitlab/gitlab-ci/builds'`
Other GitLab directories should not be shared between nodes. They contain

View File

@ -88,8 +88,8 @@ Object storage for <object type> must have a bucket specified
If you want to use local storage for specific object types, you can
[selectively disable object storages](#selectively-disabling-object-storage).
Most types of objects, such as CI artifacts, LFS files, upload
attachments, and so on can be saved in object storage by specifying a single
Most types of objects, such as CI artifacts, LFS files, and upload
attachments can be saved in object storage by specifying a single
credential for object storage with multiple buckets.
When the consolidated form is:
@ -492,7 +492,7 @@ To migrate existing local data to object storage see the following guides:
Prior to GitLab 13.2:
- Object storage configuration for all types of objects such as CI/CD artifacts, LFS
files, upload attachments, and so on had to be configured independently.
files, and upload attachments had to be configured independently.
- Object store connection parameters such as passwords and endpoint URLs had to be
duplicated for each type.

View File

@ -72,7 +72,7 @@ Some drawbacks of a package with bundled dependencies:
1. Duplication with possibly existing software.
1. Less flexibility in configuration.
## Why would I install an omnibus package when I can use a system package?
## Why would you install an omnibus package when you can use a system package?
The answer can be simplified to: less maintenance required. Instead of handling
multiple packages that *can* break existing functionality if the versions are

View File

@ -820,8 +820,8 @@ database encryption. Proceed with caution.
It's possible to run GitLab Pages on multiple servers if you wish to distribute
the load. You can do this through standard load balancing practices such as
configuring your DNS server to return multiple IPs for your Pages server,
configuring a load balancer to work at the IP level, and so on. If you wish to
configuring your DNS server to return multiple IPs for your Pages server, or
configuring a load balancer to work at the IP level. If you wish to
set up GitLab Pages on multiple servers, perform the above procedure for each
Pages server.

View File

@ -6,8 +6,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Polling interval multiplier **(FREE SELF)**
The GitLab UI polls for updates for different resources (issue notes, issue titles, pipeline
statuses, and so on) on a schedule appropriate to the resource.
The GitLab UI polls for updates for different resources (such as issue notes, issue titles, and pipeline
statuses) on a schedule appropriate to the resource.
Adjust the multiplier on these schedules to adjust how frequently the GitLab UI polls for updates. If
you set the multiplier to:

View File

@ -26,8 +26,8 @@ Start Redis troubleshooting with a basic Redis activity check:
1. Open a terminal on your GitLab server.
1. Run `gitlab-redis-cli --stat` and observe the output while it runs.
1. Go to your GitLab UI and browse to a handful of pages. Any page works, like
group or project overviews, issues, files in repositories, and so on.
1. Go to your GitLab UI and browse to a handful of pages. Any page works, such as
group or project overviews, issues, or files in repositories.
1. Check the `stat` output again and verify that the values for `keys`, `clients`,
`requests`, and `connections` increases as you browse. If the numbers go up,
basic Redis functionality is working and GitLab can connect to it.

View File

@ -35,7 +35,7 @@ For a full list of reference architectures, see
1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
- [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work.
- [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB clusters](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
- [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440), and [Azure Database for PostgreSQL](https://azure.microsoft.com/en-gb/services/postgresql/) is **not recommended** due to [performance issues](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/61).
- [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440), and [Azure Database for PostgreSQL](https://azure.microsoft.com/en-gb/products/postgresql/#overview) is **not recommended** due to [performance issues](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/61).
- Consul is primarily used for Omnibus PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However, Consul is also used optionally by Prometheus for Omnibus auto host discovery.
2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
- [Google Memorystore](https://cloud.google.com/memorystore) and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) are known to work.
@ -1010,7 +1010,7 @@ services where applicable):
1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
- [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work.
- [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB clusters](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
- [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440), and [Azure Database for PostgreSQL](https://azure.microsoft.com/en-gb/services/postgresql/) is **not recommended** due to [performance issues](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/61).
- [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440), and [Azure Database for PostgreSQL](https://azure.microsoft.com/en-gb/products/postgresql/#overview) is **not recommended** due to [performance issues](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/61).
- Consul is primarily used for Omnibus PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However, Consul is also used optionally by Prometheus for Omnibus auto host discovery.
2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
- [Google Memorystore](https://cloud.google.com/memorystore) and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) are known to work.

View File

@ -206,7 +206,7 @@ When selecting a database service, it should run a standard, performant, and [su
Several cloud provider services are known not to support the above or have been found to have other issues and aren't recommended:
- [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is incompatible and not supported. See [14.4.0](../../update/index.md#1440) for more details.
- [Azure Database for PostgreSQL Single Server](https://azure.microsoft.com/en-gb/services/postgresql/#overview) (Single / Flexible) is **strongly not recommended** for use due to notable performance / stability issues or missing functionality. See [Recommendation Notes for Azure](#recommendation-notes-for-azure) for more details.
- [Azure Database for PostgreSQL Single Server](https://azure.microsoft.com/en-gb/products/postgresql/#overview) (Single / Flexible) is **strongly not recommended** for use due to notable performance / stability issues or missing functionality. See [Recommendation Notes for Azure](#recommendation-notes-for-azure) for more details.
- [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB clusters](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
### Recommendation notes for Azure
@ -217,7 +217,7 @@ In addition to the above, you should be aware of the additional specific guidanc
- **We outright strongly do not recommend [Azure Database for PostgreSQL Single Server](https://learn.microsoft.com/en-us/azure/postgresql/single-server/overview-single-server)** specifically due to significant performance and stability issues found. **For GitLab 14.0 and higher the service is not supported** due to it only supporting up to PostgreSQL 11.
- A new service, [Azure Database for Postgres Flexible Server](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/) has been released but due to it missing some functionality we don't recommend it at this time.
- [Azure Blob Storage](https://azure.microsoft.com/en-gb/services/storage/blobs/) has been found to have performance limits that can impact production use at certain times. However, this has only been seen in larger architectures.
- [Azure Blob Storage](https://azure.microsoft.com/en-gb/products/storage/blobs/) has been found to have performance limits that can impact production use at certain times. However, this has only been seen in larger architectures.
## Validation and test results

View File

@ -1,11 +0,0 @@
---
redirect_to: '../configure.md'
remove_date: '2022-10-24'
---
This document was moved to [another location](../configure.md).
<!-- This redirect file can be deleted after <2022-10-24>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

View File

@ -1,11 +0,0 @@
---
redirect_to: '../reference_architectures/troubleshooting.md'
remove_date: '2022-10-19'
---
This document was moved to [another location](../reference_architectures/troubleshooting.md).
<!-- This redirect file can be deleted after 2022-10-19. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

View File

@ -1,11 +0,0 @@
---
redirect_to: '../../ci/troubleshooting.md#disaster-recovery'
remove_date: '2022-10-04'
---
This document was moved to [another location](../../ci/troubleshooting.md#disaster-recovery).
<!-- This redirect file can be deleted after <2022-10-04>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

View File

@ -1,11 +0,0 @@
---
redirect_to: '../../user/group/saml_sso/example_saml_config.md'
remove_date: '2022-10-29'
---
This document was moved to [another location](../../user/group/saml_sso/example_saml_config.md).
<!-- This redirect file can be deleted after <2022-10-29>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

View File

@ -1,11 +0,0 @@
---
redirect_to: 'https://docs.gitlab.com/charts/troubleshooting/kubernetes_cheat_sheet.html'
remove_date: '2022-10-05'
---
This document was moved to [another location](https://docs.gitlab.com/charts/troubleshooting/kubernetes_cheat_sheet.html).
<!-- This redirect file can be deleted after 2022-10-05. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

View File

@ -1,11 +0,0 @@
---
redirect_to: '../logs/log_parsing.md'
remove_date: '2022-10-24'
---
This document was moved to [another location](../logs/log_parsing.md).
<!-- This redirect file can be deleted after <2022-10-24>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

View File

@ -1,11 +0,0 @@
---
redirect_to: '../operations/rails_console.md'
remove_date: '2022-10-05'
---
This document was moved to [another location](../operations/rails_console.md).
<!-- This redirect file can be deleted after <2022-10-05>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

View File

@ -1506,8 +1506,8 @@ Please use `iid` of the `epic` attribute instead.
Clone the issue to given project. If the user has insufficient permissions,
an error message with status code `400` is returned.
Copies as much data as possible as long as the target project contains equivalent labels, milestones,
and so on.
Copies as much data as possible as long as the target project contains equivalent
criteria such as labels or milestones.
```plaintext
POST /projects/:id/issues/:issue_iid/clone

View File

@ -210,7 +210,7 @@ Example responses:
Checks if a project's latest (`HEAD` of the project's default branch)
`.gitlab-ci.yml` configuration is valid. This endpoint uses all namespace
specific data available, including variables, local includes, and so on.
specific data available, including variables and local includes.
```plaintext
GET /projects/:id/ci/lint

View File

@ -76,7 +76,7 @@ Prerequisites:
- [Authenticate AWS with GitLab](#authenticate-gitlab-with-aws).
- Create a cluster on Amazon ECS.
- Create related components, like an ECS service, a database on Amazon RDS, and so on.
- Create related components, like an ECS service or a database on Amazon RDS.
- Create an ECS task definition, where the value for the `containerDefinitions[].name` attribute is
the same as the `Container name` defined in your targeted ECS service. The task definition can be:
- An existing task definition in ECS.

View File

@ -16,7 +16,7 @@ Prerequisites:
- Access to an existing Azure Subscription with `Owner` access level.
- Access to the corresponding Azure Active Directory Tenant with at least the `Application Developer` access level.
- A local installation of the [Azure CLI](https://learn.microsoft.com/cli/azure/install-azure-cli).
- A local installation of the [Azure CLI](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli).
Alternatively, you can follow all the steps below with the [Azure Cloud Shell](https://shell.azure.com/).
- A GitLab project.
@ -27,11 +27,11 @@ To complete this tutorial:
1. [Grant permissions for the service principal](#grant-permissions-for-the-service-principal).
1. [Retrieve a temporary credential](#retrieve-a-temporary-credential).
For more information, review Azure's documentation on [Workload identity federation](https://learn.microsoft.com/azure/active-directory/develop/workload-identity-federation).
For more information, review Azure's documentation on [Workload identity federation](https://learn.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation).
## Create Azure AD application and service principal
To create an [Azure AD application](https://learn.microsoft.com/cli/azure/ad/app?view=azure-cli-latest#az-ad-app-create)
To create an [Azure AD application](https://learn.microsoft.com/en-us/cli/azure/ad/app?view=azure-cli-latest#az-ad-app-create)
and service principal:
1. In the Azure CLI, create the AD application:
@ -43,13 +43,13 @@ and service principal:
Save the `appId` (Application client ID) output, as you need it later
to configure your GitLab CI/CD pipeline.
1. Create a corresponding [Service Principal](https://learn.microsoft.com/cli/azure/ad/sp?view=azure-cli-latest#az-ad-sp-create):
1. Create a corresponding [Service Principal](https://learn.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest#az-ad-sp-create):
```shell
az ad sp create --id $appId --query appId -otsv
```
Instead of the Azure CLI, you can [use the Azure Portal to create these resources](https://learn.microsoft.com/azure/active-directory/develop/howto-create-service-principal-portal).
Instead of the Azure CLI, you can [use the Azure Portal to create these resources](https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal).
## Create Azure AD federated identity credentials
@ -88,7 +88,7 @@ identity credentials from the Azure Portal:
## Grant permissions for the service principal
After you create the credentials, use [`role assignment`](https://learn.microsoft.com/cli/azure/role/assignment?view=azure-cli-latest#az-role-assignment-create)
After you create the credentials, use [`role assignment`](https://learn.microsoft.com/en-us/cli/azure/role/assignment?view=azure-cli-latest#az-role-assignment-create)
to grant permissions to the above service principal to access to Azure resources:
```shell
@ -97,13 +97,13 @@ az role assignment create --assignee $appId --role Reader --scope /subscriptions
You can find your subscription ID in:
- The [Azure Portal](https://learn.microsoft.com/azure/azure-portal/get-subscription-tenant-id#find-your-azure-subscription).
- The [Azure CLI](https://learn.microsoft.com/cli/azure/manage-azure-subscriptions-azure-cli#get-the-active-subscription).
- The [Azure Portal](https://learn.microsoft.com/en-us/azure/azure-portal/get-subscription-tenant-id#find-your-azure-subscription).
- The [Azure CLI](https://learn.microsoft.com/en-us/cli/azure/manage-azure-subscriptions-azure-cli#get-the-active-subscription).
## Retrieve a temporary credential
After you configure the Azure AD application and federated identity credentials,
the CI/CD job can retrieve a temporary credential by using the [Azure CLI](https://learn.microsoft.com/cli/azure/reference-index?view=azure-cli-latest#az-login):
the CI/CD job can retrieve a temporary credential by using the [Azure CLI](https://learn.microsoft.com/en-us/cli/azure/reference-index?view=azure-cli-latest#az-login):
```yaml
default:
@ -123,7 +123,7 @@ The CI/CD variables are:
- `AZURE_CLIENT_ID`: The [application client ID you saved earlier](#create-azure-ad-application-and-service-principal).
- `AZURE_TENANT_ID`: Your Azure Active Directory. You can
[find it by using the Azure CLI or Azure Portal](https://learn.microsoft.com/azure/active-directory/fundamentals/active-directory-how-to-find-tenant).
[find it by using the Azure CLI or Azure Portal](https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-how-to-find-tenant).
- `CI_JOB_JWT_V2`: The JSON web token is a [predefined CI/CD variable](../../variables/predefined_variables.md).
## Troubleshooting

View File

@ -29,7 +29,7 @@ The Environments dashboard displays a paginated list of projects that includes
up to three environments per project.
The listed environments for each project are unique, such as
"production", "staging", and so on. Review apps and other grouped
"production" and "staging". Review apps and other grouped
environments are not displayed.
## Adding a project to the dashboard

View File

@ -29,7 +29,7 @@ You must replace the `vault.example.com` URL below with the URL of your Vault se
## How it works
Each job has JSON Web Token (JWT) provided as CI/CD variable named `CI_JOB_JWT`. This JWT can be used to authenticate with Vault using the [JWT Auth](https://www.vaultproject.io/docs/auth/jwt#jwt-authentication) method.
Each job has JSON Web Token (JWT) provided as CI/CD variable named `CI_JOB_JWT`. This JWT can be used to authenticate with Vault using the [JWT Auth](https://developer.hashicorp.com/vault/docs/auth/jwt#jwt-authentication) method.
The following fields are included in the JWT:
@ -90,7 +90,7 @@ The JWT is encoded by using RS256 and signed with a dedicated private key. The e
You can use this JWT and your instance's JWKS endpoint (`https://gitlab.example.com/-/jwks`) to authenticate with a Vault server that is configured to allow the JWT Authentication method for authentication.
When configuring roles in Vault, you can use [bound_claims](https://www.vaultproject.io/docs/auth/jwt#bound-claims) to match against the JWT's claims and restrict which secrets each CI job has access to.
When configuring roles in Vault, you can use [bound_claims](https://developer.hashicorp.com/vault/docs/auth/jwt#bound-claims) to match against the JWT's claims and restrict which secrets each CI job has access to.
To communicate with Vault, you can use either its CLI client or perform API requests (using `curl` or another client).
@ -109,7 +109,7 @@ $ vault kv get -field=password secret/myproject/production/db
real-pa$$w0rd
```
To configure your Vault server, start by enabling the [JWT Auth](https://www.vaultproject.io/docs/auth/jwt) method:
To configure your Vault server, start by enabling the [JWT Auth](https://developer.hashicorp.com/vault/docs/auth/jwt) method:
```shell
$ vault auth enable jwt
@ -180,17 +180,17 @@ $ vault write auth/jwt/role/myproject-production - <<EOF
EOF
```
This example uses [bound_claims](https://www.vaultproject.io/api-docs/auth/jwt#bound_claims) to specify that only a JWT with matching values for the specified claims is allowed to authenticate.
This example uses [bound_claims](https://developer.hashicorp.com/vault/api-docs/auth/jwt#bound_claims) to specify that only a JWT with matching values for the specified claims is allowed to authenticate.
Combined with [protected branches](../../../user/project/protected_branches.md), you can restrict who is able to authenticate and read the secrets.
[`token_explicit_max_ttl`](https://www.vaultproject.io/api-docs/auth/jwt#token_explicit_max_ttl) specifies that the token issued by Vault, upon successful authentication, has a hard lifetime limit of 60 seconds.
[`token_explicit_max_ttl`](https://developer.hashicorp.com/vault/api-docs/auth/jwt#token_explicit_max_ttl) specifies that the token issued by Vault, upon successful authentication, has a hard lifetime limit of 60 seconds.
[`user_claim`](https://www.vaultproject.io/api-docs/auth/jwt#user_claim) specifies the name for the Identity alias created by Vault upon a successful login.
[`user_claim`](https://developer.hashicorp.com/vault/api-docs/auth/jwt#user_claim) specifies the name for the Identity alias created by Vault upon a successful login.
[`bound_claims_type`](https://www.vaultproject.io/api-docs/auth/jwt#bound_claims_type) configures the interpretation of the `bound_claims` values. If set to `glob`, the values are interpreted as globs, with `*` matching any number of characters.
[`bound_claims_type`](https://developer.hashicorp.com/vault/api-docs/auth/jwt#bound_claims_type) configures the interpretation of the `bound_claims` values. If set to `glob`, the values are interpreted as globs, with `*` matching any number of characters.
The claim fields listed in [the table above](#how-it-works) can also be accessed for [Vault's policy path templating](https://learn.hashicorp.com/tutorials/vault/policy-templating?in=vault/policies) purposes by using the accessor name of the JWT auth within Vault. The [mount accessor name](https://learn.hashicorp.com/tutorials/vault/identity#step-1-create-an-entity-with-alias) (`ACCESSOR_NAME` in the example below) can be retrieved by running `vault auth list`.
The claim fields listed in [the table above](#how-it-works) can also be accessed for [Vault's policy path templating](https://developer.hashicorp.com/vault/tutorials/policies/policy-templating?in=vault%2Fpolicies) purposes by using the accessor name of the JWT auth within Vault. The [mount accessor name](https://developer.hashicorp.com/vault/tutorials/auth-methods/identity#step-1-create-an-entity-with-alias) (`ACCESSOR_NAME` in the example below) can be retrieved by running `vault auth list`.
Policy template example making use of a named metadata field named `project_path`:
@ -200,7 +200,7 @@ path "secret/data/{{identity.entity.aliases.ACCESSOR_NAME.metadata.project_path}
}
```
Role example to support the templated policy above, mapping the claim field `project_path` as a metadata field through use of [`claim_mappings`](https://www.vaultproject.io/api-docs/auth/jwt#claim_mappings) configuration:
Role example to support the templated policy above, mapping the claim field `project_path` as a metadata field through use of [`claim_mappings`](https://developer.hashicorp.com/vault/api-docs/auth/jwt#claim_mappings) configuration:
```plaintext
{
@ -212,7 +212,7 @@ Role example to support the templated policy above, mapping the claim field `pro
}
```
For the full list of options, see Vault's [Create Role documentation](https://www.vaultproject.io/api-docs/auth/jwt#create-role).
For the full list of options, see Vault's [Create Role documentation](https://developer.hashicorp.com/vault/api-docs/auth/jwt#create-role).
WARNING:
Always restrict your roles to project or namespace by using one of the provided claims (for example, `project_id` or `namespace_id`). Otherwise any JWT generated by this instance may be allowed to authenticate using this role.
@ -225,9 +225,9 @@ $ vault write auth/jwt/config \
bound_issuer="gitlab.example.com"
```
[bound_issuer](https://www.vaultproject.io/api-docs/auth/jwt#bound_issuer) specifies that only a JWT with the issuer (that is, the `iss` claim) set to `gitlab.example.com` can use this method to authenticate, and that the JWKS endpoint (`https://gitlab.example.com/-/jwks`) should be used to validate the token.
[bound_issuer](https://developer.hashicorp.com/vault/api-docs/auth/jwt#bound_issuer) specifies that only a JWT with the issuer (that is, the `iss` claim) set to `gitlab.example.com` can use this method to authenticate, and that the JWKS endpoint (`https://gitlab.example.com/-/jwks`) should be used to validate the token.
For the full list of available configuration options, see Vault's [API documentation](https://www.vaultproject.io/api-docs/auth/jwt#configure).
For the full list of available configuration options, see Vault's [API documentation](https://developer.hashicorp.com/vault/api-docs/auth/jwt#configure).
The following job, when run for the default branch, is able to read secrets under `secret/myproject/staging/`, but not the secrets under `secret/myproject/production/`:
@ -242,7 +242,7 @@ read_secrets:
# Vault's address can be provided here or as CI/CD variable
- export VAULT_ADDR=http://vault.example.com:8200
# Authenticate and get token. Token expiry time and other properties can be configured
# when configuring JWT Auth - https://www.vaultproject.io/api-docs/auth/jwt#parameters-1
# when configuring JWT Auth - https://developer.hashicorp.com/vault/api-docs/auth/jwt#parameters-1
- export VAULT_TOKEN="$(vault write -field=token auth/jwt/login role=myproject-staging jwt=$CI_JOB_JWT)"
# Now use the VAULT_TOKEN to read the secret and store it in an environment variable
- export PASSWORD="$(vault kv get -field=password secret/myproject/staging/db)"
@ -271,7 +271,7 @@ read_secrets:
# Vault's address can be provided here or as CI/CD variable
- export VAULT_ADDR=http://vault.example.com:8200
# Authenticate and get token. Token expiry time and other properties can be configured
# when configuring JWT Auth - https://www.vaultproject.io/api-docs/auth/jwt#parameters-1
# when configuring JWT Auth - https://developer.hashicorp.com/vault/api-docs/auth/jwt#parameters-1
- export VAULT_TOKEN="$(vault write -field=token auth/jwt/login role=myproject-production jwt=$CI_JOB_JWT)"
# Now use the VAULT_TOKEN to read the secret and store it in environment variable
- export PASSWORD="$(vault kv get -field=password secret/myproject/production/db)"
@ -286,11 +286,11 @@ read_secrets:
You can control `CI_JOB_JWT` access to Vault secrets by using Vault protections
and GitLab features. For example, restrict the token by:
- Using Vault [bound_claims](https://www.vaultproject.io/docs/auth/jwt#bound-claims)
- Using Vault [bound_claims](https://developer.hashicorp.com/vault/docs/auth/jwt#bound-claims)
for specific groups using `group_claim`.
- Hard coding values for Vault bound claims based on the `user_login` and `user_email`
of specific users.
- Setting Vault time limits for TTL of the token as specified in [`token_explicit_max_ttl`](https://www.vaultproject.io/api-docs/auth/jwt#token_explicit_max_ttl),
- Setting Vault time limits for TTL of the token as specified in [`token_explicit_max_ttl`](https://developer.hashicorp.com/vault/api-docs/auth/jwt#token_explicit_max_ttl),
where the token expires after authentication.
- Scoping the JWT to [GitLab protected branches](../../../user/project/protected_branches.md)
that are restricted to a subset of project users.

View File

@ -47,7 +47,7 @@ All these operations put all files into a `build` folder, which is ready to be d
## How to transfer files to a live server
You have multiple options: rsync, SCP, SFTP, and so on. For now, use SCP.
You have multiple options such as rsync, SCP, or SFTP. For now, use SCP.
To make this work, you must add a GitLab CI/CD Variable (accessible on `gitlab.example/your-project-name/variables`). Name this variable `STAGING_PRIVATE_KEY` and set it to the **private** SSH key of your server.

View File

@ -26,8 +26,8 @@ You can use a GitLab CI/CD job token to authenticate with specific API endpoints
- [Terraform plan](../../user/infrastructure/index.md).
The token has the same permissions to access the API as the user that caused the
job to run. A user can cause a job to run by pushing a commit, triggering a manual job,
being the owner of a scheduled pipeline, and so on. Therefore, this user must be assigned to
job to run. A user can cause a job to run by taking action like pushing a commit,
triggering a manual job, or being the owner of a scheduled pipeline. Therefore, this user must be assigned to
[a role that has the required privileges](../../user/permissions.md#gitlab-cicd-permissions).
The token is valid only while the pipeline job runs. After the job finishes, you can't

View File

@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
When a new pipeline starts, GitLab checks the pipeline configuration to determine
which jobs should run in that pipeline. You can configure jobs to run depending on
the status of variables, the pipeline type, and so on.
factors like the status of variables, or the pipeline type.
To configure a job to be included or excluded from certain pipelines, you can use:
@ -1061,7 +1061,7 @@ docker_build:
When the `DOCKERFILES_DIR` variable is expanded in the `changes:` section, the full
path becomes `path/to/files//*`. The double slashes might cause unexpected behavior
depending on the keyword used, shell and OS of the runner, and so on.
depending on factors like the keyword used, or the shell and OS of the runner.
### `You are not allowed to download code from this project.` error message

View File

@ -49,8 +49,8 @@ things we have found that help this:
your users understand why the effort is worth it. The value is clear when
the work is done, but people need to be aware while it's in progress too.
- Sponsorship and alignment from the relevant leadership team helps with the point above.
- Spending time educating your users on what's different, sharing this document with them,
and so on helps ensure you are successful.
- Spending time educating your users on what's different and sharing this document
with them helps ensure you are successful.
- Finding ways to sequence or delay parts of the migration can help a lot, but you
don't want to leave things in a non-migrated (or partially-migrated) state for too
long. To gain all the benefits of GitLab, moving your existing Jenkins setup over
@ -67,7 +67,7 @@ of transition, by letting you delay the migration of less urgent pipelines for a
If you are interested in helping GitLab test the wrapper, join our [public testing issue](https://gitlab.com/gitlab-org/gitlab/-/issues/215675) for instructions and to provide your feedback.
NOTE:
If you have a paid GitLab subscription, note that the JenkinsFile Wrapper is not packaged as part of GitLab, and falls outside of the scope of support. For more information, see the [Statement of Support](https://about.gitlab.com/support/statement-of-support.html).
If you have a paid GitLab subscription, note that the JenkinsFile Wrapper is not packaged as part of GitLab, and falls outside of the scope of support. For more information, see the [Statement of Support](https://about.gitlab.com/support/statement-of-support/).
## Important product differences
@ -197,7 +197,7 @@ can leverage. You can see the complete list of packaging features in the
## Integrated features
Where you may have used plugins to get things like code quality, unit tests, security scanning, and so on working in Jenkins,
Where you may have used plugins to get things like code quality, unit tests, and security scanning working in Jenkins,
GitLab takes advantage of our connected ecosystem to automatically pull these kinds of results into
your merge requests, pipeline details pages, and other locations. You may find that you actually don't
need to configure anything to have these appear.

View File

@ -232,7 +232,7 @@ For this reduced cost factor:
- The merge request source project must be a fork of a GitLab-maintained project,
such as [`gitlab-com/www-gitlab-com`](https://gitlab.com/gitlab-com/www-gitlab-com),
[`gitlab-org/gitlab`](https://gitlab.com/gitlab-org/gitlab), and so on.
or [`gitlab-org/gitlab`](https://gitlab.com/gitlab-org/gitlab).
- The merge request target project must be the fork's parent project.
- The pipeline must be a merge request, merged results, or merge train pipeline.

View File

@ -80,7 +80,7 @@ You can also configure specific aspects of your pipelines through the GitLab UI.
### Ref specs for runners
When a runner picks a pipeline job, GitLab provides that job's metadata. This includes the [Git refspecs](https://git-scm.com/book/en/v2/Git-Internals-The-Refspec),
which indicate which ref (branch, tag, and so on) and commit (SHA1) are checked out from your
which indicate which ref (such as branch or tag) and commit (SHA1) are checked out from your
project repository.
This table lists the refspecs injected for each pipeline type:
@ -158,7 +158,7 @@ The pipeline now executes the jobs as configured.
You can use the [`description` and `value`](../yaml/index.md#variablesdescription)
keywords to define [pipeline-level (global) variables](../variables/index.md#create-a-custom-cicd-variable-in-the-gitlab-ciyml-file)
that are prefilled when running a pipeline manually. Use the description to explain
what the variable is used for, what the acceptable values are, and so on.
information such as what the variable is used for, and what the acceptable values are.
Job-level variables cannot be pre-filled.

View File

@ -34,7 +34,7 @@ own advantages. These methods can be mixed and matched if needed:
## Basic Pipelines
This is the simplest pipeline in GitLab. It runs everything in the build stage concurrently,
and once all of those finish, it runs everything in the test stage the same way, and so on.
and once all of those finish, it runs everything in the test and subsequent stages the same way.
It's not the most efficient, and if you have lots of steps it can grow quite complex, but it's
easier to maintain:

View File

@ -225,7 +225,7 @@ has more information about building efficient Docker images.
Methods to reduce Docker image size:
- Use a small base image, for example `debian-slim`.
- Do not install convenience tools like vim, curl, and so on, if they aren't strictly needed.
- Do not install convenience tools such as vim or curl if they aren't strictly needed.
- Create a dedicated development image.
- Disable man pages and docs installed by packages to save space.
- Reduce the `RUN` layers and combine software installation steps.

View File

@ -20,11 +20,11 @@ required by a job. Read [GitLab CI/CD pipeline configuration reference](../yaml/
for more information about the syntax.
GitLab has selected [Vault by HashiCorp](https://www.vaultproject.io) as the
first supported provider, and [KV-V2](https://www.vaultproject.io/docs/secrets/kv/kv-v2)
first supported provider, and [KV-V2](https://developer.hashicorp.com/vault/docs/secrets/kv/kv-v2)
as the first supported secrets engine.
GitLab authenticates using Vault's
[JSON Web Token (JWT) authentication method](https://www.vaultproject.io/docs/auth/jwt#jwt-authentication), using
[JSON Web Token (JWT) authentication method](https://developer.hashicorp.com/vault/docs/auth/jwt#jwt-authentication), using
the [JSON Web Token](https://gitlab.com/gitlab-org/gitlab/-/issues/207125) (`CI_JOB_JWT`)
introduced in GitLab 12.10.
@ -88,10 +88,10 @@ To configure your Vault server:
- `VAULT_SERVER_URL` - The URL of your Vault server, such as `https://vault.example.com:8200`.
Required.
- `VAULT_AUTH_ROLE` - Optional. The role to use when attempting to authenticate.
If no role is specified, Vault uses the [default role](https://www.vaultproject.io/api-docs/auth/jwt#default_role)
If no role is specified, Vault uses the [default role](https://developer.hashicorp.com/vault/api-docs/auth/jwt#default_role)
specified when the authentication method was configured.
- `VAULT_AUTH_PATH` - Optional. The path where the authentication method is mounted, default is `jwt`.
- `VAULT_NAMESPACE` - Optional. The [Vault Enterprise namespace](https://www.vaultproject.io/docs/enterprise/namespaces) to use for reading secrets and authentication.
- `VAULT_NAMESPACE` - Optional. The [Vault Enterprise namespace](https://developer.hashicorp.com/vault/docs/enterprise/namespaces) to use for reading secrets and authentication.
If no namespace is specified, Vault uses the `root` ("`/`") namespace.
The setting is ignored by Vault Open Source.
@ -142,7 +142,7 @@ When a CI job attempts to authenticate, it specifies a role. You can use roles t
different policies together. If authentication is successful, these policies are
attached to the resulting Vault token.
[Bound claims](https://www.vaultproject.io/docs/auth/jwt#bound-claims) are predefined
[Bound claims](https://developer.hashicorp.com/vault/docs/auth/jwt#bound-claims) are predefined
values that are matched to the JWT's claims. With bounded claims, you can restrict access
to specific GitLab users, specific projects, or even jobs running for specific Git
references. You can have as many bounded claims you need, but they must *all* match
@ -183,7 +183,7 @@ For a full list of `CI_JOB_JWT` claims, read the
You can also specify some attributes for the resulting Vault tokens, such as time-to-live,
IP address range, and number of uses. The full list of options is available in
[Vault's documentation on creating roles](https://www.vaultproject.io/api-docs/auth/jwt#create-role)
[Vault's documentation on creating roles](https://developer.hashicorp.com/vault/api-docs/auth/jwt#create-role)
for the JSON web token method.
## Using a self-signed Vault server

View File

@ -3599,7 +3599,7 @@ Use `secrets:vault` to specify secrets provided by a [HashiCorp Vault](https://w
**Example of `secrets:vault`**:
To specify all details explicitly and use the [KV-V2](https://www.vaultproject.io/docs/secrets/kv/kv-v2) secrets engine:
To specify all details explicitly and use the [KV-V2](https://developer.hashicorp.com/vault/docs/secrets/kv/kv-v2) secrets engine:
```yaml
job:

View File

@ -21,7 +21,7 @@ While any events could trigger an Audit Event, not all events should. In general
- Not attributable to one specific user.
- Not of specific interest to an administrator or owner persona.
- Are tracking information for product feature adoption.
- Are covered in the direction page's discussion on [what is not planned](https://about.gitlab.com/direction/manage/compliance/audit-events/#what-is-not-planned-right-now).
- Are covered in the direction page's discussion on [what is not planned](https://about.gitlab.com/direction/govern/compliance/audit-events/#what-is-not-planned-right-now).
If you have any questions, please reach out to `@gitlab-org/govern/compliance` to see if an Audit Event, or some other approach, may be best for your event.

View File

@ -212,8 +212,8 @@ See the [test engineering process](https://about.gitlab.com/handbook/engineering
##### Security
1. I have confirmed that if this MR contains changes to processing or storing of credentials or tokens, authorization, and authentication methods, or other items described in [the security review guidelines](https://about.gitlab.com/handbook/engineering/security/#when-to-request-a-security-review), I have added the `~security` label and I have `@`-mentioned `@gitlab-com/gl-security/appsec`.
1. I have reviewed the documentation regarding [internal application security reviews](https://about.gitlab.com/handbook/engineering/security/#internal-application-security-reviews) for **when** and **how** to request a security review and requested a security review if this is warranted for this change.
1. I have confirmed that if this MR contains changes to processing or storing of credentials or tokens, authorization, and authentication methods, or other items described in [the security review guidelines](https://about.gitlab.com/handbook/security/#when-to-request-a-security-review), I have added the `~security` label and I have `@`-mentioned `@gitlab-com/gl-security/appsec`.
1. I have reviewed the documentation regarding [internal application security reviews](https://about.gitlab.com/handbook/security/#internal-application-security-reviews) for **when** and **how** to request a security review and requested a security review if this is warranted for this change.
##### Deployment
@ -508,7 +508,7 @@ people who add commits to an MR are not authorized to approve the merge request,
so they must seek a maintainer who has not contributed to the MR to approve the MR before it can be merged.
This policy is in place to satisfy the CHG-04 control of the GitLab
[Change Management Controls](https://about.gitlab.com/handbook/engineering/security/security-assurance/security-compliance/guidance/change-management.html).
[Change Management Controls](https://about.gitlab.com/handbook/security/security-assurance/security-compliance/guidance/change-management.html).
To implement this policy in `gitlab-org/gitlab`, we have enabled the following
settings to ensure MRs get an approval from a top-level CODEOWNERS maintainer:

View File

@ -24,7 +24,7 @@ screenshots (or videos) of your changes in the description, as explained in our
[MR workflow](merge_request_workflow.md). These screenshots/videos are very helpful
for all reviewers and can speed up the review process, especially if the changes
are small.
- Attach the ~UX label to any merge request that impacts the user experience. This will enable Product Designers to [review](https://about.gitlab.com/handbook/engineering/ux/product-designer/mr-reviews/#stage-group-mrs/) any user facing changes.
- Attach the ~UX label to any merge request that impacts the user experience. This will enable Product Designers to [review](https://about.gitlab.com/handbook/product/ux/product-designer/mr-reviews/#stage-group-mrs/) any user facing changes.
- Assign the Product Designer suggested by Reviewer Roulette as the reviewer of your merge request. The reviewer does not have to be the domain expert unless this is a community contribution.
## Checklist

View File

@ -80,7 +80,7 @@ In these cases, use the following workflow:
- [Backend](https://about.gitlab.com/handbook/engineering/)
- [Database](https://about.gitlab.com/handbook/engineering/development/database/)
- [User Experience (UX)](https://about.gitlab.com/handbook/product/ux/)
- [Security](https://about.gitlab.com/handbook/engineering/security/)
- [Security](https://about.gitlab.com/handbook/security/)
- [Quality](https://about.gitlab.com/handbook/engineering/quality/)
- [Engineering Productivity](https://about.gitlab.com/handbook/engineering/quality/engineering-productivity/)
- [Infrastructure](https://about.gitlab.com/handbook/engineering/infrastructure/)

View File

@ -203,7 +203,7 @@ This [GitHub pull request](https://github.com/awslabs/amazon-eks-ami/pull/898) m
it possible to create an Amazon Linux 2 EKS AMI with FIPS enabled for Kubernetes v1.21.
To build an image:
1. [Install Packer](https://learn.hashicorp.com/tutorials/packer/get-started-install-cli).
1. [Install Packer](https://developer.hashicorp.com/packer/tutorials/docker-get-started/get-started-install-cli).
1. Run the following:
```shell

View File

@ -66,7 +66,7 @@ This means that new dependencies should, at a minimum, meet the following criter
When adding a new gem to our `Gemfile` or even changing versions in
`Gemfile.lock` it is strongly recommended that you
[request a Security review](https://about.gitlab.com/handbook/engineering/security/#how-to-request-a-security-review).
[request a Security review](https://about.gitlab.com/handbook/security/#how-to-request-a-security-review).
New gems add an extra security risk for GitLab, and it is important to
evaluate this risk before we ship this to production. Technically, just adding
a new gem and pushing to a branch in our main `gitlab` project is a security

View File

@ -1,11 +0,0 @@
---
redirect_to: 'ee_features.md'
remove_date: '2022-10-08'
---
This document was moved to [another location](ee_features.md).
<!-- This redirect file can be deleted after <2022-10-08>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

View File

@ -1,11 +0,0 @@
---
redirect_to: '../fe_guide/merge_request_widget_extensions.md'
remove_date: '2022-10-27'
---
This document was moved to [another location](../fe_guide/merge_request_widget_extensions.md).
<!-- This redirect file can be deleted after <2022-10-27>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

View File

@ -1271,7 +1271,7 @@ This sensitive data must be handled carefully to avoid leaks which could lead to
- The [Gitleaks Git hook](https://gitlab.com/gitlab-com/gl-security/security-research/gitleaks-endpoint-installer) is recommended for preventing credentials from being committed.
- Never log credentials under any circumstance. Issue [#353857](https://gitlab.com/gitlab-org/gitlab/-/issues/353857) is an example of credential leaks through log file.
- When credentials are required in a CI/CD job, use [masked variables](../ci/variables/index.md#mask-a-cicd-variable) to help prevent accidental exposure in the job logs. Be aware that when [debug logging](../ci/variables/index.md#debug-logging) is enabled, all masked CI/CD variables are visible in job logs. Also consider using [protected variables](../ci/variables/index.md#protected-cicd-variables) when possible so that sensitive CI/CD variables are only available to pipelines running on protected branches or protected tags.
- Proper scanners must be enabled depending on what data those credentials are protecting. See the [Application Security Inventory Policy](https://about.gitlab.com/handbook/engineering/security/security-engineering-and-research/application-security/inventory.html#policies) and our [Data Classification Standards](https://about.gitlab.com/handbook/engineering/security/data-classification-standard.html#data-classification-standards).
- Proper scanners must be enabled depending on what data those credentials are protecting. See the [Application Security Inventory Policy](https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/inventory.html#policies) and our [Data Classification Standards](https://about.gitlab.com/handbook/security/data-classification-standard.html#data-classification-standards).
- To store and/or share credentials between teams, refer to [1Password for Teams](https://about.gitlab.com/handbook/security/#1password-for-teams) and follow [the 1Password Guidelines](https://about.gitlab.com/handbook/security/#1password-guidelines).
- If you need to share a secret with a team member, use 1Password. Do not share a secret over email, Slack, or other service on the Internet.
@ -1281,7 +1281,7 @@ This sensitive data must be handled carefully to avoid leaks which could lead to
- Avoid including credentials as part of an HTTP response unless it is absolutely necessary as part of the workflow. For example, generating a PAT for users.
- Avoid sending credentials in URL parameters, as these can be more easily logged inadvertently during transit.
In the event of credential leak through an MR, issue, or any other medium, [reach out to SIRT team](https://about.gitlab.com/handbook/engineering/security/security-operations/sirt/#-engaging-sirt).
In the event of credential leak through an MR, issue, or any other medium, [reach out to SIRT team](https://about.gitlab.com/handbook/security/security-operations/sirt/#-engaging-sirt).
## Serialization

View File

@ -504,7 +504,7 @@ Service Ping reporting process state is monitored with [internal SiSense dashboa
- [Product Intelligence Guide](https://about.gitlab.com/handbook/product/product-intelligence-guide/)
- [Snowplow Guide](../snowplow/index.md)
- [Product Intelligence Direction](https://about.gitlab.com/direction/product-intelligence/)
- [Product Intelligence Direction](https://about.gitlab.com/direction/analytics/product-intelligence/)
- [Data Analysis Process](https://about.gitlab.com/handbook/business-technology/data-team/#data-analysis-process/)
- [Data for Product Managers](https://about.gitlab.com/handbook/business-technology/data-team/programs/data-for-product-managers/)
- [Data Infrastructure](https://about.gitlab.com/handbook/business-technology/data-team/platform/infrastructure/)

View File

@ -13,7 +13,7 @@ This page describes how to:
## Snowplow JavaScript frontend tracking
GitLab provides a `Tracking` interface that wraps the [Snowplow JavaScript tracker](https://docs.snowplowanalytics.com/docs/collecting-data/collecting-from-own-applications/javascript-trackers/)
GitLab provides a `Tracking` interface that wraps the [Snowplow JavaScript tracker](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/javascript-trackers/)
to track custom events.
For the recommended frontend tracking implementation, see [Usage recommendations](#usage-recommendations).
@ -349,7 +349,7 @@ describe('MyTracking', () => {
### Form tracking
To enable Snowplow automatic [form tracking](https://docs.snowplowanalytics.com/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracking-specific-events/#form-tracking):
To enable Snowplow automatic [form tracking](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracking-specific-events/#form-tracking):
1. Call `Tracking.enableFormTracking` when the DOM is ready.
1. Provide a `config` object that includes at least one of the following elements:
@ -389,7 +389,7 @@ describe('MyFormTracking', () => {
## Implement Ruby backend tracking
`Gitlab::Tracking` is an interface that wraps the [Snowplow Ruby Tracker](https://docs.snowplowanalytics.com/docs/collecting-data/collecting-from-own-applications/ruby-tracker/) for tracking custom events.
`Gitlab::Tracking` is an interface that wraps the [Snowplow Ruby Tracker](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/ruby-tracker/) for tracking custom events.
Backend tracking provides:
- User behavior tracking
@ -451,7 +451,7 @@ Before you test frontend events in development, you must:
1. Turn off ad blockers that could prevent Snowplow JavaScript from loading in your environment.
1. Turn off "Do Not Track" (DNT) in your browser.
All URLs are pseudonymized. The entity identifier [replaces](https://docs.snowplowanalytics.com/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracker-setup/other-parameters-2/#Setting_a_custom_page_URL_and_referrer_URL) personally identifiable
All URLs are pseudonymized. The entity identifier [replaces](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracker-setup/other-parameters-2/#setting-a-custom-page-url-and-referrer-url) personally identifiable
information (PII). PII includes usernames, group, and project names.
Page titles are hardcoded as `GitLab` for the same reason.
@ -477,7 +477,7 @@ For a video tutorial, see the [Snowplow plugin walk through](https://www.youtube
#### Snowplow Micro
[Snowplow Micro](https://snowplowanalytics.com/blog/2019/07/17/introducing-snowplow-micro/) is a
[Snowplow Micro](https://snowplow.io/blog/introducing-snowplow-micro/) is a
Docker-based solution for testing backend and frontend in a local development environment. Snowplow Micro
records the same events as the full Snowplow pipeline. To query events, use the Snowplow Micro API.

View File

@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
Snowplow is an enterprise-grade marketing and Product Intelligence platform that tracks how users engage with our website and application.
[Snowplow](https://snowplowanalytics.com) consists of several loosely-coupled sub-systems:
[Snowplow](https://snowplow.io/) consists of several loosely-coupled sub-systems:
- **Trackers** fire Snowplow events. Snowplow has twelve trackers that cover web, mobile, desktop, server, and IoT.
- **Collectors** receive Snowplow events from trackers. We use different event collectors that synchronize events to Amazon S3, Apache Kafka, or Amazon Kinesis.
@ -82,10 +82,10 @@ For more details about the architecture, see [Snowplow infrastructure](infrastru
## Event schema
Click events must be consistent. If each feature captures events differently, it can be difficult
All the events must be consistent. If each feature captures events differently, it can be difficult
to perform analysis.
Each click event provides attributes that describe the event.
Each event provides attributes that describe the event.
| Attribute | Type | Required | Description |
| --------- | ------- | -------- | ----------- |
@ -94,6 +94,7 @@ Each click event provides attributes that describe the event.
| label | text | false | The specific element or object to act on. This can be one of the following: the label of the element, for example, a tab labeled 'Create from template' for `create_from_template`; a unique identifier if no text is available, for example, `groups_dropdown_close` for closing the Groups dropdown list in the top bar; or the name or title attribute of a record being created. For Service Ping metrics adapted to Snowplow events, this should be the full metric [key path](../service_ping/metrics_dictionary.md#metric-key_path) taken from its definition file. |
| property | text | false | Any additional property of the element, or object being acted on. For Service Ping metrics adapted to Snowplow events, this should be additional information or context that can help analyze the event. For example, in the case of `usage_activity_by_stage_monthly.create.merge_requests_users`, there are four different possible merge request actions: "create", "merge", "comment", and "close". Each of these would be a possible property value. |
| value | decimal | false | Describes a numeric value (decimal) directly related to the event. This could be the value of an input. For example, `10` when clicking `internal` visibility. |
| context | vector | false | Additional data in the form of a [self-describing JSON](https://docs.snowplow.io/docs/pipeline-components-and-applications/iglu/common-architecture/self-describing-json-schemas/) to describe the event if the attributes are not sufficient. Each context must have its schema defined to assure data integrity. Refer to the list of GitLab-defined contexts for more details. |
### Examples
@ -189,12 +190,12 @@ Snowplow JavaScript adds [web-specific parameters](https://docs.snowplowanalytic
## Related topics
- [Snowplow data structure](https://docs.snowplowanalytics.com/docs/understanding-your-pipeline/canonical-event/)
- [Snowplow data structure](https://docs.snowplow.io/docs/understanding-your-pipeline/canonical-event/)
- [Our Iglu schema registry](https://gitlab.com/gitlab-org/iglu)
- [List of events used in our codebase (Event Dictionary)](https://metrics.gitlab.com/snowplow/)
- [Product Intelligence Guide](https://about.gitlab.com/handbook/product/product-intelligence-guide/)
- [Service Ping Guide](../service_ping/index.md)
- [Product Intelligence Direction](https://about.gitlab.com/direction/product-intelligence/)
- [Product Intelligence Direction](https://about.gitlab.com/direction/analytics/product-intelligence/)
- [Data Analysis Process](https://about.gitlab.com/handbook/business-technology/data-team/#data-analysis-process/)
- [Data for Product Managers](https://about.gitlab.com/handbook/business-technology/data-team/programs/data-for-product-managers/)
- [Data Infrastructure](https://about.gitlab.com/handbook/business-technology/data-team/platform/infrastructure/)

View File

@ -33,8 +33,8 @@ _\* Default value present for frontend events only_
## Default Schema
Frontend events include a [web-specific schema](https://docs.snowplowanalytics.com/docs/understanding-your-pipeline/canonical-event/#Web-specific_fields) provided by Snowplow.
All URLs are pseudonymized. The entity identifier [replaces](https://docs.snowplowanalytics.com/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracker-setup/other-parameters-2/#Setting_a_custom_page_URL_and_referrer_URL) personally identifiable
Frontend events include a [web-specific schema](https://docs.snowplow.io/docs/understanding-your-pipeline/canonical-event/#web-specific-fields) provided by Snowplow.
All URLs are pseudonymized. The entity identifier [replaces](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracker-setup/other-parameters-2/#setting-a-custom-page-url-and-referrer-url) personally identifiable
information (PII). PII includes usernames, group, and project names.
Page titles are hardcoded as `GitLab` for the same reason.
@ -172,3 +172,18 @@ Page titles are hardcoded as `GitLab` for the same reason.
| `v_collector` | **{dotted-circle}** | string | Collector version |
| `v_etl` | **{dotted-circle}** | string | ETL version |
| `v_tracker` | **{dotted-circle}** | string | Identifier for Snowplow tracker |
## `gitlab_service_ping`
Backend events converted from ServicePing (`redis` and `redis_hll`) must include [ServicePing context](https://gitlab.com/gitlab-org/iglu/-/tree/master/public/schemas/com.gitlab/gitlab_service_ping/jsonschema)
using the [helper class](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/tracking/service_ping_context.rb).
An example of converted `redis_hll` [event with context](https://gitlab.com/gitlab-org/gitlab/-/edit/master/app/controllers/concerns/product_analytics_tracking.rb#L58).
| Field Name | Required | Type | Description |
|---------------|:-------------------:|------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `data_source` | **{check-circle}** | string (max 64 chars) | The `data_source` attribute from the metrics YAML definition. |
| `event_name`* | **{dotted-circle}** | string (max 128 chars) | When there is a many-to-many relationship between events and metrics, this field contains the name of a Redis event that can be used for aggregations in downstream systems |
| `key_path`* | **{dotted-circle}** | string (max 256 chars) | The `key_path` attribute from the metrics YAML definition |
_\* Either `event_name` or `key_path` is required_

View File

@ -36,7 +36,7 @@ This is a partial list of the [RSpec metadata](https://relishapp.com/rspec/rspec
| `:only` | The test is only to be run in specific execution contexts. See [test execution context selection](execution_context_selection.md) for more information. |
| `:orchestrated` | The GitLab instance under test may be [configured by `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/what_tests_can_be_run.md#orchestrated-tests) to be different to the default GitLab configuration, or `gitlab-qa` may launch additional services in separate Docker containers, or both. Tests tagged with `:orchestrated` are excluded when testing environments where we can't dynamically modify the GitLab configuration (for example, Staging). |
| `:packages` | The test requires a GitLab instance that has the [Package Registry](../../../administration/packages/index.md#gitlab-package-registry-administration) enabled. |
| `:product_group` | Specifies what product group the test belongs to. See [Product sections, stages, groups, and categories](https://about.gitlab.com/handbook/product/categories) for the comprehensive groups list. |
| `:product_group` | Specifies what product group the test belongs to. See [Product sections, stages, groups, and categories](https://about.gitlab.com/handbook/product/categories/) for the comprehensive groups list. |
| `:quarantine` | The test has been [quarantined](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/debugging-qa-test-failures/#quarantining-tests), runs in a separate job that only includes quarantined tests, and is allowed to fail. The test is skipped in its regular job so that if it fails it doesn't hold up the pipeline. Note that you can also [quarantine a test only when it runs in a specific context](execution_context_selection.md#quarantine-a-test-for-a-specific-environment). |
| `:relative_url` | The test requires a GitLab instance to be installed under a [relative URL](../../../install/relative_url.md). |
| `:reliable` | The test has been [promoted to a reliable test](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/reliable-tests/#promoting-an-existing-test-to-reliable) meaning it passes consistently in all pipelines, including merge requests. |

View File

@ -164,13 +164,17 @@ define these various types in a very flexible manner. Having GitLab use
this system first (without introducing customer customization) allows us to
better build out the initial system.
NOTE:
Currently work item's `base_type` is used to define static mapping of what
Work item's `base_type` is used to define static mapping of what
widgets are available for each type (current status), this definition should be
rather stored in database table. The exact structure of the WIT widgets
metadata is still to be defined. `base_type` was added to help converting other
types of resources (requirements and incidents) into work items. Eventually (when
these resources become regular work items), `base_type` will be removed.
rather stored in a database table. The exact structure of the WIT widgets metadata
is [still to be defined](https://gitlab.com/gitlab-org/gitlab/-/issues/370599).
`base_type` was added to help convert other types of resources (requirements
and incidents) into work items. Eventually (when these resources become regular
work items), `base_type` will be removed.
Until the architecture of WIT widgets is finalized, we are holding off on the creation of new work item
types. If a new work item type is absolutely necessary, please reach out to a
member of the [Project Management Engineering Team](https://gitlab.com/gitlab-org/gitlab/-/issues/370599).
### Custom work item types

View File

@ -83,7 +83,7 @@ In a self-managed instance:
On GitLab SaaS:
- You cannot use internal encryption key for the data store ([bring-your-own-key](https://about.gitlab.com/handbook/engineering/security/vulnerability_management/encryption-policy.html#rolling-your-own-crypto)).
- You cannot use internal encryption key for the data store ([bring-your-own-key](https://about.gitlab.com/handbook/security/threat-management/vulnerability-management/encryption-policy.html#rolling-your-own-crypto)).
- You cannot view console logs.
- You cannot enforce jobs on every pipeline across the group or organization.
- You cannot configure or control data backups. You must use [group](../../api/group_import_export.md) and [project](../../api/project_import_export.md) export.
@ -106,7 +106,7 @@ In a self-managed instance, you control the encryption type and configuration.
On GitLab SaaS:
- An [Access Management Process](https://about.gitlab.com/handbook/engineering/security/#access-management-process) is in place.
- An [Access Management Process](https://about.gitlab.com/handbook/security/#access-management-process) is in place.
- All data on GitLab.com is encrypted at rest by default. Access to encryption keys is strictly managed by GitLab.
- GitLab does not access your tenant data except as part of a verified service request from you.

View File

@ -299,7 +299,7 @@ GitLab supports the following web browsers:
- [Google Chrome](https://www.google.com/chrome/)
- [Chromium](https://www.chromium.org/getting-involved/dev-channel/)
- [Apple Safari](https://www.apple.com/safari/)
- [Microsoft Edge](https://www.microsoft.com/en-us/edge)
- [Microsoft Edge](https://www.microsoft.com/en-us/edge?form=MA13FJ)
For the listed web browsers, GitLab supports:

View File

@ -1,13 +0,0 @@
---
stage: Manage
group: Integrations
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
remove_date: '2022-10-29'
redirect_to: 'jenkins.md'
---
# Jenkins CI service (removed) **(FREE)**
This feature was [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/1600)
in GitLab 13.0.
Use the [Jenkins integration](jenkins.md) instead.

Some files were not shown because too many files have changed in this diff Show More