Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
e4632f4c63
commit
8f016fe5fb
|
|
@ -34,6 +34,9 @@ There are three main sections below. It is a good idea to structure your merge r
|
|||
|
||||
It is also a good idea to first open a proof-of-concept merge request. It can be helpful for working out kinks and getting initial support and feedback from the Geo team. As an example, see the [Proof of Concept to replicate Pipeline Artifacts](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56423).
|
||||
|
||||
You can look into the following example for implementing replication/verification for a new Git repository type:
|
||||
- [Add snippet repository verification](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56596)
|
||||
|
||||
### Modify database schemas to prepare to add Geo support for Cool Widgets
|
||||
|
||||
You might do this section in its own merge request, but it is not required.
|
||||
|
|
@ -350,6 +353,7 @@ That's all of the required database changes.
|
|||
module Geo
|
||||
class CoolWidgetReplicator < Gitlab::Geo::Replicator
|
||||
include ::Geo::RepositoryReplicatorStrategy
|
||||
extend ::Gitlab::Utils::Override
|
||||
|
||||
def self.model
|
||||
::CoolWidget
|
||||
|
|
@ -460,7 +464,7 @@ That's all of the required database changes.
|
|||
|
||||
FactoryBot.define do
|
||||
factory :geo_cool_widget_registry, class: 'Geo::CoolWidgetRegistry' do
|
||||
cool_widget
|
||||
cool_widget # This association should have data, like a file or repository
|
||||
state { Geo::CoolWidgetRegistry.state_value(:pending) }
|
||||
|
||||
trait :synced do
|
||||
|
|
@ -770,6 +774,8 @@ Individual Cool Widget replication and verification data should now be available
|
|||
module Geo
|
||||
class CoolWidgetReplicator < Gitlab::Geo::Replicator
|
||||
...
|
||||
# REMOVE THIS LINE IF IT IS NO LONGER NEEDED
|
||||
extend ::Gitlab::Utils::Override
|
||||
|
||||
# REMOVE THIS METHOD
|
||||
def self.replication_enabled_by_default?
|
||||
|
|
|
|||
|
|
@ -34,6 +34,10 @@ There are three main sections below. It is a good idea to structure your merge r
|
|||
|
||||
It is also a good idea to first open a proof-of-concept merge request. It can be helpful for working out kinks and getting initial support and feedback from the Geo team. As an example, see the [Proof of Concept to replicate Pipeline Artifacts](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56423).
|
||||
|
||||
You can look into the following examples of MRs for implementing replication/verification for a new blob type:
|
||||
- [Add db changes](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60935) and [add verification for MR diffs using SSF](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63309)
|
||||
- [Verify Terraform state versions](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/58800)
|
||||
|
||||
### Modify database schemas to prepare to add Geo support for Cool Widgets
|
||||
|
||||
You might do this section in its own merge request, but it is not required.
|
||||
|
|
@ -339,6 +343,7 @@ That's all of the required database changes.
|
|||
module Geo
|
||||
class CoolWidgetReplicator < Gitlab::Geo::Replicator
|
||||
include ::Geo::BlobReplicatorStrategy
|
||||
extend ::Gitlab::Utils::Override
|
||||
|
||||
def self.model
|
||||
::CoolWidget
|
||||
|
|
@ -426,7 +431,7 @@ That's all of the required database changes.
|
|||
|
||||
FactoryBot.define do
|
||||
factory :geo_cool_widget_registry, class: 'Geo::CoolWidgetRegistry' do
|
||||
cool_widget
|
||||
cool_widget # This association should have data, like a file or repository
|
||||
state { Geo::CoolWidgetRegistry.state_value(:pending) }
|
||||
|
||||
trait :synced do
|
||||
|
|
@ -736,7 +741,10 @@ Individual Cool Widget replication and verification data should now be available
|
|||
module Geo
|
||||
class CoolWidgetReplicator < Gitlab::Geo::Replicator
|
||||
...
|
||||
# REMOVE THIS LINE IF IT IS NO LONGER NEEDED
|
||||
extend ::Gitlab::Utils::Override
|
||||
|
||||
...
|
||||
# REMOVE THIS METHOD
|
||||
def self.replication_enabled_by_default?
|
||||
false
|
||||
|
|
|
|||
2
Gemfile
2
Gemfile
|
|
@ -496,7 +496,7 @@ gem 'flipper', '~> 0.21.0'
|
|||
gem 'flipper-active_record', '~> 0.21.0'
|
||||
gem 'flipper-active_support_cache_store', '~> 0.21.0'
|
||||
gem 'unleash', '~> 0.1.5'
|
||||
gem 'gitlab-experiment', '~> 0.5.4'
|
||||
gem 'gitlab-experiment', '~> 0.6.1'
|
||||
|
||||
# Structured logging
|
||||
gem 'lograge', '~> 0.5'
|
||||
|
|
|
|||
|
|
@ -470,7 +470,7 @@ GEM
|
|||
numerizer (~> 0.2)
|
||||
gitlab-dangerfiles (2.1.2)
|
||||
danger-gitlab
|
||||
gitlab-experiment (0.5.4)
|
||||
gitlab-experiment (0.6.1)
|
||||
activesupport (>= 3.0)
|
||||
request_store (>= 1.0)
|
||||
scientist (~> 1.6, >= 1.6.0)
|
||||
|
|
@ -1487,7 +1487,7 @@ DEPENDENCIES
|
|||
github-markup (~> 1.7.0)
|
||||
gitlab-chronic (~> 0.10.5)
|
||||
gitlab-dangerfiles (~> 2.1.2)
|
||||
gitlab-experiment (~> 0.5.4)
|
||||
gitlab-experiment (~> 0.6.1)
|
||||
gitlab-fog-azure-rm (~> 1.1.1)
|
||||
gitlab-labkit (~> 0.18.0)
|
||||
gitlab-license (~> 1.5)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,28 @@
|
|||
<script>
|
||||
import { s__, n__, sprintf } from '~/locale';
|
||||
|
||||
export default {
|
||||
props: {
|
||||
stageCount: {
|
||||
type: Number,
|
||||
required: false,
|
||||
default: null,
|
||||
},
|
||||
},
|
||||
computed: {
|
||||
formattedStageCount() {
|
||||
if (!this.stageCount) {
|
||||
return '-';
|
||||
} else if (this.stageCount > 1000) {
|
||||
return sprintf(s__('ValueStreamAnalytics|%{stageCount} items'), { stageCount: '1000+' });
|
||||
}
|
||||
|
||||
return n__('%d item', '%d items', this.stageCount);
|
||||
},
|
||||
},
|
||||
};
|
||||
</script>
|
||||
|
||||
<template>
|
||||
<span>{{ formattedStageCount }}</span>
|
||||
</template>
|
||||
|
|
@ -7,6 +7,7 @@ import {
|
|||
} from '@gitlab/ui';
|
||||
import Tracking from '~/tracking';
|
||||
import { OVERVIEW_STAGE_ID } from '../constants';
|
||||
import FormattedStageCount from './formatted_stage_count.vue';
|
||||
|
||||
export default {
|
||||
name: 'PathNavigation',
|
||||
|
|
@ -14,6 +15,7 @@ export default {
|
|||
GlPath,
|
||||
GlSkeletonLoading,
|
||||
GlPopover,
|
||||
FormattedStageCount,
|
||||
},
|
||||
directives: {
|
||||
SafeHtml,
|
||||
|
|
@ -88,10 +90,7 @@ export default {
|
|||
{{ s__('ValueStreamEvent|Items in stage') }}
|
||||
</div>
|
||||
<div class="gl-pb-4 gl-font-weight-bold">
|
||||
<template v-if="hasStageCount(pathItem)">{{
|
||||
n__('%d item', '%d items', pathItem.stageCount)
|
||||
}}</template>
|
||||
<template v-else>-</template>
|
||||
<formatted-stage-count :stage-count="pathItem.stageCount" />
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ fragment ReleaseForEditing on Release {
|
|||
name
|
||||
url
|
||||
linkType
|
||||
directAssetPath
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -165,6 +165,7 @@ const createReleaseLink = async ({ state, link }) => {
|
|||
name: link.name,
|
||||
url: link.url,
|
||||
linkType: link.linkType.toUpperCase(),
|
||||
directAssetPath: link.directAssetPath,
|
||||
},
|
||||
},
|
||||
});
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@ const index = function index() {
|
|||
release: gon.revision,
|
||||
tags: {
|
||||
revision: gon.revision,
|
||||
feature_category: gon.feature_category,
|
||||
},
|
||||
});
|
||||
|
||||
|
|
|
|||
|
|
@ -59,16 +59,18 @@ const SentryConfig = {
|
|||
|
||||
configure() {
|
||||
const { dsn, release, tags, whitelistUrls, environment } = this.options;
|
||||
|
||||
Sentry.init({
|
||||
dsn,
|
||||
release,
|
||||
tags,
|
||||
whitelistUrls,
|
||||
environment,
|
||||
ignoreErrors: this.IGNORE_ERRORS, // TODO: Remove in favor of https://gitlab.com/gitlab-org/gitlab/issues/35144
|
||||
blacklistUrls: this.BLACKLIST_URLS,
|
||||
sampleRate: SAMPLE_RATE,
|
||||
});
|
||||
|
||||
Sentry.setTags(tags);
|
||||
},
|
||||
|
||||
setUser() {
|
||||
|
|
|
|||
|
|
@ -65,15 +65,32 @@ $status-box-line-height: 26px;
|
|||
line-height: $line-height-base;
|
||||
padding: 14px 16px;
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
|
||||
.title {
|
||||
flex: 1;
|
||||
flex-grow: 2;
|
||||
}
|
||||
|
||||
.counter {
|
||||
flex: 0;
|
||||
padding-left: 16px;
|
||||
.issuable-count-weight {
|
||||
white-space: nowrap;
|
||||
|
||||
.counter,
|
||||
.weight {
|
||||
color: var(--gray-500, $gray-500);
|
||||
font-weight: $gl-font-weight-bold;
|
||||
}
|
||||
}
|
||||
|
||||
&.text-white {
|
||||
.issuable-count-weight svg {
|
||||
fill: $white;
|
||||
}
|
||||
|
||||
.issuable-count-weight .counter,
|
||||
.weight {
|
||||
color: var(--white, $white);
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -10,22 +10,28 @@ class ApplicationExperiment < Gitlab::Experiment # rubocop:disable Gitlab/Namesp
|
|||
end
|
||||
|
||||
def publish(_result = nil)
|
||||
return unless should_track? # don't track events for excluded contexts
|
||||
super
|
||||
|
||||
record_experiment if @record # record the subject in the database if the context contains a namespace, group, project, actor or user
|
||||
|
||||
track(:assignment) # track that we've assigned a variant for this context
|
||||
|
||||
push_to_client
|
||||
publish_to_client if should_track? # publish the experiment data to the client
|
||||
publish_to_database if @record # publish the experiment context to the database
|
||||
end
|
||||
|
||||
# push the experiment data to the client
|
||||
def push_to_client
|
||||
def publish_to_client
|
||||
Gon.push({ experiment: { name => signature } }, true)
|
||||
rescue NoMethodError
|
||||
# means we're not in the request cycle, and can't add to Gon. Log a warning maybe?
|
||||
end
|
||||
|
||||
def publish_to_database
|
||||
# if the context contains a namespace, group, project, user, or actor
|
||||
value = context.value
|
||||
subject = value[:namespace] || value[:group] || value[:project] || value[:user] || value[:actor]
|
||||
return unless ExperimentSubject.valid_subject?(subject)
|
||||
|
||||
variant = :experimental if @variant_name != :control
|
||||
Experiment.add_subject(name, variant: variant || :control, subject: subject)
|
||||
end
|
||||
|
||||
def track(action, **event_args)
|
||||
return unless should_track? # don't track events for excluded contexts
|
||||
|
||||
|
|
@ -41,14 +47,23 @@ class ApplicationExperiment < Gitlab::Experiment # rubocop:disable Gitlab/Namesp
|
|||
@record = true
|
||||
end
|
||||
|
||||
def exclude!
|
||||
@excluded = true
|
||||
end
|
||||
|
||||
def control_behavior
|
||||
# define a default nil control behavior so we can omit it when not needed
|
||||
end
|
||||
|
||||
# TODO: remove
|
||||
# This is deprecated logic as of v0.6.0 and should eventually be removed, but
|
||||
# needs to stay intact for actively running experiments. The new strategy
|
||||
# utilizes Digest::SHA2, a secret seed, and generates a 64-byte string.
|
||||
def key_for(source, seed = name)
|
||||
source = source.keys + source.values if source.is_a?(Hash)
|
||||
|
||||
ingredients = Array(source).map { |v| identify(v) }
|
||||
ingredients.unshift(seed)
|
||||
|
||||
Digest::MD5.hexdigest(ingredients.join('|'))
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
def feature_flag_name
|
||||
|
|
@ -58,13 +73,4 @@ class ApplicationExperiment < Gitlab::Experiment # rubocop:disable Gitlab/Namesp
|
|||
def experiment_group?
|
||||
Feature.enabled?(feature_flag_name, self, type: :experiment, default_enabled: :yaml)
|
||||
end
|
||||
|
||||
def record_experiment
|
||||
subject = context.value[:namespace] || context.value[:group] || context.value[:project] || context.value[:user] || context.value[:actor]
|
||||
return unless ExperimentSubject.valid_subject?(subject)
|
||||
|
||||
variant = :experimental if @variant_name != :control
|
||||
|
||||
Experiment.add_subject(name, variant: variant || :control, subject: subject)
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -20,6 +20,8 @@ module Types
|
|||
|
||||
field :direct_asset_url, GraphQL::STRING_TYPE, null: true,
|
||||
description: 'Direct asset URL of the link.'
|
||||
field :direct_asset_path, GraphQL::STRING_TYPE, null: true, method: :filepath,
|
||||
description: 'Relative path for the direct asset link.'
|
||||
|
||||
def direct_asset_url
|
||||
return object.url unless object.filepath
|
||||
|
|
|
|||
|
|
@ -16,6 +16,10 @@ module Types
|
|||
description: 'Blob plain highlighted data.',
|
||||
null: true
|
||||
|
||||
field :raw_plain_data, GraphQL::STRING_TYPE,
|
||||
description: 'The raw content of the blob, if the blob is text data.',
|
||||
null: true
|
||||
|
||||
field :raw_path, GraphQL::STRING_TYPE,
|
||||
description: 'Blob raw content endpoint path.',
|
||||
null: false
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module Ci
|
||||
# TODO: https://gitlab.com/groups/gitlab-org/-/epics/6168
|
||||
#
|
||||
# Do not use this yet outside of `ci_instance_variables`.
|
||||
# This class is part of a migration to move all CI classes to a new separate database.
|
||||
# Initially we are only going to be moving the `Ci::InstanceVariable` model and it will be duplicated in the main and CI tables
|
||||
# Do not extend this class in any other models.
|
||||
class ApplicationRecord < ::ApplicationRecord
|
||||
self.abstract_class = true
|
||||
|
||||
if Gitlab::Database.has_config?(:ci)
|
||||
connects_to database: { writing: :ci, reading: :ci }
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module Ci
|
||||
class InstanceVariable < ApplicationRecord
|
||||
class InstanceVariable < ::Ci::ApplicationRecord
|
||||
extend Gitlab::Ci::Model
|
||||
extend Gitlab::ProcessMemoryCache::Helper
|
||||
include Ci::NewHasVariable
|
||||
|
|
|
|||
|
|
@ -163,9 +163,9 @@ module CacheMarkdownField
|
|||
refs = all_references(self.author)
|
||||
|
||||
references = {}
|
||||
references[:mentioned_users_ids] = refs.mentioned_users&.pluck(:id).presence
|
||||
references[:mentioned_groups_ids] = refs.mentioned_groups&.pluck(:id).presence
|
||||
references[:mentioned_projects_ids] = refs.mentioned_projects&.pluck(:id).presence
|
||||
references[:mentioned_users_ids] = refs.mentioned_user_ids.presence
|
||||
references[:mentioned_groups_ids] = refs.mentioned_group_ids.presence
|
||||
references[:mentioned_projects_ids] = refs.mentioned_project_ids.presence
|
||||
|
||||
# One retry is enough as next time `model_user_mention` should return the existing mention record,
|
||||
# that threw the `ActiveRecord::RecordNotUnique` exception in first place.
|
||||
|
|
|
|||
|
|
@ -26,6 +26,10 @@ class BlobPresenter < Gitlab::View::Presenter::Delegated
|
|||
highlight(plain: false)
|
||||
end
|
||||
|
||||
def raw_plain_data
|
||||
blob.data unless blob.binary?
|
||||
end
|
||||
|
||||
def web_url
|
||||
url_helpers.project_blob_url(project, ref_qualified_path)
|
||||
end
|
||||
|
|
|
|||
|
|
@ -17,6 +17,10 @@ class SnippetBlobPresenter < BlobPresenter
|
|||
snippet_blob_raw_route
|
||||
end
|
||||
|
||||
def raw_plain_data
|
||||
blob.data unless blob.binary?
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
def snippet
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@
|
|||
= build_summary(build)
|
||||
|
||||
#js-tab-dag.tab-pane
|
||||
#js-pipeline-dag-vue{ data: { pipeline_project_path: @project.full_path, pipeline_iid: @pipeline.iid, empty_svg_path: image_path('illustrations/empty-state/empty-dag-md.svg'), about_dag_doc_path: help_page_path('ci/directed_acyclic_graph/index.md'), dag_doc_path: help_page_path('ci/yaml/README.md', anchor: 'needs')} }
|
||||
#js-pipeline-dag-vue{ data: { pipeline_project_path: @project.full_path, pipeline_iid: @pipeline.iid, empty_svg_path: image_path('illustrations/empty-state/empty-dag-md.svg'), about_dag_doc_path: help_page_path('ci/directed_acyclic_graph/index.md'), dag_doc_path: help_page_path('ci/yaml/index.md', anchor: 'needs')} }
|
||||
|
||||
#js-tab-tests.tab-pane
|
||||
#js-pipeline-tests-detail{ data: { summary_endpoint: summary_project_pipeline_tests_path(@project, @pipeline, format: :json),
|
||||
|
|
|
|||
|
|
@ -1,8 +1,10 @@
|
|||
- if cookies[:hide_project_limit_message].blank? && !current_user.hide_project_limit && !current_user.can_create_project? && current_user.projects_limit > 0
|
||||
.project-limit-message.gl-alert.gl-alert-warning.gl-display-none.gl-sm-display-block
|
||||
= _("You won't be able to create new projects because you have reached your project limit.")
|
||||
|
||||
.float-right
|
||||
= link_to _("Don't show again"), profile_path(user: {hide_project_limit: true}), method: :put, class: 'alert-link'
|
||||
|
|
||||
= link_to _('Remind later'), '#', class: 'hide-project-limit-message alert-link'
|
||||
= render 'shared/global_alert',
|
||||
variant: :warning,
|
||||
dismissible: false,
|
||||
alert_class: 'project-limit-message' do
|
||||
.gl-alert-body
|
||||
= _("You won't be able to create new projects because you have reached your project limit.")
|
||||
.gl-alert-actions
|
||||
= link_to _('Remind later'), '#', class: 'alert-link hide-project-limit-message btn gl-button btn-confirm'
|
||||
= link_to _("Don't show again"), profile_path(user: {hide_project_limit: true}), method: :put, class: 'alert-link btn gl-button btn-default gl-ml-3'
|
||||
|
|
|
|||
|
|
@ -25,3 +25,5 @@
|
|||
= link_to polymorphic_path(issuable_type_args, { milestone_title: @milestone.title, assignee_id: assignee.id, state: 'all' }),
|
||||
class: 'has-tooltip', title: _("Assigned to %{assignee_name}") % { assignee_name: assignee.name }, data: { container: 'body' } do
|
||||
- image_tag(avatar_icon_for_user(assignee, 16), class: "avatar s16", alt: '')
|
||||
|
||||
= render_if_exists "shared/milestones/issuable_weight", issuable: issuable
|
||||
|
|
|
|||
|
|
@ -4,11 +4,15 @@
|
|||
|
||||
.card
|
||||
.card-header{ class: panel_class }
|
||||
.title
|
||||
= title
|
||||
- if show_counter
|
||||
.counter
|
||||
= number_with_delimiter(issuables.length)
|
||||
.header.gl-mb-2
|
||||
.title
|
||||
= title
|
||||
.issuable-count-weight.gl-ml-3
|
||||
- if show_counter
|
||||
%span.counter
|
||||
= sprite_icon('issues', css_class: 'gl-vertical-align-text-bottom')
|
||||
= number_with_delimiter(issuables.length)
|
||||
= render_if_exists "shared/milestones/issuables_weight", issuables: issuables
|
||||
|
||||
- class_prefix = dom_class(issuables).pluralize
|
||||
%ul{ class: "content-list milestone-#{class_prefix}-list", id: "#{class_prefix}-list-#{id}" }
|
||||
|
|
|
|||
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
name: gitlab_experiment_middleware
|
||||
introduced_by_url:
|
||||
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/323643
|
||||
milestone: '14.1'
|
||||
type: development
|
||||
group: group::adoption
|
||||
default_enabled: false
|
||||
|
|
@ -1,5 +1,8 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
# Because we use Gitlab::Database, which in turn uses prepend_mod_with,
|
||||
# we need this intializer to be after config/initializers/0_inject_enterprise_edition_module.rb.
|
||||
|
||||
# Post deployment migrations are included by default. This file must be loaded
|
||||
# before other initializers as Rails may otherwise memoize a list of migrations
|
||||
# excluding the post deployment migrations.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
ci_db_config = Gitlab::Application.config.database_configuration[Rails.env]["ci"]
|
||||
|
||||
if ci_db_config.present?
|
||||
raise "migrations_paths setting for ci database must be `db/ci_migrate`" unless ci_db_config["migrations_paths"] == 'db/ci_migrate'
|
||||
end
|
||||
|
|
@ -2,16 +2,22 @@
|
|||
|
||||
Gitlab::Experiment.configure do |config|
|
||||
config.base_class = 'ApplicationExperiment'
|
||||
config.mount_at = '/-/experiment'
|
||||
config.cache = Gitlab::Experiment::Cache::RedisHashStore.new(
|
||||
pool: ->(&block) { Gitlab::Redis::SharedState.with { |redis| block.call(redis) } }
|
||||
)
|
||||
end
|
||||
|
||||
# TODO: This will be deprecated as of v0.6.0, but needs to stay intact for
|
||||
# actively running experiments until a versioning concept is put in place to
|
||||
# enable migrating into the new SHA2 strategy.
|
||||
config.context_hash_strategy = lambda do |source, seed|
|
||||
source = source.keys + source.values if source.is_a?(Hash)
|
||||
data = Array(source).map { |v| (v.respond_to?(:to_global_id) ? v.to_global_id : v).to_s }
|
||||
Digest::MD5.hexdigest(data.unshift(seed).join('|'))
|
||||
# TODO: This shim should be removed after the feature flag is rolled out, as
|
||||
# it only exists to facilitate the feature flag control of the behavior.
|
||||
module Gitlab::Experiment::MiddlewareWithFeatureFlags
|
||||
attr_reader :app
|
||||
|
||||
def call(env)
|
||||
return app.call(env) unless Feature.enabled?(:gitlab_experiment_middleware)
|
||||
|
||||
super
|
||||
end
|
||||
end
|
||||
|
||||
Gitlab::Experiment::Middleware.prepend(Gitlab::Experiment::MiddlewareWithFeatureFlags)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,31 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class CreateCiInstanceVariablesOnCi < ActiveRecord::Migration[6.1]
|
||||
include Gitlab::Database::MigrationHelpers
|
||||
|
||||
disable_ddl_transaction!
|
||||
|
||||
def up
|
||||
unless table_exists?(:ci_instance_variables)
|
||||
create_table :ci_instance_variables do |t|
|
||||
t.integer :variable_type, null: false, limit: 2, default: 1
|
||||
t.boolean :masked, default: false, allow_null: false
|
||||
t.boolean :protected, default: false, allow_null: false
|
||||
t.text :key, null: false
|
||||
t.text :encrypted_value
|
||||
t.text :encrypted_value_iv
|
||||
|
||||
t.index [:key], name: 'index_ci_instance_variables_on_key', unique: true, using: :btree
|
||||
end
|
||||
end
|
||||
|
||||
add_text_limit(:ci_instance_variables, :key, 255)
|
||||
# Use constraint_name generated from db/migrate/20200625193358_increase_size_on_instance_level_variable_values.rb
|
||||
add_text_limit(:ci_instance_variables, :encrypted_value, 13_579, constraint_name: 'check_956afd70f1')
|
||||
add_text_limit(:ci_instance_variables, :encrypted_value_iv, 255)
|
||||
end
|
||||
|
||||
def down
|
||||
drop_table :ci_instance_variables
|
||||
end
|
||||
end
|
||||
|
|
@ -0,0 +1,121 @@
|
|||
SET statement_timeout = 0;
|
||||
SET lock_timeout = 0;
|
||||
SET idle_in_transaction_session_timeout = 0;
|
||||
SET client_encoding = 'UTF8';
|
||||
SET standard_conforming_strings = on;
|
||||
SELECT pg_catalog.set_config('search_path', '', false);
|
||||
SET check_function_bodies = false;
|
||||
SET xmloption = content;
|
||||
SET client_min_messages = warning;
|
||||
SET row_security = off;
|
||||
|
||||
SET default_tablespace = '';
|
||||
|
||||
SET default_table_access_method = heap;
|
||||
|
||||
--
|
||||
-- Name: ar_internal_metadata; Type: TABLE; Schema: public; Owner: -
|
||||
--
|
||||
|
||||
CREATE TABLE public.ar_internal_metadata (
|
||||
key character varying NOT NULL,
|
||||
value character varying,
|
||||
created_at timestamp(6) without time zone NOT NULL,
|
||||
updated_at timestamp(6) without time zone NOT NULL
|
||||
);
|
||||
|
||||
|
||||
--
|
||||
-- Name: ci_instance_variables; Type: TABLE; Schema: public; Owner: -
|
||||
--
|
||||
|
||||
CREATE TABLE public.ci_instance_variables (
|
||||
id bigint NOT NULL,
|
||||
variable_type smallint DEFAULT 1 NOT NULL,
|
||||
masked boolean DEFAULT false,
|
||||
protected boolean DEFAULT false,
|
||||
key text NOT NULL,
|
||||
encrypted_value text,
|
||||
encrypted_value_iv text,
|
||||
CONSTRAINT check_07a45a5bcb CHECK ((char_length(encrypted_value_iv) <= 255)),
|
||||
CONSTRAINT check_5aede12208 CHECK ((char_length(key) <= 255)),
|
||||
CONSTRAINT check_956afd70f1 CHECK ((char_length(encrypted_value) <= 13579))
|
||||
);
|
||||
|
||||
|
||||
--
|
||||
-- Name: ci_instance_variables_id_seq; Type: SEQUENCE; Schema: public; Owner: -
|
||||
--
|
||||
|
||||
CREATE SEQUENCE public.ci_instance_variables_id_seq
|
||||
START WITH 1
|
||||
INCREMENT BY 1
|
||||
NO MINVALUE
|
||||
NO MAXVALUE
|
||||
CACHE 1;
|
||||
|
||||
|
||||
--
|
||||
-- Name: ci_instance_variables_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: -
|
||||
--
|
||||
|
||||
ALTER SEQUENCE public.ci_instance_variables_id_seq OWNED BY public.ci_instance_variables.id;
|
||||
|
||||
|
||||
--
|
||||
-- Name: schema_migrations; Type: TABLE; Schema: public; Owner: -
|
||||
--
|
||||
|
||||
CREATE TABLE public.schema_migrations (
|
||||
version character varying NOT NULL
|
||||
);
|
||||
|
||||
|
||||
--
|
||||
-- Name: ci_instance_variables id; Type: DEFAULT; Schema: public; Owner: -
|
||||
--
|
||||
|
||||
ALTER TABLE ONLY public.ci_instance_variables ALTER COLUMN id SET DEFAULT nextval('public.ci_instance_variables_id_seq'::regclass);
|
||||
|
||||
|
||||
--
|
||||
-- Name: ar_internal_metadata ar_internal_metadata_pkey; Type: CONSTRAINT; Schema: public; Owner: -
|
||||
--
|
||||
|
||||
ALTER TABLE ONLY public.ar_internal_metadata
|
||||
ADD CONSTRAINT ar_internal_metadata_pkey PRIMARY KEY (key);
|
||||
|
||||
|
||||
--
|
||||
-- Name: ci_instance_variables ci_instance_variables_pkey; Type: CONSTRAINT; Schema: public; Owner: -
|
||||
--
|
||||
|
||||
ALTER TABLE ONLY public.ci_instance_variables
|
||||
ADD CONSTRAINT ci_instance_variables_pkey PRIMARY KEY (id);
|
||||
|
||||
|
||||
--
|
||||
-- Name: schema_migrations schema_migrations_pkey; Type: CONSTRAINT; Schema: public; Owner: -
|
||||
--
|
||||
|
||||
ALTER TABLE ONLY public.schema_migrations
|
||||
ADD CONSTRAINT schema_migrations_pkey PRIMARY KEY (version);
|
||||
|
||||
|
||||
--
|
||||
-- Name: index_ci_instance_variables_on_key; Type: INDEX; Schema: public; Owner: -
|
||||
--
|
||||
|
||||
CREATE UNIQUE INDEX index_ci_instance_variables_on_key ON public.ci_instance_variables USING btree (key);
|
||||
|
||||
|
||||
--
|
||||
-- PostgreSQL database dump complete
|
||||
--
|
||||
|
||||
SET search_path TO "$user", public;
|
||||
|
||||
INSERT INTO "schema_migrations" (version) VALUES
|
||||
('20210617101848');
|
||||
|
||||
|
||||
|
|
@ -120,6 +120,7 @@ From there, you can see the following actions:
|
|||
- Project access token was successfully created or revoked ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/230007) in GitLab 13.9)
|
||||
- Failed attempt to create or revoke a project access token ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/230007) in GitLab 13.9)
|
||||
- When default branch changes for a project ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/52339) in GitLab 13.9)
|
||||
- Created, updated, or deleted DAST profiles, DAST scanner profiles, and DAST site profiles ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217872))
|
||||
|
||||
Project events can also be accessed via the [Project Audit Events API](../api/audit_events.md#project-audit-events).
|
||||
|
||||
|
|
|
|||
|
|
@ -192,7 +192,7 @@ The number of pipelines that can be created in a single push is 4.
|
|||
This is to prevent the accidental creation of pipelines when `git push --all`
|
||||
or `git push --mirror` is used.
|
||||
|
||||
Read more in the [CI documentation](../ci/yaml/README.md#processing-git-pushes).
|
||||
Read more in the [CI documentation](../ci/yaml/index.md#processing-git-pushes).
|
||||
|
||||
## Retention of activity history
|
||||
|
||||
|
|
@ -407,7 +407,7 @@ Plan.default.actual_limits.update!(ci_instance_level_variables: 30)
|
|||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37226) in GitLab 13.3.
|
||||
|
||||
Job artifacts defined with [`artifacts:reports`](../ci/yaml/README.md#artifactsreports)
|
||||
Job artifacts defined with [`artifacts:reports`](../ci/yaml/index.md#artifactsreports)
|
||||
that are uploaded by the runner are rejected if the file size exceeds the maximum
|
||||
file size limit. The limit is determined by comparing the project's
|
||||
[maximum artifact size setting](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size)
|
||||
|
|
@ -576,7 +576,7 @@ prevent any more changes from rendering. For more information about these limits
|
|||
Reports that go over the 20 MB limit won't be loaded. Affected reports:
|
||||
|
||||
- [Merge request security reports](../user/project/merge_requests/testing_and_reports_in_merge_requests.md#security-reports)
|
||||
- [CI/CD parameter `artifacts:expose_as`](../ci/yaml/README.md#artifactsexpose_as)
|
||||
- [CI/CD parameter `artifacts:expose_as`](../ci/yaml/index.md#artifactsexpose_as)
|
||||
- [Unit test reports](../ci/unit_test_reports.md)
|
||||
|
||||
## Advanced Search limits
|
||||
|
|
|
|||
|
|
@ -42,10 +42,10 @@ To disable artifacts site-wide, follow the steps below.
|
|||
|
||||
GitLab Runner can upload an archive containing the job artifacts to GitLab. By default,
|
||||
this is done when the job succeeds, but can also be done on failure, or always, via the
|
||||
[`artifacts:when`](../ci/yaml/README.md#artifactswhen) parameter.
|
||||
[`artifacts:when`](../ci/yaml/index.md#artifactswhen) parameter.
|
||||
|
||||
Most artifacts are compressed by GitLab Runner before being sent to the coordinator. The exception to this is
|
||||
[reports artifacts](../ci/yaml/README.md#artifactsreports), which are compressed after uploading.
|
||||
[reports artifacts](../ci/yaml/index.md#artifactsreports), which are compressed after uploading.
|
||||
|
||||
### Using local storage
|
||||
|
||||
|
|
@ -326,7 +326,7 @@ To migrate back to local storage:
|
|||
|
||||
## Expiring artifacts
|
||||
|
||||
If [`artifacts:expire_in`](../ci/yaml/README.md#artifactsexpire_in) is used to set
|
||||
If [`artifacts:expire_in`](../ci/yaml/index.md#artifactsexpire_in) is used to set
|
||||
an expiry for the artifacts, they are marked for deletion right after that date passes.
|
||||
Otherwise, they expire per the [default artifacts expiration setting](../user/admin_area/settings/continuous_integration.md).
|
||||
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ See "Phase 4: uploading" in [Data flow](#data-flow) to learn about the process.
|
|||
If you want to avoid any local disk usage for job logs,
|
||||
you can do so using one of the following options:
|
||||
|
||||
- Enable the [beta incremental logging](#incremental-logging-architecture) feature.
|
||||
- Enable the [incremental logging](#incremental-logging-architecture) feature.
|
||||
- Set the [job logs location](#changing-the-job-logs-local-location)
|
||||
to an NFS drive.
|
||||
|
||||
|
|
@ -140,7 +140,7 @@ For more information, see [delete references to missing artifacts](raketasks/che
|
|||
> - [Recommended for production use with AWS S3](https://gitlab.com/gitlab-org/gitlab/-/issues/273498) in GitLab 13.7.
|
||||
> - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-incremental-logging). **(FREE SELF)**
|
||||
|
||||
Job logs are sent from the GitLab Runner in chunks and cached temporarily on disk
|
||||
By default job logs are sent from the GitLab Runner in chunks and cached temporarily on disk
|
||||
in `/var/opt/gitlab/gitlab-ci/builds` by Omnibus GitLab. After the job completes,
|
||||
a background job archives the job log. The log is moved to `/var/opt/gitlab/gitlab-rails/shared/artifacts/`
|
||||
by default, or to object storage if configured.
|
||||
|
|
@ -150,7 +150,7 @@ server, these two locations on the filesystem have to be shared using NFS.
|
|||
|
||||
To eliminate both filesystem requirements:
|
||||
|
||||
- Enable the incremental logging feature, which uses Redis instead of disk space for temporary caching of job logs.
|
||||
- [Enable the incremental logging feature](#enable-or-disable-incremental-logging), which uses Redis instead of disk space for temporary caching of job logs.
|
||||
- Configure [object storage](job_artifacts.md#object-storage-settings) for storing archived job logs.
|
||||
|
||||
### Technical details
|
||||
|
|
@ -185,7 +185,7 @@ Here is the detailed data flow:
|
|||
|
||||
### Enable or disable incremental logging **(FREE SELF)**
|
||||
|
||||
Incremental logging is under development, but ready for production use. It is
|
||||
Incremental logging is under development, but [ready for production use as of GitLab 13.6](https://gitlab.com/groups/gitlab-org/-/epics/4275). It is
|
||||
deployed behind a feature flag that is **disabled by default**.
|
||||
[GitLab administrators with access to the GitLab Rails console](feature_flags.md)
|
||||
can enable it.
|
||||
|
|
|
|||
|
|
@ -591,12 +591,6 @@ with the Fog library that GitLab uses. Symptoms include an error in `production.
|
|||
411 Length Required
|
||||
```
|
||||
|
||||
### Incremental logging is required for CI to use object storage
|
||||
|
||||
If you configure GitLab to use object storage for CI logs and artifacts,
|
||||
you can avoid [local disk usage for job logs](job_logs.md#data-flow) by enabling
|
||||
[beta incremental logging](job_logs.md#incremental-logging-architecture).
|
||||
|
||||
### Proxy Download
|
||||
|
||||
Clients can download files in object storage by receiving a pre-signed, time-limited URL,
|
||||
|
|
|
|||
|
|
@ -638,8 +638,8 @@ GET /projects/:id/repository/commits/:sha/statuses
|
|||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) owned by the authenticated user
|
||||
| `sha` | string | yes | The commit SHA
|
||||
| `ref` | string | no | The name of a repository branch or tag or, if not given, the default branch
|
||||
| `stage` | string | no | Filter by [build stage](../ci/yaml/README.md#stages), e.g., `test`
|
||||
| `name` | string | no | Filter by [job name](../ci/yaml/README.md#job-keywords), e.g., `bundler:audit`
|
||||
| `stage` | string | no | Filter by [build stage](../ci/yaml/index.md#stages), e.g., `test`
|
||||
| `name` | string | no | Filter by [job name](../ci/yaml/index.md#job-keywords), e.g., `bundler:audit`
|
||||
| `all` | boolean | no | Return all statuses, not only the latest ones
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -3631,6 +3631,25 @@ Input type: `SecurityPolicyProjectAssignInput`
|
|||
| <a id="mutationsecuritypolicyprojectassignclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
|
||||
| <a id="mutationsecuritypolicyprojectassignerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
|
||||
|
||||
### `Mutation.securityPolicyProjectCreate`
|
||||
|
||||
Input type: `SecurityPolicyProjectCreateInput`
|
||||
|
||||
#### Arguments
|
||||
|
||||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="mutationsecuritypolicyprojectcreateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
|
||||
| <a id="mutationsecuritypolicyprojectcreateprojectpath"></a>`projectPath` | [`ID!`](#id) | Full path of the project. |
|
||||
|
||||
#### Fields
|
||||
|
||||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="mutationsecuritypolicyprojectcreateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
|
||||
| <a id="mutationsecuritypolicyprojectcreateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
|
||||
| <a id="mutationsecuritypolicyprojectcreateproject"></a>`project` | [`Project`](#project) | Security Policy Project that was created. |
|
||||
|
||||
### `Mutation.terraformStateDelete`
|
||||
|
||||
Input type: `TerraformStateDeleteInput`
|
||||
|
|
@ -12240,6 +12259,7 @@ Represents an asset link associated with a release.
|
|||
|
||||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="releaseassetlinkdirectassetpath"></a>`directAssetPath` | [`String`](#string) | Relative path for the direct asset link. |
|
||||
| <a id="releaseassetlinkdirectasseturl"></a>`directAssetUrl` | [`String`](#string) | Direct asset URL of the link. |
|
||||
| <a id="releaseassetlinkexternal"></a>`external` | [`Boolean`](#boolean) | Indicates the link points to an external resource. |
|
||||
| <a id="releaseassetlinkid"></a>`id` | [`ID!`](#id) | ID of the link. |
|
||||
|
|
@ -12861,6 +12881,7 @@ Represents the snippet blob.
|
|||
| <a id="snippetblobpath"></a>`path` | [`String`](#string) | Blob path. |
|
||||
| <a id="snippetblobplaindata"></a>`plainData` | [`String`](#string) | Blob plain highlighted data. |
|
||||
| <a id="snippetblobrawpath"></a>`rawPath` | [`String!`](#string) | Blob raw content endpoint path. |
|
||||
| <a id="snippetblobrawplaindata"></a>`rawPlainData` | [`String`](#string) | The raw content of the blob, if the blob is text data. |
|
||||
| <a id="snippetblobrenderedastext"></a>`renderedAsText` | [`Boolean!`](#boolean) | Shows whether the blob is rendered as text. |
|
||||
| <a id="snippetblobrichdata"></a>`richData` | [`String`](#string) | Blob highlighted data. |
|
||||
| <a id="snippetblobrichviewer"></a>`richViewer` | [`SnippetBlobViewer`](#snippetblobviewer) | Blob content rich viewer. |
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Example request using the `PRIVATE-TOKEN` header:
|
|||
curl --output artifacts.zip --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/42/artifacts"
|
||||
```
|
||||
|
||||
To use this in a [`script` definition](../ci/yaml/README.md#script) inside
|
||||
To use this in a [`script` definition](../ci/yaml/index.md#script) inside
|
||||
`.gitlab-ci.yml` **(PREMIUM)**, you can use either:
|
||||
|
||||
- The `JOB-TOKEN` header with the GitLab-provided `CI_JOB_TOKEN` variable.
|
||||
|
|
@ -93,7 +93,7 @@ Example request using the `PRIVATE-TOKEN` header:
|
|||
curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/main/download?job=test"
|
||||
```
|
||||
|
||||
To use this in a [`script` definition](../ci/yaml/README.md#script) inside
|
||||
To use this in a [`script` definition](../ci/yaml/index.md#script) inside
|
||||
`.gitlab-ci.yml` **(PREMIUM)**, you can use either:
|
||||
|
||||
- The `JOB-TOKEN` header with the GitLab-provided `CI_JOB_TOKEN` variable.
|
||||
|
|
|
|||
|
|
@ -87,8 +87,8 @@ Example responses:
|
|||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29568) in GitLab 13.5.
|
||||
|
||||
The CI lint returns an expanded version of the configuration. The expansion does not
|
||||
work for CI configuration added with [`include: local`](../ci/yaml/README.md#includelocal),
|
||||
or with [`extends:`](../ci/yaml/README.md#extends).
|
||||
work for CI configuration added with [`include: local`](../ci/yaml/index.md#includelocal),
|
||||
or with [`extends:`](../ci/yaml/index.md#extends).
|
||||
|
||||
Example contents of a `.gitlab-ci.yml` passed to the CI Lint API with
|
||||
`include_merged_yaml` set as true:
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ type: reference
|
|||
|
||||
In GitLab, there is an API endpoint available to work with GitLab CI/CD YMLs. For more
|
||||
information on CI/CD pipeline configuration in GitLab, see the
|
||||
[configuration reference documentation](../../ci/yaml/README.md).
|
||||
[configuration reference documentation](../../ci/yaml/index.md).
|
||||
|
||||
## List GitLab CI YAML templates
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ A cache is one or more files that a job downloads and saves. Subsequent jobs tha
|
|||
the same cache don't have to download the files again, so they execute more quickly.
|
||||
|
||||
To learn how to define the cache in your `.gitlab-ci.yml` file,
|
||||
see the [`cache` reference](../yaml/README.md#cache).
|
||||
see the [`cache` reference](../yaml/index.md#cache).
|
||||
|
||||
## How cache is different from artifacts
|
||||
|
||||
|
|
@ -38,8 +38,8 @@ can't link to files outside it.
|
|||
- Subsequent jobs in later stages of the same pipeline can use artifacts.
|
||||
- Different projects cannot share artifacts.
|
||||
|
||||
Artifacts expire after 30 days unless you define an [expiration time](../yaml/README.md#artifactsexpire_in).
|
||||
Use [dependencies](../yaml/README.md#dependencies) to control which jobs fetch the artifacts.
|
||||
Artifacts expire after 30 days unless you define an [expiration time](../yaml/index.md#artifactsexpire_in).
|
||||
Use [dependencies](../yaml/index.md#dependencies) to control which jobs fetch the artifacts.
|
||||
|
||||
## Good caching practices
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ To ensure maximum availability of the cache, do one or more of the following:
|
|||
- [Tag your runners](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
|
||||
that share the cache.
|
||||
- [Use runners that are only available to a particular project](../runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects).
|
||||
- [Use a `key`](../yaml/README.md#cachekey) that fits your workflow. For example,
|
||||
- [Use a `key`](../yaml/index.md#cachekey) that fits your workflow. For example,
|
||||
you can configure a different cache for each branch.
|
||||
|
||||
For runners to work with caches efficiently, you must do one of the following:
|
||||
|
|
@ -97,7 +97,7 @@ the fallback cache is fetched every time a cache is not found.
|
|||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1534) in GitLab Runner 13.4.
|
||||
|
||||
You can use the `$CI_COMMIT_REF_SLUG` [predefined variable](../variables/predefined_variables.md)
|
||||
to specify your [`cache:key`](../yaml/README.md#cachekey). For example, if your
|
||||
to specify your [`cache:key`](../yaml/index.md#cachekey). For example, if your
|
||||
`$CI_COMMIT_REF_SLUG` is `test`, you can set a job to download cache that's tagged with `test`.
|
||||
|
||||
If a cache with this tag is not found, you can use `CACHE_FALLBACK_KEY` to
|
||||
|
|
@ -134,7 +134,7 @@ job:
|
|||
## Inherit global configuration, but override specific settings per job
|
||||
|
||||
You can override cache settings without overwriting the global cache by using
|
||||
[anchors](../yaml/README.md#anchors). For example, if you want to override the
|
||||
[anchors](../yaml/index.md#anchors). For example, if you want to override the
|
||||
`policy` for one job:
|
||||
|
||||
```yaml
|
||||
|
|
@ -154,7 +154,7 @@ job:
|
|||
policy: pull
|
||||
```
|
||||
|
||||
For more information, see [`cache: policy`](../yaml/README.md#cachepolicy).
|
||||
For more information, see [`cache: policy`](../yaml/index.md#cachepolicy).
|
||||
|
||||
## Common use cases for caches
|
||||
|
||||
|
|
@ -212,7 +212,7 @@ cache:
|
|||
If your project uses [npm](https://www.npmjs.com/) to install Node.js
|
||||
dependencies, the following example defines `cache` globally so that all jobs inherit it.
|
||||
By default, npm stores cache data in the home folder (`~/.npm`). However, you
|
||||
[can't cache things outside of the project directory](../yaml/README.md#cachepaths).
|
||||
[can't cache things outside of the project directory](../yaml/index.md#cachepaths).
|
||||
Instead, tell npm to use `./.npm`, and cache it per-branch:
|
||||
|
||||
```yaml
|
||||
|
|
@ -392,7 +392,7 @@ test:
|
|||
Caching is an optimization, but it isn't guaranteed to always work. You might need
|
||||
to regenerate cached files in each job that needs them.
|
||||
|
||||
After you define a [cache in `.gitlab-ci.yml`](../yaml/README.md#cache),
|
||||
After you define a [cache in `.gitlab-ci.yml`](../yaml/index.md#cache),
|
||||
the availability of the cache depends on:
|
||||
|
||||
- The runner's executor type.
|
||||
|
|
@ -489,7 +489,7 @@ machines, it is a safe default.
|
|||
|
||||
## Clearing the cache
|
||||
|
||||
Runners use [cache](../yaml/README.md#cache) to speed up the execution
|
||||
Runners use [cache](../yaml/index.md#cache) to speed up the execution
|
||||
of your jobs by reusing existing data. This can sometimes lead to
|
||||
inconsistent behavior.
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ to the job:
|
|||
- `CHAT_CHANNEL` is set to the name of channel the action was triggered in.
|
||||
|
||||
When executed, ChatOps looks up the specified job name and attempts to match it
|
||||
to a corresponding job in [`.gitlab-ci.yml`](../yaml/README.md). If a matching job
|
||||
to a corresponding job in [`.gitlab-ci.yml`](../yaml/index.md). If a matching job
|
||||
is found on the default branch, a pipeline containing only that job is scheduled. After the
|
||||
job completes:
|
||||
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ path to point to your ECR image.
|
|||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207962) in GitLab 12.9.
|
||||
> - The `Deploy-ECS.gitlab-ci.yml` template was [moved](https://gitlab.com/gitlab-org/gitlab/-/issues/220821) to `AWS/Deploy-ECS.gitlab-ci.yml` in GitLab 13.2.
|
||||
|
||||
GitLab provides a series of [CI templates that you can include in your project](../yaml/README.md#include).
|
||||
GitLab provides a series of [CI templates that you can include in your project](../yaml/index.md#include).
|
||||
To automate deployments of your application to your [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (AWS ECS)
|
||||
cluster, you can `include` the `AWS/Deploy-ECS.gitlab-ci.yml` template in your `.gitlab-ci.yml` file.
|
||||
|
||||
|
|
@ -231,7 +231,7 @@ pass three JSON input objects, based on existing templates:
|
|||
|
||||
- [Template for the _Create stack_ step on AWS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-anatomy.html).
|
||||
- Template for the _Push to S3_ step. Note that `source` is where a preceding `build` job built
|
||||
your application, exporting the build through [`artifacts:paths`](../yaml/README.md#artifactspaths):
|
||||
your application, exporting the build through [`artifacts:paths`](../yaml/index.md#artifactspaths):
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
|||
|
|
@ -66,9 +66,9 @@ as quickly as possible.
|
|||
|
||||
## Usage
|
||||
|
||||
Relationships are defined between jobs using the [`needs:` keyword](../yaml/README.md#needs).
|
||||
Relationships are defined between jobs using the [`needs:` keyword](../yaml/index.md#needs).
|
||||
|
||||
Note that `needs:` also works with the [parallel](../yaml/README.md#parallel) keyword,
|
||||
Note that `needs:` also works with the [parallel](../yaml/index.md#parallel) keyword,
|
||||
giving you powerful options for parallelization within your pipeline.
|
||||
|
||||
## Limitations
|
||||
|
|
@ -76,7 +76,7 @@ giving you powerful options for parallelization within your pipeline.
|
|||
A directed acyclic graph is a complicated feature, and as of the initial MVC there
|
||||
are certain use cases that you may need to work around. For more information:
|
||||
|
||||
- [`needs` requirements and limitations](../yaml/README.md#requirements-and-limitations).
|
||||
- [`needs` requirements and limitations](../yaml/index.md#requirements-and-limitations).
|
||||
- Related epic [tracking planned improvements](https://gitlab.com/groups/gitlab-org/-/epics/1716).
|
||||
|
||||
## Needs Visualization
|
||||
|
|
|
|||
|
|
@ -577,7 +577,7 @@ don't work because a fresh Docker daemon is started with the service.
|
|||
|
||||
### Option 1: Run `docker login`
|
||||
|
||||
In [`before_script`](../yaml/README.md#before_script), run `docker
|
||||
In [`before_script`](../yaml/index.md#before_script), run `docker
|
||||
login`:
|
||||
|
||||
```yaml
|
||||
|
|
@ -682,10 +682,10 @@ There are multiple ways to define this authentication:
|
|||
|
||||
- In [`pre_build_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
|
||||
in the runner configuration file.
|
||||
- In [`before_script`](../yaml/README.md#before_script).
|
||||
- In [`script`](../yaml/README.md#script).
|
||||
- In [`before_script`](../yaml/index.md#before_script).
|
||||
- In [`script`](../yaml/index.md#script).
|
||||
|
||||
The following example shows [`before_script`](../yaml/README.md#before_script).
|
||||
The following example shows [`before_script`](../yaml/index.md#before_script).
|
||||
The same commands apply for any solution you implement.
|
||||
|
||||
```yaml
|
||||
|
|
@ -798,7 +798,7 @@ which can be avoided if a different driver is used, for example `overlay2`.
|
|||
### Use the OverlayFS driver per project
|
||||
|
||||
You can enable the driver for each project individually by using the `DOCKER_DRIVER`
|
||||
[CI/CD variable](../yaml/README.md#variables) in `.gitlab-ci.yml`:
|
||||
[CI/CD variable](../yaml/index.md#variables) in `.gitlab-ci.yml`:
|
||||
|
||||
```yaml
|
||||
variables:
|
||||
|
|
|
|||
|
|
@ -153,9 +153,9 @@ CI/CD jobs:
|
|||
from `Dockerfile` that may be overridden in the `.gitlab-ci.yml` file.
|
||||
1. The runner attaches itself to a running container.
|
||||
1. The runner prepares a script (the combination of
|
||||
[`before_script`](../yaml/README.md#before_script),
|
||||
[`script`](../yaml/README.md#script),
|
||||
and [`after_script`](../yaml/README.md#after_script)).
|
||||
[`before_script`](../yaml/index.md#before_script),
|
||||
[`script`](../yaml/index.md#script),
|
||||
and [`after_script`](../yaml/index.md#after_script)).
|
||||
1. The runner sends the script to the container's shell `stdin` and receives the
|
||||
output.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ type: howto
|
|||
|
||||
To effectively use GitLab CI/CD, you need:
|
||||
|
||||
- A valid [`.gitlab-ci.yml`](yaml/README.md) file present at the root directory
|
||||
- A valid [`.gitlab-ci.yml`](yaml/index.md) file present at the root directory
|
||||
of your project.
|
||||
- A [runner](runners/index.md) properly set up.
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Pipeline jobs in GitLab CI/CD run in parallel, so it's possible that two deploym
|
|||
jobs in two different pipelines attempt to deploy to the same environment at the same
|
||||
time. This is not desired behavior as deployments should happen sequentially.
|
||||
|
||||
You can ensure only one deployment job runs at a time with the [`resource_group` keyword](../yaml/README.md#resource_group) in your `.gitlab-ci.yml`.
|
||||
You can ensure only one deployment job runs at a time with the [`resource_group` keyword](../yaml/index.md#resource_group) in your `.gitlab-ci.yml`.
|
||||
|
||||
For example:
|
||||
|
||||
|
|
@ -59,7 +59,7 @@ The improved pipeline flow **after** using the resource group:
|
|||
1. `deploy` job in Pipeline-A finishes.
|
||||
1. `deploy` job in Pipeline-B starts running.
|
||||
|
||||
For more information, see [`resource_group` keyword in `.gitlab-ci.yml`](../yaml/README.md#resource_group).
|
||||
For more information, see [`resource_group` keyword in `.gitlab-ci.yml`](../yaml/index.md#resource_group).
|
||||
|
||||
## Skip outdated deployment jobs
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ disqus_identifier: 'https://docs.gitlab.com/ee/ci/environments.html'
|
|||
|
||||
Environments describe where code is deployed.
|
||||
|
||||
Each time [GitLab CI/CD](../yaml/README.md) deploys a version of code to an environment,
|
||||
Each time [GitLab CI/CD](../yaml/index.md) deploys a version of code to an environment,
|
||||
a deployment is created.
|
||||
|
||||
GitLab:
|
||||
|
|
@ -84,7 +84,7 @@ When the job runs, the environment and deployment are created.
|
|||
NOTE:
|
||||
Some characters cannot be used in environment names.
|
||||
For more information about the `environment` keywords, see
|
||||
[the `.gitlab-ci.yml` keyword reference](../yaml/README.md#environment).
|
||||
[the `.gitlab-ci.yml` keyword reference](../yaml/index.md#environment).
|
||||
|
||||
### Create a dynamic environment
|
||||
|
||||
|
|
@ -107,7 +107,7 @@ deploy_review:
|
|||
|
||||
In this example:
|
||||
|
||||
- The `name` is `review/$CI_COMMIT_REF_NAME`. Because the [environment name](../yaml/README.md#environmentname)
|
||||
- The `name` is `review/$CI_COMMIT_REF_NAME`. Because the [environment name](../yaml/index.md#environmentname)
|
||||
can contain slashes (`/`), you can use this pattern to distinguish between dynamic and static environments.
|
||||
- For the `url`, you could use `$CI_COMMIT_REF_NAME`, but because this value
|
||||
may contain a `/` or other characters that would not be valid in a domain name or URL,
|
||||
|
|
@ -119,7 +119,7 @@ However, when you use this format, you can [group similar environments](#group-s
|
|||
NOTE:
|
||||
Some variables cannot be used as environment names or URLs.
|
||||
For more information about the `environment` keywords, see
|
||||
[the `.gitlab-ci.yml` keyword reference](../yaml/README.md#environment).
|
||||
[the `.gitlab-ci.yml` keyword reference](../yaml/index.md#environment).
|
||||
|
||||
## Deployment tier of environments
|
||||
|
||||
|
|
@ -141,8 +141,8 @@ you can use tiers:
|
|||
| `development` | Dev, [Review apps](../review_apps/index.md), Trunk |
|
||||
| `other` | |
|
||||
|
||||
By default, GitLab assumes a tier based on [the environment name](../yaml/README.md#environmentname).
|
||||
Instead, you can use the [`deployment_tier` keyword](../yaml/README.md#environmentdeployment_tier) to specify a tier.
|
||||
By default, GitLab assumes a tier based on [the environment name](../yaml/index.md#environmentname).
|
||||
Instead, you can use the [`deployment_tier` keyword](../yaml/index.md#environmentdeployment_tier) to specify a tier.
|
||||
|
||||
## Configure manual deployments
|
||||
|
||||
|
|
@ -250,7 +250,7 @@ GitLab supports the [dotenv (`.env`)](https://github.com/bkeepers/dotenv) file f
|
|||
and expands the `environment:url` value with variables defined in the `.env` file.
|
||||
|
||||
To use this feature, specify the
|
||||
[`artifacts:reports:dotenv`](../yaml/README.md#artifactsreportsdotenv) keyword in `.gitlab-ci.yml`.
|
||||
[`artifacts:reports:dotenv`](../yaml/index.md#artifactsreportsdotenv) keyword in `.gitlab-ci.yml`.
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
For an overview, see [Set dynamic URLs after a job finished](https://youtu.be/70jDXtOf4Ig).
|
||||
|
|
@ -334,7 +334,7 @@ To retry or rollback a deployment:
|
|||
|
||||
### Environment URL
|
||||
|
||||
The [environment URL](../yaml/README.md#environmenturl) is displayed in a few
|
||||
The [environment URL](../yaml/index.md#environmenturl) is displayed in a few
|
||||
places in GitLab:
|
||||
|
||||
- In a merge request as a link:
|
||||
|
|
@ -364,7 +364,7 @@ When you stop an environment:
|
|||
|
||||
- On the **Environments** page, it moves from the list of **Available** environments
|
||||
to the list of **Stopped** environments.
|
||||
- An [`on_stop` action](../yaml/README.md#environmenton_stop), if defined, is executed.
|
||||
- An [`on_stop` action](../yaml/index.md#environmenton_stop), if defined, is executed.
|
||||
|
||||
Dynamic environments stop automatically when their associated branch is
|
||||
deleted.
|
||||
|
|
@ -400,8 +400,8 @@ stop_review:
|
|||
when: manual
|
||||
```
|
||||
|
||||
Both jobs must have the same [`rules`](../yaml/README.md#only--except)
|
||||
or [`only/except`](../yaml/README.md#only--except) configuration. Otherwise,
|
||||
Both jobs must have the same [`rules`](../yaml/index.md#only--except)
|
||||
or [`only/except`](../yaml/index.md#only--except) configuration. Otherwise,
|
||||
the `stop_review` job might not be included in all pipelines that include the
|
||||
`deploy_review` job, and you cannot trigger `action: stop` to stop the environment automatically.
|
||||
|
||||
|
|
@ -413,7 +413,7 @@ set the [`GIT_STRATEGY`](../runners/configure_runners.md#git-strategy) to `none`
|
|||
`stop_review` job. Then the [runner](https://docs.gitlab.com/runner/) doesn't
|
||||
try to check out the code after the branch is deleted.
|
||||
|
||||
Read more in the [`.gitlab-ci.yml` reference](../yaml/README.md#environmenton_stop).
|
||||
Read more in the [`.gitlab-ci.yml` reference](../yaml/index.md#environmenton_stop).
|
||||
|
||||
#### Stop an environment after a certain time period
|
||||
|
||||
|
|
@ -421,7 +421,7 @@ Read more in the [`.gitlab-ci.yml` reference](../yaml/README.md#environmenton_st
|
|||
|
||||
You can set environments to stop automatically after a certain time period.
|
||||
|
||||
In your `.gitlab-ci.yml` file, specify the [`environment:auto_stop_in`](../yaml/README.md#environmentauto_stop_in)
|
||||
In your `.gitlab-ci.yml` file, specify the [`environment:auto_stop_in`](../yaml/index.md#environmentauto_stop_in)
|
||||
keyword. You can specify a human-friendly date as the value, such as `1 hour and 30 minutes` or `1 day`.
|
||||
After the time period passes, GitLab automatically triggers a job to stop the environment.
|
||||
|
||||
|
|
@ -767,7 +767,7 @@ To ensure the `action: stop` can always run when needed, you can:
|
|||
when: manual
|
||||
```
|
||||
|
||||
- Add a [`needs`](../yaml/README.md#needs) entry to the `action: stop` job so the
|
||||
- Add a [`needs`](../yaml/index.md#needs) entry to the `action: stop` job so the
|
||||
job can start out of stage order:
|
||||
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -146,10 +146,10 @@ new browser window interacting with your app as you specified.
|
|||
Which brings us to the exciting part: how do we run this in GitLab CI/CD? There are two things we
|
||||
need to do for this:
|
||||
|
||||
1. Set up [CI/CD jobs](../../yaml/README.md) that actually have a browser available.
|
||||
1. Set up [CI/CD jobs](../../yaml/index.md) that actually have a browser available.
|
||||
1. Update our WebdriverIO configuration to use those browsers to visit the review apps.
|
||||
|
||||
For the scope of this article, we've defined an additional [CI/CD stage](../../yaml/README.md#stages)
|
||||
For the scope of this article, we've defined an additional [CI/CD stage](../../yaml/index.md#stages)
|
||||
`confidence-check` that is executed _after_ the stage that deploys the review app. It uses the `node:latest` [Docker
|
||||
image](../../docker/using_docker_images.md). However, WebdriverIO fires up actual browsers
|
||||
to interact with your application, so we need to install and run them.
|
||||
|
|
@ -255,5 +255,5 @@ production project, see:
|
|||
|
||||
There's plenty more that WebdriverIO can do. For example, you can configure a [`screenshotPath`](http://v4.webdriver.io/guide/getstarted/configuration.html#screenshotPath) to tell WebdriverIO to take
|
||||
a screenshot when tests are failing. Then tell GitLab CI/CD to store those
|
||||
[artifacts](../../yaml/README.md#artifacts), and you'll be able to see what went
|
||||
[artifacts](../../yaml/index.md#artifacts), and you'll be able to see what went
|
||||
wrong within GitLab.
|
||||
|
|
|
|||
|
|
@ -548,7 +548,7 @@ If you wish to test your app with different PHP versions and [database managemen
|
|||
|
||||
#### CI/CD variables
|
||||
|
||||
GitLab CI/CD allows us to use [CI/CD variables](../../yaml/README.md#variables) in our jobs.
|
||||
GitLab CI/CD allows us to use [CI/CD variables](../../yaml/index.md#variables) in our jobs.
|
||||
We defined MySQL as our database management system, which comes with a superuser root created by default.
|
||||
|
||||
So we should adjust the configuration of MySQL instance by defining `MYSQL_DATABASE` variable as our database name and `MYSQL_ROOT_PASSWORD` variable as the password of `root`.
|
||||
|
|
@ -567,7 +567,7 @@ variables:
|
|||
|
||||
#### Unit Test as the first job
|
||||
|
||||
We defined the required shell scripts as an array of the [script](../../yaml/README.md#script) keyword to be executed when running `unit_test` job.
|
||||
We defined the required shell scripts as an array of the [script](../../yaml/index.md#script) keyword to be executed when running `unit_test` job.
|
||||
|
||||
These scripts are some Artisan commands to prepare the Laravel, and, at the end of the script, we'll run the tests by `PHPUnit`.
|
||||
|
||||
|
|
@ -593,7 +593,7 @@ To deploy our app with Envoy, we had to set up the `$SSH_PRIVATE_KEY` variable a
|
|||
If the SSH keys have added successfully, we can run Envoy.
|
||||
|
||||
As mentioned before, GitLab supports [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-delivery) methods as well.
|
||||
The [environment](../../yaml/README.md#environment) keyword tells GitLab that this job deploys to the `production` environment.
|
||||
The [environment](../../yaml/index.md#environment) keyword tells GitLab that this job deploys to the `production` environment.
|
||||
The `url` keyword is used to generate a link to our application on the GitLab Environments page.
|
||||
The `only` keyword tells GitLab CI/CD that the job should be executed only when the pipeline is building the `main` branch.
|
||||
Lastly, `when: manual` is used to turn the job from running automatically to a manual action.
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ GitLab CI/CD supports numerous configuration options:
|
|||
| [Pipelines for Merge Requests](merge_request_pipelines/index.md) | Design a pipeline structure for running a pipeline in merge requests. |
|
||||
| [Integrate with Kubernetes clusters](../user/project/clusters/index.md) | Connect your project to Google Kubernetes Engine (GKE) or an existing Kubernetes cluster. |
|
||||
| [Optimize GitLab and GitLab Runner for large repositories](large_repositories/index.md) | Recommended strategies for handling large repositories. |
|
||||
| [`.gitlab-ci.yml` full reference](yaml/README.md) | All the attributes you can use with GitLab CI/CD. |
|
||||
| [`.gitlab-ci.yml` full reference](yaml/index.md) | All the attributes you can use with GitLab CI/CD. |
|
||||
|
||||
Note that certain operations can only be performed according to the
|
||||
[user](../user/permissions.md#gitlab-cicd-permissions) and [job](../user/permissions.md#job-permissions) permissions.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Pipeline configuration begins with jobs. Jobs are the most fundamental element o
|
|||
Jobs are:
|
||||
|
||||
- Defined with constraints stating under what conditions they should be executed.
|
||||
- Top-level elements with an arbitrary name and must contain at least the [`script`](../yaml/README.md#script) clause.
|
||||
- Top-level elements with an arbitrary name and must contain at least the [`script`](../yaml/index.md#script) clause.
|
||||
- Not limited in how many can be defined.
|
||||
|
||||
For example:
|
||||
|
|
@ -101,7 +101,7 @@ jobs. Click to expand them.
|
|||
|
||||
|
||||
|
||||
To create a group of jobs, in the [CI/CD pipeline configuration file](../yaml/README.md),
|
||||
To create a group of jobs, in the [CI/CD pipeline configuration file](../yaml/index.md),
|
||||
separate each job name with a number and one of the following:
|
||||
|
||||
- A slash (`/`), for example, `test 1/3`, `test 2/3`, `test 3/3`.
|
||||
|
|
@ -168,7 +168,7 @@ for a single run of the manual job.
|
|||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21767) in GitLab 11.4.
|
||||
|
||||
When you do not want to run a job immediately, you can use the [`when:delayed`](../yaml/README.md#whendelayed) keyword to
|
||||
When you do not want to run a job immediately, you can use the [`when:delayed`](../yaml/index.md#whendelayed) keyword to
|
||||
delay a job's execution for a certain period.
|
||||
|
||||
This is especially useful for timed incremental rollout where new code is rolled out gradually.
|
||||
|
|
|
|||
|
|
@ -12,22 +12,22 @@ the status of variables, the pipeline type, and so on.
|
|||
|
||||
To configure a job to be included or excluded from certain pipelines, you can use:
|
||||
|
||||
- [`rules`](../yaml/README.md#rules)
|
||||
- [`only`](../yaml/README.md#only--except)
|
||||
- [`except`](../yaml/README.md#only--except)
|
||||
- [`rules`](../yaml/index.md#rules)
|
||||
- [`only`](../yaml/index.md#only--except)
|
||||
- [`except`](../yaml/index.md#only--except)
|
||||
|
||||
Use [`needs`](../yaml/README.md#needs) to configure a job to run as soon as the
|
||||
Use [`needs`](../yaml/index.md#needs) to configure a job to run as soon as the
|
||||
earlier jobs it depends on finish running.
|
||||
|
||||
## Specify when jobs run with `rules`
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27863) in GitLab 12.3.
|
||||
|
||||
Use [`rules`](../yaml/README.md#rules) to include or exclude jobs in pipelines.
|
||||
Use [`rules`](../yaml/index.md#rules) to include or exclude jobs in pipelines.
|
||||
|
||||
Rules are evaluated in order until the first match. When a match is found, the job
|
||||
is either included or excluded from the pipeline, depending on the configuration.
|
||||
See the [`rules`](../yaml/README.md#rules) reference for more details.
|
||||
See the [`rules`](../yaml/index.md#rules) reference for more details.
|
||||
|
||||
Future keyword improvements are being discussed in our [epic for improving `rules`](https://gitlab.com/groups/gitlab-org/-/epics/2783),
|
||||
where anyone can add suggestions or requests.
|
||||
|
|
@ -150,7 +150,7 @@ causes duplicated pipelines.
|
|||
|
||||
To avoid duplicate pipelines, you can:
|
||||
|
||||
- Use [`workflow`](../yaml/README.md#workflow) to specify which types of pipelines
|
||||
- Use [`workflow`](../yaml/index.md#workflow) to specify which types of pipelines
|
||||
can run.
|
||||
- Rewrite the rules to run the job only in very specific cases,
|
||||
and avoid a final `when:` rule:
|
||||
|
|
@ -179,7 +179,7 @@ job:
|
|||
```
|
||||
|
||||
You should not include both push and merge request pipelines in the same job without
|
||||
[`workflow:rules` that prevent duplicate pipelines](../yaml/README.md#switch-between-branch-pipelines-and-merge-request-pipelines):
|
||||
[`workflow:rules` that prevent duplicate pipelines](../yaml/index.md#switch-between-branch-pipelines-and-merge-request-pipelines):
|
||||
|
||||
```yaml
|
||||
job:
|
||||
|
|
@ -206,12 +206,12 @@ job-with-rules:
|
|||
For every change pushed to the branch, duplicate pipelines run. One
|
||||
branch pipeline runs a single job (`job-with-no-rules`), and one merge request pipeline
|
||||
runs the other job (`job-with-rules`). Jobs with no rules default
|
||||
to [`except: merge_requests`](../yaml/README.md#only--except), so `job-with-no-rules`
|
||||
to [`except: merge_requests`](../yaml/index.md#only--except), so `job-with-no-rules`
|
||||
runs in all cases except merge requests.
|
||||
|
||||
### Common `if` clauses for `rules`
|
||||
|
||||
For behavior similar to the [`only`/`except` keywords](../yaml/README.md#only--except), you can
|
||||
For behavior similar to the [`only`/`except` keywords](../yaml/index.md#only--except), you can
|
||||
check the value of the `$CI_PIPELINE_SOURCE` variable:
|
||||
|
||||
| Value | Description |
|
||||
|
|
@ -222,7 +222,7 @@ check the value of the `$CI_PIPELINE_SOURCE` variable:
|
|||
| `external_pull_request_event` | When an external pull request on GitHub is created or updated. See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). |
|
||||
| `merge_request_event` | For pipelines created when a merge request is created or updated. Required to enable [merge request pipelines](../merge_request_pipelines/index.md), [merged results pipelines](../merge_request_pipelines/pipelines_for_merged_results/index.md), and [merge trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). |
|
||||
| `parent_pipeline` | For pipelines triggered by a [parent/child pipeline](../parent_child_pipelines.md) with `rules`. Use this pipeline source in the child pipeline configuration so that it can be triggered by the parent pipeline. |
|
||||
| `pipeline` | For [multi-project pipelines](../multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api), or the [`trigger`](../yaml/README.md#trigger) keyword. |
|
||||
| `pipeline` | For [multi-project pipelines](../multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api), or the [`trigger`](../yaml/index.md#trigger) keyword. |
|
||||
| `push` | For pipelines triggered by a `git push` event, including for branches and tags. |
|
||||
| `schedule` | For [scheduled pipelines](../pipelines/schedules.md). |
|
||||
| `trigger` | For pipelines created by using a [trigger token](../triggers/index.md#trigger-token). |
|
||||
|
|
@ -292,7 +292,7 @@ You can use the `$` character for both variables and paths. For example, if the
|
|||
|
||||
## Specify when jobs run with `only` and `except`
|
||||
|
||||
You can use [`only`](../yaml/README.md#only--except) and [`except`](../yaml/README.md#only--except)
|
||||
You can use [`only`](../yaml/index.md#only--except) and [`except`](../yaml/index.md#only--except)
|
||||
to control when to add jobs to pipelines.
|
||||
|
||||
- Use `only` to define when a job runs.
|
||||
|
|
@ -301,7 +301,7 @@ to control when to add jobs to pipelines.
|
|||
### `only:refs` / `except:refs` examples
|
||||
|
||||
`only` or `except` used without `refs` is the same as
|
||||
[`only:refs` / `except/refs`](../yaml/README.md#onlyrefs--exceptrefs)
|
||||
[`only:refs` / `except/refs`](../yaml/index.md#onlyrefs--exceptrefs)
|
||||
|
||||
In the following example, `job` runs only for:
|
||||
|
||||
|
|
@ -334,7 +334,7 @@ except `main` and branches that start with `release/`.
|
|||
|
||||
### `only: variables` / `except: variables` examples
|
||||
|
||||
You can use [`except:variables`](../yaml/README.md#onlyvariables--exceptvariables) to exclude jobs based on a commit message:
|
||||
You can use [`except:variables`](../yaml/index.md#onlyvariables--exceptvariables) to exclude jobs based on a commit message:
|
||||
|
||||
```yaml
|
||||
end-to-end:
|
||||
|
|
@ -502,9 +502,9 @@ test:
|
|||
You can use [predefined CI/CD variables](../variables/predefined_variables.md) to choose
|
||||
which pipeline types jobs run in, with:
|
||||
|
||||
- [`rules`](../yaml/README.md#rules)
|
||||
- [`only:variables`](../yaml/README.md#onlyvariables--exceptvariables)
|
||||
- [`except:variables`](../yaml/README.md#onlyvariables--exceptvariables)
|
||||
- [`rules`](../yaml/index.md#rules)
|
||||
- [`only:variables`](../yaml/index.md#onlyvariables--exceptvariables)
|
||||
- [`except:variables`](../yaml/index.md#onlyvariables--exceptvariables)
|
||||
|
||||
The following table lists some of the variables that you can use, and the pipeline
|
||||
types the variables can control for:
|
||||
|
|
@ -592,14 +592,14 @@ Feature.enable(:allow_unsafe_ruby_regexp)
|
|||
|
||||
## CI/CD variable expressions
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37397) in GitLab 10.7 for [the `only` and `except` CI keywords](../yaml/README.md#onlyvariables--exceptvariables)
|
||||
> - [Expanded](https://gitlab.com/gitlab-org/gitlab/-/issues/27863) in GitLab 12.3 with [the `rules` keyword](../yaml/README.md#rules)
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37397) in GitLab 10.7 for [the `only` and `except` CI keywords](../yaml/index.md#onlyvariables--exceptvariables)
|
||||
> - [Expanded](https://gitlab.com/gitlab-org/gitlab/-/issues/27863) in GitLab 12.3 with [the `rules` keyword](../yaml/index.md#rules)
|
||||
|
||||
Use variable expressions to control which jobs are created in a pipeline after changes
|
||||
are pushed to GitLab. You can use variable expressions with:
|
||||
|
||||
- [`rules:if`](../yaml/README.md#rules).
|
||||
- [`only:variables` and `except:variables`](../yaml/README.md#onlyvariables--exceptvariables).
|
||||
- [`rules:if`](../yaml/index.md#rules).
|
||||
- [`only:variables` and `except:variables`](../yaml/index.md#onlyvariables--exceptvariables).
|
||||
|
||||
For example, with `rules:if`:
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ in your project and click **CI lint**.
|
|||
## Validate basic logic and syntax
|
||||
|
||||
By default, the CI lint checks the syntax of your CI YAML configuration and also runs
|
||||
some basic logical validations. Configuration added with the [`includes` keyword](yaml/README.md#include),
|
||||
some basic logical validations. Configuration added with the [`includes` keyword](yaml/index.md#include),
|
||||
is also validated.
|
||||
|
||||
To use the CI lint, paste a complete CI configuration (`.gitlab-ci.yml` for example)
|
||||
|
|
|
|||
|
|
@ -39,13 +39,13 @@ To enable pipelines for merge requests:
|
|||
|
||||
## Configure pipelines for merge requests
|
||||
|
||||
To configure pipelines for merge requests, you must configure your [CI/CD configuration file](../yaml/README.md).
|
||||
To configure pipelines for merge requests, you must configure your [CI/CD configuration file](../yaml/index.md).
|
||||
To do this, you can use [`rules`](#use-rules-to-run-pipelines-for-merge-requests) or [`only/except`](#use-only-or-except-to-run-pipelines-for-merge-requests).
|
||||
|
||||
### Use `rules` to run pipelines for merge requests
|
||||
|
||||
GitLab recommends that you use the `rules` keyword, which is available in
|
||||
[`workflow:rules` templates](../yaml/README.md#workflowrules-templates).
|
||||
[`workflow:rules` templates](../yaml/index.md#workflowrules-templates).
|
||||
|
||||
### Use `only` or `except` to run pipelines for merge requests
|
||||
|
||||
|
|
@ -138,7 +138,7 @@ Instead, use the
|
|||
[`$CI_COMMIT_REF_NAME` predefined environment
|
||||
variable](../variables/predefined_variables.md) in
|
||||
combination with
|
||||
[`only:variables`](../yaml/README.md#onlyvariables--exceptvariables) to
|
||||
[`only:variables`](../yaml/index.md#onlyvariables--exceptvariables) to
|
||||
accomplish this behavior:
|
||||
|
||||
```yaml
|
||||
|
|
@ -199,7 +199,7 @@ If you are seeing two pipelines when using `only/except`, please see the caveats
|
|||
related to using `only/except` above (or, consider moving to `rules`).
|
||||
|
||||
In [GitLab 13.7](https://gitlab.com/gitlab-org/gitlab/-/issues/201845) and later,
|
||||
you can add `workflow:rules` to [switch from branch pipelines to merge request pipelines](../yaml/README.md#switch-between-branch-pipelines-and-merge-request-pipelines).
|
||||
you can add `workflow:rules` to [switch from branch pipelines to merge request pipelines](../yaml/index.md#switch-between-branch-pipelines-and-merge-request-pipelines).
|
||||
After a merge request is open on the branch, the pipeline switches to a merge request pipeline.
|
||||
|
||||
### Two pipelines created when pushing an invalid CI configuration file
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ For an MR, the values of these metrics from the feature branch are compared to t
|
|||
|
||||
## How to set it up
|
||||
|
||||
Add a job that creates a [metrics report](yaml/README.md#artifactsreportsmetrics) (default filename: `metrics.txt`). The file should conform to the [OpenMetrics](https://openmetrics.io/) format.
|
||||
Add a job that creates a [metrics report](yaml/index.md#artifactsreportsmetrics) (default filename: `metrics.txt`). The file should conform to the [OpenMetrics](https://openmetrics.io/) format.
|
||||
|
||||
For example:
|
||||
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ job1:
|
|||
|
||||
### Workflows
|
||||
|
||||
CircleCI determines the run order for jobs with `workflows`. This is also used to determine concurrent, sequential, scheduled, or manual runs. The equivalent function in GitLab CI/CD is called [stages](../yaml/README.md#stages). Jobs on the same stage run in parallel, and only run after previous stages complete. Execution of the next stage is skipped when a job fails by default, but this can be allowed to continue even [after a failed job](../yaml/README.md#allow_failure).
|
||||
CircleCI determines the run order for jobs with `workflows`. This is also used to determine concurrent, sequential, scheduled, or manual runs. The equivalent function in GitLab CI/CD is called [stages](../yaml/index.md#stages). Jobs on the same stage run in parallel, and only run after previous stages complete. Execution of the next stage is skipped when a job fails by default, but this can be allowed to continue even [after a failed job](../yaml/index.md#allow_failure).
|
||||
|
||||
See [the Pipeline Architecture Overview](../pipelines/pipeline_architectures.md) for guidance on different types of pipelines that you can use. Pipelines can be tailored to meet your needs, such as for a large complex project or a monorepo with independent defined components.
|
||||
|
||||
|
|
@ -140,7 +140,7 @@ job4:
|
|||
|
||||
#### Scheduled run
|
||||
|
||||
GitLab CI/CD has an easy to use UI to [schedule pipelines](../pipelines/schedules.md). Also, [rules](../yaml/README.md#rules) can be used to determine if jobs should be included or excluded from a scheduled pipeline.
|
||||
GitLab CI/CD has an easy to use UI to [schedule pipelines](../pipelines/schedules.md). Also, [rules](../yaml/index.md#rules) can be used to determine if jobs should be included or excluded from a scheduled pipeline.
|
||||
|
||||
CircleCI example of a scheduled workflow:
|
||||
|
||||
|
|
@ -159,7 +159,7 @@ scheduled-workflow:
|
|||
- build
|
||||
```
|
||||
|
||||
Example of the same scheduled pipeline using [`rules`](../yaml/README.md#rules) in GitLab CI/CD:
|
||||
Example of the same scheduled pipeline using [`rules`](../yaml/index.md#rules) in GitLab CI/CD:
|
||||
|
||||
```yaml
|
||||
job1:
|
||||
|
|
@ -188,7 +188,7 @@ release-branch-workflow:
|
|||
- testing
|
||||
```
|
||||
|
||||
Example of the same workflow using [`when: manual`](../yaml/README.md#whenmanual) in GitLab CI/CD:
|
||||
Example of the same workflow using [`when: manual`](../yaml/index.md#whenmanual) in GitLab CI/CD:
|
||||
|
||||
```yaml
|
||||
deploy_prod:
|
||||
|
|
@ -200,7 +200,7 @@ deploy_prod:
|
|||
|
||||
### Filter job by branch
|
||||
|
||||
[Rules](../yaml/README.md#rules) are a mechanism to determine if the job runs for a specific branch.
|
||||
[Rules](../yaml/index.md#rules) are a mechanism to determine if the job runs for a specific branch.
|
||||
|
||||
CircleCI example of a job filtered by branch:
|
||||
|
||||
|
|
@ -294,7 +294,7 @@ GitLab.com shared runners:
|
|||
|
||||
### Machine and specific build environments
|
||||
|
||||
[Tags](../yaml/README.md#tags) can be used to run jobs on different platforms, by telling GitLab which runners should run the jobs.
|
||||
[Tags](../yaml/index.md#tags) can be used to run jobs on different platforms, by telling GitLab which runners should run the jobs.
|
||||
|
||||
CircleCI example of a job running on a specific environment:
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ that were able to quickly complete this migration:
|
|||
1. Learn the importance of [managing the organizational transition](#managing-the-organizational-transition).
|
||||
1. [Add runners](../runners/index.md) to your GitLab instance.
|
||||
1. Educate and enable your developers to independently perform the following steps in their projects:
|
||||
1. Review the [Quick Start Guide](../quick_start/index.md) and [Pipeline Configuration Reference](../yaml/README.md).
|
||||
1. Review the [Quick Start Guide](../quick_start/index.md) and [Pipeline Configuration Reference](../yaml/index.md).
|
||||
1. Use the [Jenkins Wrapper](#jenkinsfile-wrapper) to temporarily maintain fragile Jenkins jobs.
|
||||
1. Migrate the build and CI jobs and configure them to show results directly in your merge requests. They can use [Auto DevOps](../../topics/autodevops/index.md) as a starting point, and [customize](../../topics/autodevops/customize.md) or [decompose](../../topics/autodevops/customize.md#using-components-of-auto-devops) the configuration as needed.
|
||||
1. Add [Review Apps](../review_apps/index.md).
|
||||
|
|
@ -71,7 +71,7 @@ If you are interested in helping GitLab test the wrapper, join our [public testi
|
|||
There are some high level differences between the products worth mentioning:
|
||||
|
||||
- With GitLab you don't need a root `pipeline` keyword to wrap everything.
|
||||
- The way pipelines are triggered and [trigger other pipelines](../yaml/README.md#trigger)
|
||||
- The way pipelines are triggered and [trigger other pipelines](../yaml/index.md#trigger)
|
||||
is different than Jenkins. GitLab pipelines can be triggered:
|
||||
|
||||
- on push
|
||||
|
|
@ -82,34 +82,34 @@ There are some high level differences between the products worth mentioning:
|
|||
- by [ChatOps](../chatops/index.md)
|
||||
|
||||
- You can control which jobs run in which cases, depending on how they are triggered,
|
||||
with the [`rules` syntax](../yaml/README.md#rules).
|
||||
with the [`rules` syntax](../yaml/index.md#rules).
|
||||
- GitLab [pipeline scheduling concepts](../pipelines/schedules.md) are also different from Jenkins.
|
||||
- You can reuse pipeline configurations using the [`include` keyword](../yaml/README.md#include)
|
||||
- You can reuse pipeline configurations using the [`include` keyword](../yaml/index.md#include)
|
||||
and [templates](#templates). Your templates can be kept in a central repository (with different
|
||||
permissions), and then any project can use them. This central project could also
|
||||
contain scripts or other reusable code.
|
||||
- You can also use the [`extends` keyword](../yaml/README.md#extends) to reuse configuration
|
||||
- You can also use the [`extends` keyword](../yaml/index.md#extends) to reuse configuration
|
||||
within a single pipeline configuration.
|
||||
- All jobs within a single stage always run in parallel, and all stages run in sequence. We are planning
|
||||
to allow certain jobs to break this sequencing as needed with our [directed acyclic graph](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47063)
|
||||
feature.
|
||||
- The [`parallel`](../yaml/README.md#parallel) keyword can automatically parallelize tasks,
|
||||
- The [`parallel`](../yaml/index.md#parallel) keyword can automatically parallelize tasks,
|
||||
like tests that support parallelization.
|
||||
- Normally all jobs within a single stage run in parallel, and all stages run in sequence.
|
||||
There are different [pipeline architectures](../pipelines/pipeline_architectures.md)
|
||||
that allow you to change this behavior.
|
||||
- The new [`rules` syntax](../yaml/README.md#rules) is the recommended method of
|
||||
- The new [`rules` syntax](../yaml/index.md#rules) is the recommended method of
|
||||
controlling when different jobs run. It is more powerful than the `only/except` syntax.
|
||||
- One important difference is that jobs run independently of each other and have a
|
||||
fresh environment in each job. Passing artifacts between jobs is controlled using the
|
||||
[`artifacts`](../yaml/README.md#artifacts) and [`dependencies`](../yaml/README.md#dependencies)
|
||||
[`artifacts`](../yaml/index.md#artifacts) and [`dependencies`](../yaml/index.md#dependencies)
|
||||
keywords. When finished, use the planned [Workspaces](https://gitlab.com/gitlab-org/gitlab/-/issues/29265)
|
||||
feature to more easily persist a common workspace between serial jobs.
|
||||
- The `.gitlab-ci.yml` file is checked in to the root of your repository, much like a Jenkinsfile, but
|
||||
is in the YAML format (see [complete reference](../yaml/README.md)) instead of a Groovy DSL. It's most
|
||||
is in the YAML format (see [complete reference](../yaml/index.md)) instead of a Groovy DSL. It's most
|
||||
analogous to the declarative Jenkinsfile format.
|
||||
- Manual approvals or gates can be set up as [`when:manual` jobs](../yaml/README.md#whenmanual). These can
|
||||
also leverage [`protected environments`](../yaml/README.md#protecting-manual-jobs)
|
||||
- Manual approvals or gates can be set up as [`when:manual` jobs](../yaml/index.md#whenmanual). These can
|
||||
also leverage [`protected environments`](../yaml/index.md#protecting-manual-jobs)
|
||||
to control who is able to approve them.
|
||||
- GitLab comes with a [container registry](../../user/packages/container_registry/index.md), and we recommend using
|
||||
container images to set up your build environment. For example, set up one pipeline that builds your build environment
|
||||
|
|
@ -154,8 +154,8 @@ and manage.
|
|||
|
||||
That said, we do of course still value DRY (don't repeat yourself) principles and want to ensure that
|
||||
behaviors of your jobs can be codified once and applied as needed. You can use the `extends:` syntax to
|
||||
[reuse configuration in your jobs](../yaml/README.md#extends), and `include:` can
|
||||
be used to [reuse pipeline configurations](../yaml/README.md#include) in pipelines
|
||||
[reuse configuration in your jobs](../yaml/index.md#extends), and `include:` can
|
||||
be used to [reuse pipeline configurations](../yaml/index.md#include) in pipelines
|
||||
in different projects:
|
||||
|
||||
```yaml
|
||||
|
|
@ -234,7 +234,7 @@ We also support using [tags](../runners/configure_runners.md#use-tags-to-limit-t
|
|||
to different runners (execution agents).
|
||||
|
||||
The `agent` section also allows you to define which Docker images should be used for execution, for which we use
|
||||
the [`image`](../yaml/README.md#image) keyword. The `image` can be set on a single job or at the top level, in which
|
||||
the [`image`](../yaml/index.md#image) keyword. The `image` can be set on a single job or at the top level, in which
|
||||
case it applies to all jobs in the pipeline:
|
||||
|
||||
```yaml
|
||||
|
|
@ -258,7 +258,7 @@ stages:
|
|||
```
|
||||
|
||||
Setting a step to be performed before and after any job can be done via the
|
||||
[`before_script`](../yaml/README.md#before_script) and [`after_script`](../yaml/README.md#after_script) keywords:
|
||||
[`before_script`](../yaml/index.md#before_script) and [`after_script`](../yaml/index.md#after_script) keywords:
|
||||
|
||||
```yaml
|
||||
default:
|
||||
|
|
@ -268,10 +268,10 @@ default:
|
|||
|
||||
#### `stages`
|
||||
|
||||
GitLab CI/CD also lets you define stages, but is a little bit more free-form to configure. The GitLab [`stages` keyword](../yaml/README.md#stages)
|
||||
GitLab CI/CD also lets you define stages, but is a little bit more free-form to configure. The GitLab [`stages` keyword](../yaml/index.md#stages)
|
||||
is a top level setting that enumerates the list of stages, but you are not required to nest individual jobs underneath
|
||||
the `stages` section. Any job defined in the `.gitlab-ci.yml` can be made a part of any stage through use of the
|
||||
[`stage:` keyword](../yaml/README.md#stage).
|
||||
[`stage:` keyword](../yaml/index.md#stage).
|
||||
|
||||
Note that, unless otherwise specified, every pipeline is instantiated with a `build`, `test`, and `deploy` stage
|
||||
which are run in that order. Jobs that have no `stage` defined are placed by default in the `test` stage.
|
||||
|
|
@ -289,7 +289,7 @@ my_job:
|
|||
|
||||
#### `steps`
|
||||
|
||||
The `steps` section is equivalent to the [`script` section](../yaml/README.md#script) of an individual job. This is
|
||||
The `steps` section is equivalent to the [`script` section](../yaml/index.md#script) of an individual job. This is
|
||||
a simple YAML array with each line representing an individual command to be run:
|
||||
|
||||
```yaml
|
||||
|
|
@ -303,7 +303,7 @@ my_job:
|
|||
|
||||
#### `environment`
|
||||
|
||||
In GitLab, we use the [`variables` keyword](../yaml/README.md#variables) to define different variables at runtime.
|
||||
In GitLab, we use the [`variables` keyword](../yaml/index.md#variables) to define different variables at runtime.
|
||||
These can also be set up through the GitLab UI, under CI/CD settings. See also our [general documentation on variables](../variables/index.md),
|
||||
including the section on [protected variables](../variables/index.md#protect-a-cicd-variable) which can be used
|
||||
to limit access to certain variables to certain environments or runners:
|
||||
|
|
@ -318,7 +318,7 @@ variables:
|
|||
|
||||
Here, options for different things exist associated with the object in question itself. For example, options related
|
||||
to jobs are defined in relation to the job itself. If you're looking for a certain option, you should be able to find
|
||||
where it's located by searching our [complete configuration reference](../yaml/README.md) page.
|
||||
where it's located by searching our [complete configuration reference](../yaml/index.md) page.
|
||||
|
||||
#### `parameters`
|
||||
|
||||
|
|
@ -347,9 +347,9 @@ variable entry.
|
|||
|
||||
#### `when`
|
||||
|
||||
GitLab does support a [`when` keyword](../yaml/README.md#when) which is used to indicate when a job should be
|
||||
GitLab does support a [`when` keyword](../yaml/index.md#when) which is used to indicate when a job should be
|
||||
run in case of (or despite) failure, but most of the logic for controlling pipelines can be found in
|
||||
our very powerful [`rules` system](../yaml/README.md#rules):
|
||||
our very powerful [`rules` system](../yaml/index.md#rules):
|
||||
|
||||
```yaml
|
||||
my_job:
|
||||
|
|
|
|||
|
|
@ -78,17 +78,17 @@ the `staging` job is marked as _failed_.
|
|||
|
||||
#### Trigger job configuration keywords
|
||||
|
||||
Trigger jobs can use only a limited set of the GitLab CI/CD [configuration keywords](yaml/README.md).
|
||||
Trigger jobs can use only a limited set of the GitLab CI/CD [configuration keywords](yaml/index.md).
|
||||
The keywords available for use in trigger jobs are:
|
||||
|
||||
- [`trigger`](yaml/README.md#trigger)
|
||||
- [`stage`](yaml/README.md#stage)
|
||||
- [`allow_failure`](yaml/README.md#allow_failure)
|
||||
- [`rules`](yaml/README.md#rules)
|
||||
- [`only` and `except`](yaml/README.md#only--except)
|
||||
- [`when`](yaml/README.md#when) (only with a value of `on_success`, `on_failure`, or `always`)
|
||||
- [`extends`](yaml/README.md#extends)
|
||||
- [`needs`](yaml/README.md#needs)
|
||||
- [`trigger`](yaml/index.md#trigger)
|
||||
- [`stage`](yaml/index.md#stage)
|
||||
- [`allow_failure`](yaml/index.md#allow_failure)
|
||||
- [`rules`](yaml/index.md#rules)
|
||||
- [`only` and `except`](yaml/index.md#only--except)
|
||||
- [`when`](yaml/index.md#when) (only with a value of `on_success`, `on_failure`, or `always`)
|
||||
- [`extends`](yaml/index.md#extends)
|
||||
- [`needs`](yaml/index.md#needs)
|
||||
|
||||
#### Specify a downstream pipeline branch
|
||||
|
||||
|
|
@ -175,7 +175,7 @@ the ones defined in the upstream project take precedence.
|
|||
|
||||
#### Pass CI/CD variables to a downstream pipeline by using variable inheritance
|
||||
|
||||
You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](variables/index.md#pass-an-environment-variable-to-another-job) and [cross project artifact downloads](yaml/README.md#cross-project-artifact-downloads-with-needs).
|
||||
You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](variables/index.md#pass-an-environment-variable-to-another-job) and [cross project artifact downloads](yaml/index.md#cross-project-artifact-downloads-with-needs).
|
||||
|
||||
In the upstream pipeline:
|
||||
|
||||
|
|
@ -215,14 +215,14 @@ In the upstream pipeline:
|
|||
|
||||
#### Use `rules` or `only`/`except` with multi-project pipelines
|
||||
|
||||
You can use CI/CD variables or the [`rules`](yaml/README.md#rulesif) keyword to
|
||||
You can use CI/CD variables or the [`rules`](yaml/index.md#rulesif) keyword to
|
||||
[control job behavior](jobs/job_control.md) for multi-project pipelines. When a
|
||||
downstream pipeline is triggered with the [`trigger`](yaml/README.md#trigger) keyword,
|
||||
downstream pipeline is triggered with the [`trigger`](yaml/index.md#trigger) keyword,
|
||||
the value of the [`$CI_PIPELINE_SOURCE` predefined variable](variables/predefined_variables.md)
|
||||
is `pipeline` for all its jobs.
|
||||
|
||||
If you use [`only/except`](yaml/README.md#only--except) to control job behavior, use the
|
||||
[`pipelines`](yaml/README.md#onlyrefs--exceptrefs) keyword.
|
||||
If you use [`only/except`](yaml/index.md#only--except) to control job behavior, use the
|
||||
[`pipelines`](yaml/index.md#onlyrefs--exceptrefs) keyword.
|
||||
|
||||
#### Mirror status of a triggered pipeline in the trigger job
|
||||
|
||||
|
|
@ -267,10 +267,10 @@ outbound connections for upstream and downstream pipeline dependencies.
|
|||
|
||||
When using:
|
||||
|
||||
- CI/CD variables or [`rules`](yaml/README.md#rulesif) to control job behavior, the value of
|
||||
- CI/CD variables or [`rules`](yaml/index.md#rulesif) to control job behavior, the value of
|
||||
the [`$CI_PIPELINE_SOURCE` predefined variable](variables/predefined_variables.md) is
|
||||
`pipeline` for multi-project pipeline triggered through the API with `CI_JOB_TOKEN`.
|
||||
- [`only/except`](yaml/README.md#only--except) to control job behavior, use the
|
||||
- [`only/except`](yaml/index.md#only--except) to control job behavior, use the
|
||||
`pipelines` keyword.
|
||||
|
||||
## Trigger a pipeline when an upstream project is rebuilt **(PREMIUM)**
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ As pipelines grow more complex, a few related problems start to emerge:
|
|||
job in next stage begins, causes arbitrary waits, slowing things down.
|
||||
- Configuration for the single global pipeline becomes very long and complicated,
|
||||
making it hard to manage.
|
||||
- Imports with [`include`](yaml/README.md#include) increase the complexity of the configuration, and create the potential
|
||||
- Imports with [`include`](yaml/index.md#include) increase the complexity of the configuration, and create the potential
|
||||
for namespace collisions where jobs are unintentionally duplicated.
|
||||
- Pipeline UX can become unwieldy with so many jobs and stages to work with.
|
||||
|
||||
|
|
@ -38,12 +38,12 @@ set of concurrently running child pipelines, but within the same project:
|
|||
|
||||
Child pipelines work well with other GitLab CI/CD features:
|
||||
|
||||
- Use [`rules: changes`](yaml/README.md#ruleschanges) to trigger pipelines only when
|
||||
- Use [`rules: changes`](yaml/index.md#ruleschanges) to trigger pipelines only when
|
||||
certain files change. This is useful for monorepos, for example.
|
||||
- Since the parent pipeline in `.gitlab-ci.yml` and the child pipeline run as normal
|
||||
pipelines, they can have their own behaviors and sequencing in relation to triggers.
|
||||
|
||||
See the [`trigger:`](yaml/README.md#trigger) keyword documentation for full details on how to
|
||||
See the [`trigger:`](yaml/index.md#trigger) keyword documentation for full details on how to
|
||||
include the child pipeline configuration.
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
|
|
@ -51,7 +51,7 @@ For an overview, see [Parent-Child Pipelines feature demo](https://youtu.be/n8Kp
|
|||
|
||||
## Examples
|
||||
|
||||
The simplest case is [triggering a child pipeline](yaml/README.md#trigger) using a
|
||||
The simplest case is [triggering a child pipeline](yaml/index.md#trigger) using a
|
||||
local YAML file to define the pipeline configuration. In this case, the parent pipeline
|
||||
triggers the child pipeline, and continues without waiting:
|
||||
|
||||
|
|
@ -72,7 +72,7 @@ microservice_a:
|
|||
```
|
||||
|
||||
In [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/205157) and later,
|
||||
you can use [`include:file`](yaml/README.md#includefile) to trigger child pipelines
|
||||
you can use [`include:file`](yaml/index.md#includefile) to trigger child pipelines
|
||||
with a configuration file in a different project:
|
||||
|
||||
```yaml
|
||||
|
|
@ -148,7 +148,7 @@ microservice_a:
|
|||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35632) in GitLab 12.9.
|
||||
|
||||
Instead of running a child pipeline from a static YAML file, you can define a job that runs
|
||||
your own script to generate a YAML file, which is then [used to trigger a child pipeline](yaml/README.md#trigger-child-pipeline-with-generated-configuration-file).
|
||||
your own script to generate a YAML file, which is then [used to trigger a child pipeline](yaml/index.md#trigger-child-pipeline-with-generated-configuration-file).
|
||||
|
||||
This technique can be very powerful in generating pipelines targeting content that changed or to
|
||||
build a matrix of targets and architectures.
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ From the pipeline editor page you can:
|
|||
- Select the branch to work from. [Introduced in GitLab 13.12](https://gitlab.com/gitlab-org/gitlab/-/issues/326189), disabled by default.
|
||||
- [Validate](#validate-ci-configuration) your configuration syntax while editing the file.
|
||||
- Do a deeper [lint](#lint-ci-configuration) of your configuration, that verifies it with any configuration
|
||||
added with the [`include`](../yaml/README.md#include) keyword.
|
||||
added with the [`include`](../yaml/index.md#include) keyword.
|
||||
- See a [visualization](#visualize-ci-configuration) of the current configuration.
|
||||
- View an [expanded](#view-expanded-configuration) version of your configuration.
|
||||
- [Commit](#commit-changes-to-ci-configuration) the changes to a specific branch.
|
||||
|
|
@ -58,7 +58,7 @@ reflected in the CI lint. It displays the same results as the existing [CI Lint
|
|||
|
||||
To view a visualization of your `gitlab-ci.yml` configuration, in your project,
|
||||
go to **CI/CD > Editor**, and then select the **Visualize** tab. The
|
||||
visualization shows all stages and jobs. Any [`needs`](../yaml/README.md#needs)
|
||||
visualization shows all stages and jobs. Any [`needs`](../yaml/index.md#needs)
|
||||
relationships are displayed as lines connecting jobs together, showing the
|
||||
hierarchy of execution:
|
||||
|
||||
|
|
@ -80,10 +80,10 @@ To view the fully expanded CI/CD configuration as one combined file, go to the
|
|||
pipeline editor's **View merged YAML** tab. This tab displays an expanded configuration
|
||||
where:
|
||||
|
||||
- Configuration imported with [`include`](../yaml/README.md#include) is copied into the view.
|
||||
- Jobs that use [`extends`](../yaml/README.md#extends) display with the
|
||||
[extended configuration merged into the job](../yaml/README.md#merge-details).
|
||||
- YAML anchors are [replaced with the linked configuration](../yaml/README.md#anchors).
|
||||
- Configuration imported with [`include`](../yaml/index.md#include) is copied into the view.
|
||||
- Jobs that use [`extends`](../yaml/index.md#extends) display with the
|
||||
[extended configuration merged into the job](../yaml/index.md#merge-details).
|
||||
- YAML anchors are [replaced with the linked configuration](../yaml/index.md#anchors).
|
||||
|
||||
## Commit changes to CI configuration
|
||||
|
||||
|
|
|
|||
|
|
@ -67,9 +67,9 @@ Pipelines can be configured in many different ways:
|
|||
Pipelines and their component jobs and stages are defined in the CI/CD pipeline configuration file for each project.
|
||||
|
||||
- [Jobs](../jobs/index.md) are the basic configuration component.
|
||||
- Stages are defined by using the [`stages`](../yaml/README.md#stages) keyword.
|
||||
- Stages are defined by using the [`stages`](../yaml/index.md#stages) keyword.
|
||||
|
||||
For a list of configuration options in the CI pipeline file, see the [GitLab CI/CD Pipeline Configuration Reference](../yaml/README.md).
|
||||
For a list of configuration options in the CI pipeline file, see the [GitLab CI/CD Pipeline Configuration Reference](../yaml/index.md).
|
||||
|
||||
You can also configure specific aspects of your pipelines through the GitLab UI. For example:
|
||||
|
||||
|
|
@ -146,7 +146,7 @@ The pipeline now executes the jobs as configured.
|
|||
|
||||
> [Introduced in](https://gitlab.com/gitlab-org/gitlab/-/issues/30101) GitLab 13.7.
|
||||
|
||||
You can use the [`value` and `description`](../yaml/README.md#prefill-variables-in-manual-pipelines)
|
||||
You can use the [`value` and `description`](../yaml/index.md#prefill-variables-in-manual-pipelines)
|
||||
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.
|
||||
|
|
@ -200,7 +200,7 @@ For each `var` or `file_var`, a key and value are required.
|
|||
|
||||
### Add manual interaction to your pipeline
|
||||
|
||||
Manual actions, configured using the [`when:manual`](../yaml/README.md#whenmanual) keyword,
|
||||
Manual actions, configured using the [`when:manual`](../yaml/index.md#whenmanual) keyword,
|
||||
allow you to require manual interaction before moving forward in the pipeline.
|
||||
|
||||
You can do this straight from the pipeline graph. Just click the play button
|
||||
|
|
@ -347,7 +347,7 @@ You can group the jobs by:
|
|||
|
||||
|
||||
- [Job dependencies](#view-job-dependencies-in-the-pipeline-graph), which arranges
|
||||
jobs based on their [`needs`](../yaml/README.md#needs) dependencies.
|
||||
jobs based on their [`needs`](../yaml/index.md#needs) dependencies.
|
||||
|
||||
[Multi-project pipeline graphs](../multi_project_pipelines.md#multi-project-pipeline-visualization) help
|
||||
you visualize the entire pipeline, including all cross-project inter-dependencies. **(PREMIUM)**
|
||||
|
|
@ -365,7 +365,7 @@ This in-development feature might not be available for your use. There can be
|
|||
[risks when enabling features still in development](../../user/feature_flags.md#risks-when-enabling-features-still-in-development).
|
||||
Refer to this feature's version history for more details.
|
||||
|
||||
You can arrange jobs in the pipeline graph based on their [`needs`](../yaml/README.md#needs)
|
||||
You can arrange jobs in the pipeline graph based on their [`needs`](../yaml/index.md#needs)
|
||||
dependencies.
|
||||
|
||||
Jobs in the leftmost column run first, and jobs that depend on them are grouped in the next columns.
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ is used.
|
|||
If you run two types of pipelines (like branch and scheduled) for the same ref,
|
||||
the pipeline that finishes later creates the job artifact.
|
||||
|
||||
For more examples, view the [keyword reference for the `.gitlab-ci.yml` file](../yaml/README.md#artifacts).
|
||||
For more examples, view the [keyword reference for the `.gitlab-ci.yml` file](../yaml/index.md#artifacts).
|
||||
|
||||
## Download job artifacts
|
||||
|
||||
|
|
@ -173,7 +173,7 @@ https://gitlab.com/gitlab-org/gitlab/-/jobs/artifacts/main/file/htmlcov/index.ht
|
|||
|
||||
## When job artifacts are deleted
|
||||
|
||||
See the [`expire_in`](../yaml/README.md#artifactsexpire_in) documentation for information on when
|
||||
See the [`expire_in`](../yaml/index.md#artifactsexpire_in) documentation for information on when
|
||||
job artifacts are deleted.
|
||||
|
||||
### Keep artifacts from most recent successful jobs
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ own advantages. These methods can be mixed and matched if needed:
|
|||
- [Child/Parent Pipelines](#child--parent-pipelines): Good for monorepos and projects with lots of independently defined components.
|
||||
|
||||
For more details about
|
||||
any of the keywords used below, check out our [CI YAML reference](../yaml/README.md) for details.
|
||||
any of the keywords used below, check out our [CI YAML reference](../yaml/index.md) for details.
|
||||
|
||||
## Basic Pipelines
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ deploy_b:
|
|||
|
||||
If efficiency is important to you and you want everything to run as quickly as possible,
|
||||
you can use [Directed Acyclic Graphs (DAG)](../directed_acyclic_graph/index.md). Use the
|
||||
[`needs` keyword](../yaml/README.md#needs) to define dependency relationships between
|
||||
[`needs` keyword](../yaml/index.md#needs) to define dependency relationships between
|
||||
your jobs. When GitLab knows the relationships between your jobs, it can run everything
|
||||
as fast as possible, and even skips into subsequent stages when possible.
|
||||
|
||||
|
|
@ -163,12 +163,12 @@ deploy_b:
|
|||
|
||||
In the examples above, it's clear we've got two types of things that could be built independently.
|
||||
This is an ideal case for using [Child / Parent Pipelines](../parent_child_pipelines.md)) via
|
||||
the [`trigger` keyword](../yaml/README.md#trigger). It separates out the configuration
|
||||
the [`trigger` keyword](../yaml/index.md#trigger). It separates out the configuration
|
||||
into multiple files, keeping things very simple. You can also combine this with:
|
||||
|
||||
- The [`rules` keyword](../yaml/README.md#rules): For example, have the child pipelines triggered only
|
||||
- The [`rules` keyword](../yaml/index.md#rules): For example, have the child pipelines triggered only
|
||||
when there are changes to that area.
|
||||
- The [`include` keyword](../yaml/README.md#include): Bring in common behaviors, ensuring
|
||||
- The [`include` keyword](../yaml/index.md#include): Bring in common behaviors, ensuring
|
||||
you are not repeating yourself.
|
||||
- [DAG pipelines](#directed-acyclic-graph-pipelines) inside of child pipelines, achieving the benefits of both.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ type: reference, howto
|
|||
|
||||
Pipeline artifacts are files created by GitLab after a pipeline finishes. These are different than [job artifacts](job_artifacts.md) because they are not explicitly managed by the `.gitlab-ci.yml` definitions.
|
||||
|
||||
Pipeline artifacts are used by the [test coverage visualization feature](../../user/project/merge_requests/test_coverage_visualization.md) to collect coverage information. It uses the [`artifacts: reports`](../yaml/README.md#artifactsreports) CI/CD keyword.
|
||||
Pipeline artifacts are used by the [test coverage visualization feature](../../user/project/merge_requests/test_coverage_visualization.md) to collect coverage information. It uses the [`artifacts: reports`](../yaml/index.md#artifactsreports) CI/CD keyword.
|
||||
|
||||
## Storage
|
||||
|
||||
|
|
|
|||
|
|
@ -146,7 +146,7 @@ with embedded metric charts and all valuable details to analyze the problem.
|
|||
|
||||
Review the storage use of the following to help analyze costs and efficiency:
|
||||
|
||||
- [Job artifacts](job_artifacts.md) and their [`expire_in`](../yaml/README.md#artifactsexpire_in)
|
||||
- [Job artifacts](job_artifacts.md) and their [`expire_in`](../yaml/index.md#artifactsexpire_in)
|
||||
configuration. If kept for too long, storage usage grows and could slow pipelines down.
|
||||
- [Container registry](../../user/packages/container_registry/index.md) usage.
|
||||
- [Package registry](../../user/packages/package_registry/index.md) usage.
|
||||
|
|
@ -162,9 +162,9 @@ make pipelines run faster and more efficiently.
|
|||
Try to find which jobs don't need to run in all situations, and use pipeline configuration
|
||||
to stop them from running:
|
||||
|
||||
- Use the [`interruptible`](../yaml/README.md#interruptible) keyword to stop old pipelines
|
||||
- Use the [`interruptible`](../yaml/index.md#interruptible) keyword to stop old pipelines
|
||||
when they are superseded by a newer pipeline.
|
||||
- Use [`rules`](../yaml/README.md#rules) to skip tests that aren't needed. For example,
|
||||
- Use [`rules`](../yaml/index.md#rules) to skip tests that aren't needed. For example,
|
||||
skip backend tests when only the frontend code is changed.
|
||||
- Run non-essential [scheduled pipelines](schedules.md) less frequently.
|
||||
|
||||
|
|
@ -195,7 +195,7 @@ Another optimization method is to [cache](../caching/index.md) dependencies. If
|
|||
dependencies change rarely, like [NodeJS `/node_modules`](../caching/index.md#cache-nodejs-dependencies),
|
||||
caching can make pipeline execution much faster.
|
||||
|
||||
You can use [`cache:when`](../yaml/README.md#cachewhen) to cache downloaded dependencies
|
||||
You can use [`cache:when`](../yaml/index.md#cachewhen) to cache downloaded dependencies
|
||||
even when a job fails.
|
||||
|
||||
### Docker Images
|
||||
|
|
|
|||
|
|
@ -52,14 +52,14 @@ is installed on.
|
|||
### Using variables
|
||||
|
||||
You can pass any number of arbitrary variables. They are available in
|
||||
GitLab CI/CD so that they can be used in your [`.gitlab-ci.yml` file](../../ci/yaml/README.md).
|
||||
GitLab CI/CD so that they can be used in your [`.gitlab-ci.yml` file](../../ci/yaml/index.md).
|
||||
|
||||
|
||||
|
||||
### Using `rules`
|
||||
|
||||
To configure a job to be executed only when the pipeline has been
|
||||
scheduled, use the [`rules`](../yaml/README.md#rules) keyword.
|
||||
scheduled, use the [`rules`](../yaml/index.md#rules) keyword.
|
||||
|
||||
In this example, `make world` runs in scheduled pipelines, and `make build`
|
||||
runs in branch and tag pipelines:
|
||||
|
|
|
|||
|
|
@ -228,7 +228,7 @@ You can set pending or running pipelines to cancel automatically when a new pipe
|
|||
1. Check the **Auto-cancel redundant pipelines** checkbox.
|
||||
1. Click **Save changes**.
|
||||
|
||||
Use the [`interruptible`](../yaml/README.md#interruptible) keyword to indicate if a
|
||||
Use the [`interruptible`](../yaml/index.md#interruptible) keyword to indicate if a
|
||||
running job can be cancelled before it completes.
|
||||
|
||||
## Skip outdated deployment jobs
|
||||
|
|
|
|||
|
|
@ -142,7 +142,7 @@ The pipeline starts when the commit is committed.
|
|||
- You can also use [CI/CD configuration visualization](../pipeline_editor/index.md#visualize-ci-configuration) to
|
||||
view a graphical representation of your `.gitlab-ci.yml` file.
|
||||
- For the complete `.gitlab-ci.yml` syntax, see
|
||||
[the `.gitlab-ci.yml` reference topic](../yaml/README.md).
|
||||
[the `.gitlab-ci.yml` reference topic](../yaml/index.md).
|
||||
|
||||
### View the status of your pipeline and jobs
|
||||
|
||||
|
|
|
|||
|
|
@ -169,13 +169,13 @@ GitLab CI tags are not the same as Git tags. GitLab CI tags are associated with
|
|||
Git tags are associated with commits.
|
||||
|
||||
By tagging a runner for the types of jobs it can handle, you can make sure
|
||||
shared runners will [only run the jobs they are equipped to run](../yaml/README.md#tags).
|
||||
shared runners will [only run the jobs they are equipped to run](../yaml/index.md#tags).
|
||||
|
||||
For instance, at GitLab we have runners tagged with `rails` if they contain
|
||||
the appropriate dependencies to run Rails test suites.
|
||||
|
||||
When you [register a runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick**
|
||||
[tagged jobs](../yaml/README.md#tags).
|
||||
[tagged jobs](../yaml/index.md#tags).
|
||||
To change this, you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project.
|
||||
|
||||
To make a runner pick untagged jobs:
|
||||
|
|
@ -250,7 +250,7 @@ You can also use variables to configure how many times a runner
|
|||
> - `GIT_STRATEGY=none` requires GitLab Runner v1.7+.
|
||||
|
||||
You can set the `GIT_STRATEGY` used to fetch the repository content, either
|
||||
globally or per-job in the [`variables`](../yaml/README.md#variables) section:
|
||||
globally or per-job in the [`variables`](../yaml/index.md#variables) section:
|
||||
|
||||
```yaml
|
||||
variables:
|
||||
|
|
@ -281,7 +281,7 @@ The `kubernetes` executor always clones into an temporary directory.
|
|||
A Git strategy of `none` also re-uses the local working copy, but skips all Git
|
||||
operations normally done by GitLab. GitLab Runner pre-clone scripts are also skipped,
|
||||
if present. This strategy could mean you need to add `fetch` and `checkout` commands
|
||||
to [your `.gitlab-ci.yml` script](../yaml/README.md#script).
|
||||
to [your `.gitlab-ci.yml` script](../yaml/index.md#script).
|
||||
|
||||
It can be used for jobs that operate exclusively on artifacts, like a deployment job.
|
||||
Git repository data may be present, but it's likely out of date. You should only
|
||||
|
|
@ -293,7 +293,7 @@ rely on files brought into the local working copy from cache or artifacts.
|
|||
|
||||
The `GIT_SUBMODULE_STRATEGY` variable is used to control if / how Git
|
||||
submodules are included when fetching the code before a build. You can set them
|
||||
globally or per-job in the [`variables`](../yaml/README.md#variables) section.
|
||||
globally or per-job in the [`variables`](../yaml/index.md#variables) section.
|
||||
|
||||
There are three possible values: `none`, `normal`, and `recursive`:
|
||||
|
||||
|
|
@ -332,7 +332,7 @@ For this feature to work correctly, the submodules must be configured
|
|||
The `GIT_CHECKOUT` variable can be used when the `GIT_STRATEGY` is set to either
|
||||
`clone` or `fetch` to specify whether a `git checkout` should be run. If not
|
||||
specified, it defaults to true. You can set them globally or per-job in the
|
||||
[`variables`](../yaml/README.md#variables) section.
|
||||
[`variables`](../yaml/index.md#variables) section.
|
||||
|
||||
If set to `false`, the runner:
|
||||
|
||||
|
|
@ -360,7 +360,7 @@ script:
|
|||
|
||||
The `GIT_CLEAN_FLAGS` variable is used to control the default behavior of
|
||||
`git clean` after checking out the sources. You can set it globally or per-job in the
|
||||
[`variables`](../yaml/README.md#variables) section.
|
||||
[`variables`](../yaml/index.md#variables) section.
|
||||
|
||||
`GIT_CLEAN_FLAGS` accepts all possible options of the [`git clean`](https://git-scm.com/docs/git-clean)
|
||||
command.
|
||||
|
|
@ -386,7 +386,7 @@ script:
|
|||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) in GitLab Runner 13.1.
|
||||
|
||||
The `GIT_FETCH_EXTRA_FLAGS` variable is used to control the behavior of
|
||||
`git fetch`. You can set it globally or per-job in the [`variables`](../yaml/README.md#variables) section.
|
||||
`git fetch`. You can set it globally or per-job in the [`variables`](../yaml/index.md#variables) section.
|
||||
|
||||
`GIT_FETCH_EXTRA_FLAGS` accepts all options of the [`git fetch`](https://git-scm.com/docs/git-fetch) command. However, `GIT_FETCH_EXTRA_FLAGS` flags are appended after the default flags that can't be modified.
|
||||
|
||||
|
|
@ -450,7 +450,7 @@ variables:
|
|||
GIT_DEPTH: "3"
|
||||
```
|
||||
|
||||
You can set it globally or per-job in the [`variables`](../yaml/README.md#variables) section.
|
||||
You can set it globally or per-job in the [`variables`](../yaml/index.md#variables) section.
|
||||
|
||||
### Custom build directories
|
||||
|
||||
|
|
@ -559,7 +559,7 @@ variables:
|
|||
GET_SOURCES_ATTEMPTS: 3
|
||||
```
|
||||
|
||||
You can set them globally or per-job in the [`variables`](../yaml/README.md#variables) section.
|
||||
You can set them globally or per-job in the [`variables`](../yaml/index.md#variables) section.
|
||||
|
||||
## System calls not available on GitLab.com shared runners
|
||||
|
||||
|
|
|
|||
|
|
@ -273,12 +273,12 @@ test:
|
|||
for maintenance or updates.
|
||||
- The Windows shared runner virtual machine instances do not use the
|
||||
GitLab Docker executor. This means that you can't specify
|
||||
[`image`](../../ci/yaml/README.md#image) or [`services`](../../ci/yaml/README.md#services) in
|
||||
[`image`](../../ci/yaml/index.md#image) or [`services`](../../ci/yaml/index.md#services) in
|
||||
your pipeline configuration.
|
||||
- For the beta release, we have included a set of software packages in
|
||||
the base VM image. If your CI job requires additional software that's
|
||||
not included in this list, then you must add installation
|
||||
commands to [`before_script`](../../ci/yaml/README.md#before_script) or [`script`](../../ci/yaml/README.md#script) to install the required
|
||||
commands to [`before_script`](../../ci/yaml/index.md#before_script) or [`script`](../../ci/yaml/index.md#script) to install the required
|
||||
software. Note that each job runs on a new VM instance, so the
|
||||
installation of additional software packages needs to be repeated for
|
||||
each job in your pipeline.
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ sensitive information can be items like API tokens, database credentials, or pri
|
|||
Secrets are sourced from your secrets provider.
|
||||
|
||||
Unlike CI/CD variables, which are always presented to a job, secrets must be explicitly
|
||||
required by a job. Read [GitLab CI/CD pipeline configuration reference](../yaml/README.md#secrets)
|
||||
required by a job. Read [GitLab CI/CD pipeline configuration reference](../yaml/index.md#secrets)
|
||||
for more information about the syntax.
|
||||
|
||||
GitLab has selected [Vault by HashiCorp](https://www.vaultproject.io) as the
|
||||
|
|
@ -117,7 +117,7 @@ The path to this file is stored in a CI/CD variable named `DATABASE_PASSWORD`,
|
|||
similar to [variables of type `file`](../variables/index.md#cicd-variable-types).
|
||||
|
||||
For more information about the supported syntax, read the
|
||||
[`.gitlab-ci.yml` reference](../yaml/README.md#secretsvault).
|
||||
[`.gitlab-ci.yml` reference](../yaml/index.md#secretsvault).
|
||||
|
||||
## Configure Vault server roles
|
||||
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ to access it. This is where an SSH key pair comes in handy.
|
|||
# - git config --global user.name "User name"
|
||||
```
|
||||
|
||||
The [`before_script`](../yaml/README.md#before_script) can be set globally
|
||||
The [`before_script`](../yaml/index.md#before_script) can be set globally
|
||||
or per-job.
|
||||
|
||||
1. Make sure the private server's [SSH host keys are verified](#verifying-the-ssh-host-keys).
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ depending on which trigger method is used.
|
|||
| `pipeline` | Using the `trigger:` keyword in the CI/CD configuration file, or using the trigger API with `$CI_JOB_TOKEN`. |
|
||||
| `trigger` | Using the trigger API using a generated trigger token |
|
||||
|
||||
This also applies when using the `pipelines` or `triggers` keywords with the legacy [`only/except` basic syntax](../yaml/README.md#only--except).
|
||||
This also applies when using the `pipelines` or `triggers` keywords with the legacy [`only/except` basic syntax](../yaml/index.md#only--except).
|
||||
|
||||
### Trigger token
|
||||
|
||||
|
|
@ -218,7 +218,7 @@ Using trigger variables can be proven useful for a variety of reasons:
|
|||
a certain variable is present.
|
||||
|
||||
Consider the following `.gitlab-ci.yml` where we set three
|
||||
[stages](../yaml/README.md#stages) and the `upload_package` job is run only
|
||||
[stages](../yaml/index.md#stages) and the `upload_package` job is run only
|
||||
when all jobs from the test and build stages pass. When the `UPLOAD_TO_S3`
|
||||
variable is non-zero, `make upload` is run.
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ and check if their values are what you expect.
|
|||
|
||||
## GitLab CI/CD documentation
|
||||
|
||||
The [complete `gitlab-ci.yml` reference](yaml/README.md) contains a full list of
|
||||
The [complete `gitlab-ci.yml` reference](yaml/index.md) contains a full list of
|
||||
every keyword you may need to use to configure your pipelines.
|
||||
|
||||
You can also look at a large number of pipeline configuration [examples](examples/index.md)
|
||||
|
|
@ -105,7 +105,7 @@ If a pipeline does not seem to run at all, with no error message, it may also be
|
|||
due to `rules` or `only/except` configuration, or the `workflow: rules` keyword.
|
||||
|
||||
If you are converting from `only/except` to the `rules` keyword, you should check
|
||||
the [`rules` configuration details](yaml/README.md#rules) carefully. The behavior
|
||||
the [`rules` configuration details](yaml/index.md#rules) carefully. The behavior
|
||||
of `only/except` and `rules` is different and can cause unexpected behavior when migrating
|
||||
between the two.
|
||||
|
||||
|
|
@ -123,8 +123,8 @@ This is usually caused by the `rules` configuration, and there are several ways
|
|||
|
||||
#### A job is not in the pipeline
|
||||
|
||||
GitLab determines if a job is added to a pipeline based on the [`only/except`](yaml/README.md#only--except)
|
||||
or [`rules`](yaml/README.md#rules) defined for the job. If it didn't run, it's probably
|
||||
GitLab determines if a job is added to a pipeline based on the [`only/except`](yaml/index.md#only--except)
|
||||
or [`rules`](yaml/index.md#rules) defined for the job. If it didn't run, it's probably
|
||||
not evaluating as you expect.
|
||||
|
||||
#### No pipeline or the wrong type of pipeline runs
|
||||
|
|
@ -141,7 +141,7 @@ be checked to make sure the jobs are added to the correct pipeline type. For
|
|||
example, if a merge request pipeline did not run, the jobs may have been added to
|
||||
a branch pipeline instead.
|
||||
|
||||
It's also possible that your [`workflow: rules`](yaml/README.md#workflow) configuration
|
||||
It's also possible that your [`workflow: rules`](yaml/index.md#workflow) configuration
|
||||
blocked the pipeline, or allowed the wrong pipeline type.
|
||||
|
||||
### A job runs unexpectedly
|
||||
|
|
@ -150,8 +150,8 @@ A common reason a job is added to a pipeline unexpectedly is because the `change
|
|||
keyword always evaluates to true in certain cases. For example, `changes` is always
|
||||
true in certain pipeline types, including scheduled pipelines and pipelines for tags.
|
||||
|
||||
The `changes` keyword is used in combination with [`only/except`](yaml/README.md#onlychanges--exceptchanges)
|
||||
or [`rules`](yaml/README.md#ruleschanges)). It's recommended to use `changes` with
|
||||
The `changes` keyword is used in combination with [`only/except`](yaml/index.md#onlychanges--exceptchanges)
|
||||
or [`rules`](yaml/index.md#ruleschanges)). It's recommended to use `changes` with
|
||||
`rules` or `only/except` configuration that ensures the job is only added to branch
|
||||
pipelines or merge request pipelines.
|
||||
|
||||
|
|
@ -249,17 +249,17 @@ If the merge train pipeline was canceled before the merge request was merged, wi
|
|||
|
||||
Pipeline configuration warnings are shown when you:
|
||||
|
||||
- [Validate configuration with the CI Lint tool](yaml/README.md).
|
||||
- [Validate configuration with the CI Lint tool](yaml/index.md).
|
||||
- [Manually run a pipeline](pipelines/index.md#run-a-pipeline-manually).
|
||||
|
||||
### "Job may allow multiple pipelines to run for a single action" warning
|
||||
|
||||
When you use [`rules`](yaml/README.md#rules) with a `when:` clause without an `if:`
|
||||
When you use [`rules`](yaml/index.md#rules) with a `when:` clause without an `if:`
|
||||
clause, multiple pipelines may run. Usually this occurs when you push a commit to
|
||||
a branch that has an open merge request associated with it.
|
||||
|
||||
To [prevent duplicate pipelines](jobs/job_control.md#avoid-duplicate-pipelines), use
|
||||
[`workflow: rules`](yaml/README.md#workflow) or rewrite your rules to control
|
||||
[`workflow: rules`](yaml/index.md#workflow) or rewrite your rules to control
|
||||
which pipelines can run.
|
||||
|
||||
### Console workaround if job using resource_group gets stuck
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ Consider the following workflow:
|
|||
## How it works
|
||||
|
||||
First, GitLab Runner uploads all [JUnit report format XML files](https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_14.1.0/com.ibm.rsar.analysis.codereview.cobol.doc/topics/cac_useresults_junit.html)
|
||||
as [artifacts](yaml/README.md#artifactsreportsjunit) to GitLab. Then, when you visit a merge request, GitLab starts
|
||||
as [artifacts](yaml/index.md#artifactsreportsjunit) to GitLab. Then, when you visit a merge request, GitLab starts
|
||||
comparing the head and base branch's JUnit report format XML files, where:
|
||||
|
||||
- The base branch is the target branch (usually the default branch).
|
||||
|
|
@ -77,7 +77,7 @@ If a test failed in the project's default branch in the last 14 days, a message
|
|||
## How to set it up
|
||||
|
||||
To enable the Unit test reports in merge requests, you need to add
|
||||
[`artifacts:reports:junit`](yaml/README.md#artifactsreportsjunit)
|
||||
[`artifacts:reports:junit`](yaml/index.md#artifactsreportsjunit)
|
||||
in `.gitlab-ci.yml`, and specify the path(s) of the generated test reports.
|
||||
The reports must be `.xml` files, otherwise [GitLab returns an Error 500](https://gitlab.com/gitlab-org/gitlab/-/issues/216575).
|
||||
|
||||
|
|
@ -87,8 +87,8 @@ XML reports are stored in GitLab as artifacts and their results are shown in the
|
|||
merge request widget.
|
||||
|
||||
To make the Unit test report output files browsable, include them with the
|
||||
[`artifacts:paths`](yaml/README.md#artifactspaths) keyword as well, as shown in the [Ruby example](#ruby-example).
|
||||
To upload the report even if the job fails (for example if the tests do not pass), use the [`artifacts:when:always`](yaml/README.md#artifactswhen)
|
||||
[`artifacts:paths`](yaml/index.md#artifactspaths) keyword as well, as shown in the [Ruby example](#ruby-example).
|
||||
To upload the report even if the job fails (for example if the tests do not pass), use the [`artifacts:when:always`](yaml/index.md#artifactswhen)
|
||||
keyword.
|
||||
|
||||
You cannot have multiple tests with the same name and class in your JUnit report format XML file.
|
||||
|
|
@ -355,7 +355,7 @@ If parsing JUnit report XML results in an error, an indicator is shown next to t
|
|||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202114) in GitLab 13.0 behind the `:junit_pipeline_screenshots_view` feature flag, disabled by default.
|
||||
> - The feature flag was removed and was [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/216979) in GitLab 13.12.
|
||||
|
||||
Upload your screenshots as [artifacts](yaml/README.md#artifactsreportsjunit) to GitLab. If JUnit
|
||||
Upload your screenshots as [artifacts](yaml/index.md#artifactsreportsjunit) to GitLab. If JUnit
|
||||
report format XML files contain an `attachment` tag, GitLab parses the attachment. Note that:
|
||||
|
||||
- The `attachment` tag **must** contain the relative path to `$CI_PROJECT_DIR` of the screenshots you uploaded. For
|
||||
|
|
@ -368,7 +368,7 @@ report format XML files contain an `attachment` tag, GitLab parses the attachmen
|
|||
```
|
||||
|
||||
- You should set the job that uploads the screenshot to
|
||||
[`artifacts:when: always`](yaml/README.md#artifactswhen) so that it still uploads a screenshot
|
||||
[`artifacts:when: always`](yaml/index.md#artifactswhen) so that it still uploads a screenshot
|
||||
when a test fails.
|
||||
|
||||
A link to the test case attachment appears in the test case details in
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ Make sure each variable is defined for the [scope you want to use it in](where_v
|
|||
|
||||
### Create a custom CI/CD variable in the `.gitlab-ci.yml` file
|
||||
|
||||
To create a custom variable in the [`.gitlab-ci.yml`](../yaml/README.md#variables) file,
|
||||
To create a custom variable in the [`.gitlab-ci.yml`](../yaml/index.md#variables) file,
|
||||
define the variable and value with `variables` keyword.
|
||||
|
||||
You can use the `variables` keyword in a job or at the top level of the `.gitlab-ci.yml` file.
|
||||
|
|
@ -119,7 +119,7 @@ script:
|
|||
- 'eval "$LS_CMD"' # Executes 'ls -al $TMP_DIR'
|
||||
```
|
||||
|
||||
Use the [`value` and `description`](../yaml/README.md#prefill-variables-in-manual-pipelines)
|
||||
Use the [`value` and `description`](../yaml/index.md#prefill-variables-in-manual-pipelines)
|
||||
keywords to define [variables that are prefilled](../pipelines/index.md#prefill-variables-in-manual-pipelines)
|
||||
for [manually-triggered pipelines](../pipelines/index.md#run-a-pipeline-manually).
|
||||
|
||||
|
|
@ -493,13 +493,13 @@ These variables cannot be used as CI/CD variables to configure a pipeline, but
|
|||
they can be used in job scripts.
|
||||
|
||||
1. In the job script, save the variable as a `.env` file.
|
||||
1. Save the `.env` file as an [`artifacts:reports:dotenv`](../yaml/README.md#artifactsreportsdotenv)
|
||||
1. Save the `.env` file as an [`artifacts:reports:dotenv`](../yaml/index.md#artifactsreportsdotenv)
|
||||
artifact.
|
||||
1. Set a job in a later stage to receive the artifact by using the [`dependencies`](../yaml/README.md#dependencies)
|
||||
or the [`needs`](../yaml/README.md#artifact-downloads-with-needs) keywords.
|
||||
1. Set a job in a later stage to receive the artifact by using the [`dependencies`](../yaml/index.md#dependencies)
|
||||
or the [`needs`](../yaml/index.md#artifact-downloads-with-needs) keywords.
|
||||
1. The later job can then [use the variable in scripts](#use-cicd-variables-in-job-scripts).
|
||||
|
||||
For example, with the [`dependencies`](../yaml/README.md#dependencies) keyword:
|
||||
For example, with the [`dependencies`](../yaml/index.md#dependencies) keyword:
|
||||
|
||||
```yaml
|
||||
build:
|
||||
|
|
@ -518,7 +518,7 @@ deploy:
|
|||
- build
|
||||
```
|
||||
|
||||
For example, with the [`needs`](../yaml/README.md#artifact-downloads-with-needs) keyword:
|
||||
For example, with the [`needs`](../yaml/index.md#artifact-downloads-with-needs) keyword:
|
||||
|
||||
```yaml
|
||||
build:
|
||||
|
|
|
|||
|
|
@ -49,10 +49,10 @@ There are also [Kubernetes-specific deployment variables](../../user/project/clu
|
|||
| `CI_DEPLOY_PASSWORD` | 10.8 | all | The authentication password of the [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token), if the project has one. |
|
||||
| `CI_DEPLOY_USER` | 10.8 | all | The authentication username of the [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token), if the project has one. |
|
||||
| `CI_DISPOSABLE_ENVIRONMENT` | all | 10.1 | Only available if the job is executed in a disposable environment (something that is created only for this job and disposed of/destroyed after the execution - all executors except `shell` and `ssh`). `true` when available. |
|
||||
| `CI_ENVIRONMENT_NAME` | 8.15 | all | The name of the environment for this job. Available if [`environment:name`](../yaml/README.md#environmentname) is set. |
|
||||
| `CI_ENVIRONMENT_SLUG` | 8.15 | all | The simplified version of the environment name, suitable for inclusion in DNS, URLs, Kubernetes labels, and so on. Available if [`environment:name`](../yaml/README.md#environmentname) is set. The slug is [truncated to 24 characters](https://gitlab.com/gitlab-org/gitlab/-/issues/20941). |
|
||||
| `CI_ENVIRONMENT_URL` | 9.3 | all | The URL of the environment for this job. Available if [`environment:url`](../yaml/README.md#environmenturl) is set. |
|
||||
| `CI_ENVIRONMENT_ACTION` | 13.11 | all | The action annotation specified for this job's environment. Available if [`environment:action`](../yaml/README.md#environmentaction) is set. Can be `start`, `prepare`, or `stop`. |
|
||||
| `CI_ENVIRONMENT_NAME` | 8.15 | all | The name of the environment for this job. Available if [`environment:name`](../yaml/index.md#environmentname) is set. |
|
||||
| `CI_ENVIRONMENT_SLUG` | 8.15 | all | The simplified version of the environment name, suitable for inclusion in DNS, URLs, Kubernetes labels, and so on. Available if [`environment:name`](../yaml/index.md#environmentname) is set. The slug is [truncated to 24 characters](https://gitlab.com/gitlab-org/gitlab/-/issues/20941). |
|
||||
| `CI_ENVIRONMENT_URL` | 9.3 | all | The URL of the environment for this job. Available if [`environment:url`](../yaml/index.md#environmenturl) is set. |
|
||||
| `CI_ENVIRONMENT_ACTION` | 13.11 | all | The action annotation specified for this job's environment. Available if [`environment:action`](../yaml/index.md#environmentaction) is set. Can be `start`, `prepare`, or `stop`. |
|
||||
| `CI_ENVIRONMENT_TIER` | 14.0 | all | The [deployment tier of the environment](../environments/index.md#deployment-tier-of-environments) for this job. |
|
||||
| `CI_HAS_OPEN_REQUIREMENTS` | 13.1 | all | Only available if the pipeline's project has an open [requirement](../../user/project/requirements/index.md). `true` when available. |
|
||||
| `CI_JOB_ID` | 9.0 | all | The internal ID of the job, unique across all jobs in the GitLab instance. |
|
||||
|
|
@ -61,13 +61,13 @@ There are also [Kubernetes-specific deployment variables](../../user/project/clu
|
|||
| `CI_JOB_MANUAL` | 8.12 | all | `true` if a job was started manually. |
|
||||
| `CI_JOB_NAME` | 9.0 | 0.5 | The name of the job. |
|
||||
| `CI_JOB_STAGE` | 9.0 | 0.5 | The name of the job's stage. |
|
||||
| `CI_JOB_STATUS` | all | 13.5 | The status of the job as each runner stage is executed. Use with [`after_script`](../yaml/README.md#after_script). Can be `success`, `failed`, or `canceled`. |
|
||||
| `CI_JOB_STATUS` | all | 13.5 | The status of the job as each runner stage is executed. Use with [`after_script`](../yaml/index.md#after_script). Can be `success`, `failed`, or `canceled`. |
|
||||
| `CI_JOB_TOKEN` | 9.0 | 1.2 | A token to authenticate with [certain API endpoints](../../api/index.md#gitlab-cicd-job-token). The token is valid as long as the job is running. |
|
||||
| `CI_JOB_URL` | 11.1 | 0.5 | The job details URL. |
|
||||
| `CI_JOB_STARTED_AT` | 13.10 | all | The UTC datetime when a job started, in [ISO 8601](https://tools.ietf.org/html/rfc3339#appendix-A) format. |
|
||||
| `CI_KUBERNETES_ACTIVE` | 13.0 | all | Only available if the pipeline has a Kubernetes cluster available for deployments. `true` when available. |
|
||||
| `CI_NODE_INDEX` | 11.5 | all | The index of the job in the job set. Only available if the job uses [`parallel`](../yaml/README.md#parallel). |
|
||||
| `CI_NODE_TOTAL` | 11.5 | all | The total number of instances of this job running in parallel. Set to `1` if the job does not use [`parallel`](../yaml/README.md#parallel). |
|
||||
| `CI_NODE_INDEX` | 11.5 | all | The index of the job in the job set. Only available if the job uses [`parallel`](../yaml/index.md#parallel). |
|
||||
| `CI_NODE_TOTAL` | 11.5 | all | The total number of instances of this job running in parallel. Set to `1` if the job does not use [`parallel`](../yaml/index.md#parallel). |
|
||||
| `CI_OPEN_MERGE_REQUESTS` | 13.8 | all | A comma-separated list of up to four merge requests that use the current branch and project as the merge request source. Only available in branch and merge request pipelines if the branch has an associated merge request. For example, `gitlab-org/gitlab!333,gitlab-org/gitlab-foss!11`. |
|
||||
| `CI_PAGES_DOMAIN` | 11.8 | all | The configured domain that hosts GitLab Pages. |
|
||||
| `CI_PAGES_URL` | 11.8 | all | The URL for a GitLab Pages site. Always a subdomain of `CI_PAGES_DOMAIN`. |
|
||||
|
|
|
|||
|
|
@ -149,7 +149,7 @@ In the case of `after_script` scripts, they can:
|
|||
- Not use variables defined in `before_script` and `script`.
|
||||
|
||||
These restrictions exist because `after_script` scripts are executed in a
|
||||
[separated shell context](../yaml/README.md#after_script).
|
||||
[separated shell context](../yaml/index.md#after_script).
|
||||
|
||||
## Persisted variables
|
||||
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -13,7 +13,7 @@ type: reference
|
|||
To use GitLab CI/CD, you need:
|
||||
|
||||
- Application code hosted in a Git repository.
|
||||
- A file called [`.gitlab-ci.yml`](README.md) in the root of your repository, which
|
||||
- A file called [`.gitlab-ci.yml`](index.md) in the root of your repository, which
|
||||
contains the CI/CD configuration.
|
||||
|
||||
In the `.gitlab-ci.yml` file, you can define:
|
||||
|
|
@ -27,7 +27,7 @@ In the `.gitlab-ci.yml` file, you can define:
|
|||
|
||||
The scripts are grouped into **jobs**, and jobs run as part of a larger
|
||||
**pipeline**. You can group multiple independent jobs into **stages** that run in a defined order.
|
||||
The CI/CD configuration needs at least one job that is [not hidden](README.md#hide-jobs).
|
||||
The CI/CD configuration needs at least one job that is [not hidden](index.md#hide-jobs).
|
||||
|
||||
You should organize your jobs in a sequence that suits your application and is in accordance with
|
||||
the tests you wish to perform. To [visualize](../pipeline_editor/index.md#visualize-ci-configuration) the process, imagine
|
||||
|
|
@ -89,4 +89,4 @@ If anything goes wrong, you can
|
|||
|
||||
|
||||
|
||||
[View the full syntax for the `.gitlab-ci.yml` file](README.md).
|
||||
[View the full syntax for the `.gitlab-ci.yml` file](index.md).
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@ type: reference
|
|||
|
||||
# GitLab CI/CD include examples **(FREE)**
|
||||
|
||||
In addition to the [`includes` examples](README.md#include) listed in the
|
||||
[GitLab CI YAML reference](README.md), this page lists more variations of `include`
|
||||
In addition to the [`includes` examples](index.md#include) listed in the
|
||||
[GitLab CI YAML reference](index.md), this page lists more variations of `include`
|
||||
usage.
|
||||
|
||||
## Single string or array of multiple values
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -7,7 +7,7 @@ type: reference
|
|||
|
||||
# GitLab CI/CD script syntax **(FREE)**
|
||||
|
||||
You can use special syntax in [`script`](README.md#script) sections to:
|
||||
You can use special syntax in [`script`](index.md#script) sections to:
|
||||
|
||||
- [Split long commands](#split-long-commands) into multiline commands.
|
||||
- [Use color codes](#add-color-codes-to-script-output) to make job logs easier to review.
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ is also available on YouTube.
|
|||
Auto DevOps builds on top of GitLab CI/CD to create an automatic pipeline
|
||||
based on your project contents. When Auto DevOps is enabled for a
|
||||
project, the user does not need to explicitly include any pipeline configuration
|
||||
through a [`.gitlab-ci.yml` file](../ci/yaml/README.md).
|
||||
through a [`.gitlab-ci.yml` file](../ci/yaml/index.md).
|
||||
|
||||
In the absence of a `.gitlab-ci.yml` file, the [Auto DevOps CI
|
||||
template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ Keyword description and main details.
|
|||
|
||||
### YAML reference style example
|
||||
|
||||
See the [`only:changes` / `except:changes`](../../ci/yaml/README.md#onlychanges--exceptchanges)
|
||||
See the [`only:changes` / `except:changes`](../../ci/yaml/index.md#onlychanges--exceptchanges)
|
||||
documentation for an example of the YAML reference style. The following example is a
|
||||
shortened version of that documentation's Markdown:
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Development guides that are specific to CI/CD are listed here.
|
|||
If you are creating new CI/CD templates, please read [the development guide for GitLab CI/CD templates](templates.md).
|
||||
|
||||
See the [CI/CD YAML reference documentation guide](cicd_reference_documentation_guide.md)
|
||||
to learn how to update the [reference page](../../ci/yaml/README.md).
|
||||
to learn how to update the [reference page](../../ci/yaml/index.md).
|
||||
|
||||
## CI Architecture overview
|
||||
|
||||
|
|
@ -33,7 +33,7 @@ On the left side we have the events that can trigger a pipeline based on various
|
|||
- When project is [subscribed to an upstream project](../../ci/multi_project_pipelines.md#trigger-a-pipeline-when-an-upstream-project-is-rebuilt).
|
||||
- When [Auto DevOps](../../topics/autodevops/index.md) is enabled.
|
||||
- When GitHub integration is used with [external pull requests](../../ci/ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests).
|
||||
- When an upstream pipeline contains a [bridge job](../../ci/yaml/README.md#trigger) which triggers a downstream pipeline.
|
||||
- When an upstream pipeline contains a [bridge job](../../ci/yaml/index.md#trigger) which triggers a downstream pipeline.
|
||||
|
||||
Triggering any of these events invokes the [`CreatePipelineService`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/ci/create_pipeline_service.rb)
|
||||
which takes as input event data and the user triggering it, then attempts to create a pipeline.
|
||||
|
|
@ -42,7 +42,7 @@ The `CreatePipelineService` relies heavily on the [`YAML Processor`](https://git
|
|||
component, which is responsible for taking in a YAML blob as input and returns the abstract data structure of a
|
||||
pipeline (including stages and all jobs). This component also validates the structure of the YAML while
|
||||
processing it, and returns any syntax or semantic errors. The `YAML Processor` component is where we define
|
||||
[all the keywords](../../ci/yaml/README.md) available to structure a pipeline.
|
||||
[all the keywords](../../ci/yaml/index.md) available to structure a pipeline.
|
||||
|
||||
The `CreatePipelineService` receives the abstract data structure returned by the `YAML Processor`,
|
||||
which then converts it to persisted models (pipeline, stages, jobs, etc.). After that, the pipeline is ready
|
||||
|
|
@ -79,12 +79,12 @@ case the runner downloads them using a dedicated API endpoint.
|
|||
Artifacts are stored in object storage, while metadata is kept in the database. An important example of artifacts
|
||||
are reports (JUnit, SAST, DAST, etc.) which are parsed and rendered in the merge request.
|
||||
|
||||
Job status transitions are not all automated. A user may run [manual jobs](../../ci/yaml/README.md#whenmanual), cancel a pipeline, retry
|
||||
Job status transitions are not all automated. A user may run [manual jobs](../../ci/yaml/index.md#whenmanual), cancel a pipeline, retry
|
||||
specific failed jobs or the entire pipeline. Anything that
|
||||
causes a job to change status triggers `ProcessPipelineService`, as it's responsible for
|
||||
tracking the status of the entire pipeline.
|
||||
|
||||
A special type of job is the [bridge job](../../ci/yaml/README.md#trigger) which is executed server-side
|
||||
A special type of job is the [bridge job](../../ci/yaml/index.md#trigger) which is executed server-side
|
||||
when transitioning to the `pending` state. This job is responsible for creating a downstream pipeline, such as
|
||||
a multi-project or child pipeline. The workflow loop starts again
|
||||
from the `CreatePipelineService` every time a downstream pipeline is triggered.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Before submitting a merge request with a new or updated CI/CD template, you must
|
|||
- Place the template in the correct [directory](#template-directories).
|
||||
- Follow the [CI/CD template authoring guidelines](#template-authoring-guidelines).
|
||||
- Name the template following the `*.gitlab-ci.yml` format.
|
||||
- Use valid [`.gitlab-ci.yml` syntax](../../ci/yaml/README.md). Verify it's valid
|
||||
- Use valid [`.gitlab-ci.yml` syntax](../../ci/yaml/index.md). Verify it's valid
|
||||
with the [CI/CD lint tool](../../ci/lint.md).
|
||||
- Include [a changelog](../changelog.md) if the merge request introduces a user-facing change.
|
||||
- Follow the [template review process](#contribute-cicd-template-merge-requests).
|
||||
|
|
@ -59,8 +59,8 @@ don't have any other `.gitlab-ci.yml` files.
|
|||
|
||||
When authoring pipeline templates:
|
||||
|
||||
- Place any [global keywords](../../ci/yaml/README.md#global-keywords) like `image`
|
||||
or `before_script` in a [`default`](../../ci/yaml/README.md#custom-default-keyword-values)
|
||||
- Place any [global keywords](../../ci/yaml/index.md#global-keywords) like `image`
|
||||
or `before_script` in a [`default`](../../ci/yaml/index.md#custom-default-keyword-values)
|
||||
section at the top of the template.
|
||||
- Note clearly in the [code comments](#explain-the-template-with-comments) if the
|
||||
template is designed to be used with the `includes` keyword in an existing
|
||||
|
|
@ -68,7 +68,7 @@ When authoring pipeline templates:
|
|||
|
||||
A **job template** provides specific jobs that can be added to an existing CI/CD
|
||||
workflow to accomplish specific tasks. It usually should be used by adding it to
|
||||
an existing `.gitlab-ci.yml` file by using the [`includes`](../../ci/yaml/README.md#global-keywords)
|
||||
an existing `.gitlab-ci.yml` file by using the [`includes`](../../ci/yaml/index.md#global-keywords)
|
||||
keyword. You can also copy and paste the contents into an existing `.gitlab-ci.yml` file.
|
||||
|
||||
Configure job templates so that users can add them to their current pipeline with very
|
||||
|
|
@ -77,7 +77,7 @@ other pipeline configuration.
|
|||
|
||||
When authoring job templates:
|
||||
|
||||
- Do not use [global](../../ci/yaml/README.md#global-keywords) or [`default`](../../ci/yaml/README.md#custom-default-keyword-values)
|
||||
- Do not use [global](../../ci/yaml/index.md#global-keywords) or [`default`](../../ci/yaml/index.md#custom-default-keyword-values)
|
||||
keywords. When a root `.gitlab-ci.yml` includes a template, global or default keywords
|
||||
might be overridden and cause unexpected behavior. If a job template requires a
|
||||
specific stage, explain in the code comments that users must manually add the stage
|
||||
|
|
@ -127,8 +127,8 @@ job2:
|
|||
|
||||
#### Use `rules` instead of `only` or `except`
|
||||
|
||||
Avoid using [`only` or `except`](../../ci/yaml/README.md#only--except) if possible.
|
||||
Only and except is not being developed any more, and [`rules`](../../ci/yaml/README.md#rules)
|
||||
Avoid using [`only` or `except`](../../ci/yaml/index.md#only--except) if possible.
|
||||
Only and except is not being developed any more, and [`rules`](../../ci/yaml/index.md#rules)
|
||||
is now the preferred syntax:
|
||||
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -0,0 +1,104 @@
|
|||
---
|
||||
stage: Enablement
|
||||
group: Sharding
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Multiple Databases
|
||||
|
||||
In order to scale GitLab, the GitLab application database
|
||||
will be [decomposed into multiple
|
||||
databases](https://gitlab.com/groups/gitlab-org/-/epics/6168).
|
||||
|
||||
## CI Database
|
||||
|
||||
Support for configuring the GitLab Rails application to use a distinct
|
||||
database for CI tables was added in [GitLab
|
||||
14.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64289). This
|
||||
feature is still under development, and is not ready for production use.
|
||||
|
||||
By default, GitLab is configured to use only one main database. To
|
||||
opt-in to use a main database, and CI database, modify the
|
||||
`config/database.yml` file to have a `primary` and a `ci` database
|
||||
configurations. For example, given a `config/database.yml` like below:
|
||||
|
||||
```yaml
|
||||
development:
|
||||
adapter: postgresql
|
||||
encoding: unicode
|
||||
database: gitlabhq_development
|
||||
host: /path/to/gdk/postgresql
|
||||
pool: 10
|
||||
prepared_statements: false
|
||||
variables:
|
||||
statement_timeout: 120s
|
||||
|
||||
test: &test
|
||||
adapter: postgresql
|
||||
encoding: unicode
|
||||
database: gitlabhq_test
|
||||
host: /path/to/gdk/postgresql
|
||||
pool: 10
|
||||
prepared_statements: false
|
||||
variables:
|
||||
statement_timeout: 120s
|
||||
```
|
||||
|
||||
Edit the `config/database.yml` to look like this:
|
||||
|
||||
```yaml
|
||||
development:
|
||||
primary:
|
||||
adapter: postgresql
|
||||
encoding: unicode
|
||||
database: gitlabhq_development
|
||||
host: /path/to/gdk/postgresql
|
||||
pool: 10
|
||||
prepared_statements: false
|
||||
variables:
|
||||
statement_timeout: 120s
|
||||
ci:
|
||||
adapter: postgresql
|
||||
encoding: unicode
|
||||
database: gitlabhq_development_ci
|
||||
migrations_paths: db/ci_migrate
|
||||
host: /path/to/gdk/postgresql
|
||||
pool: 10
|
||||
prepared_statements: false
|
||||
variables:
|
||||
statement_timeout: 120s
|
||||
|
||||
test: &test
|
||||
primary:
|
||||
adapter: postgresql
|
||||
encoding: unicode
|
||||
database: gitlabhq_test
|
||||
host: /path/to/gdk/postgresql
|
||||
pool: 10
|
||||
prepared_statements: false
|
||||
variables:
|
||||
statement_timeout: 120s
|
||||
ci:
|
||||
adapter: postgresql
|
||||
encoding: unicode
|
||||
database: gitlabhq_test_ci
|
||||
migrations_paths: db/ci_migrate
|
||||
host: /path/to/gdk/postgresql
|
||||
pool: 10
|
||||
prepared_statements: false
|
||||
variables:
|
||||
statement_timeout: 120s
|
||||
```
|
||||
|
||||
Note that we use `primary` in the `config/database.yml` to refer to the main
|
||||
database. This is to match the default name Rails has.
|
||||
|
||||
### Migrations
|
||||
|
||||
Any migrations that affect `Ci::ApplicationRecord` models
|
||||
and their tables must be placed in two directories for now:
|
||||
|
||||
- `db/migrate`
|
||||
- `db/ci_migrate`
|
||||
|
||||
We aim to keep the schema for both tables the same across both databases.
|
||||
|
|
@ -123,7 +123,7 @@ following:
|
|||
- `tutorial`: Learn a process/concept by doing.
|
||||
[Example page](../../gitlab-basics/start-using-git.md).
|
||||
- `reference`: A collection of information used as a reference to use a feature
|
||||
or a functionality. [Example page](../../ci/yaml/README.md).
|
||||
or a functionality. [Example page](../../ci/yaml/index.md).
|
||||
|
||||
### Redirection metadata
|
||||
|
||||
|
|
@ -475,10 +475,10 @@ If you want to know the in-depth details, here's what's really happening:
|
|||
|
||||
The following GitLab features are used among others:
|
||||
|
||||
- [Manual actions](../../ci/yaml/README.md#whenmanual)
|
||||
- [Manual actions](../../ci/yaml/index.md#whenmanual)
|
||||
- [Multi project pipelines](../../ci/multi_project_pipelines.md)
|
||||
- [Review Apps](../../ci/review_apps/index.md)
|
||||
- [Artifacts](../../ci/yaml/README.md#artifacts)
|
||||
- [Artifacts](../../ci/yaml/index.md#artifacts)
|
||||
- [Specific runner](../../ci/runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
|
||||
- [Pipelines for merge requests](../../ci/merge_request_pipelines/index.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
# Security scanner integration
|
||||
|
||||
Integrating a security scanner into GitLab consists of providing end users
|
||||
with a [CI job definition](../../ci/yaml/README.md)
|
||||
with a [CI job definition](../../ci/yaml/index.md)
|
||||
they can add to their CI configuration files to scan their GitLab projects.
|
||||
This CI job should then output its results in a GitLab-specified format. These results are then
|
||||
automatically presented in various places in GitLab, such as the Pipeline view, Merge Request
|
||||
|
|
@ -23,7 +23,7 @@ scanner, as well as requirements and guidelines for the Docker image.
|
|||
|
||||
This section describes several important fields to add to the security scanner's job
|
||||
definition file. Full documentation on these and other available fields can be viewed
|
||||
in the [CI documentation](../../ci/yaml/README.md#image).
|
||||
in the [CI documentation](../../ci/yaml/index.md#image).
|
||||
|
||||
### Name
|
||||
|
||||
|
|
@ -34,41 +34,41 @@ For instance, the dependency scanning job based on the "MySec" scanner would be
|
|||
|
||||
### Image
|
||||
|
||||
The [`image`](../../ci/yaml/README.md#image) keyword is used to specify
|
||||
The [`image`](../../ci/yaml/index.md#image) keyword is used to specify
|
||||
the [Docker image](../../ci/docker/using_docker_images.md#what-is-an-image)
|
||||
containing the security scanner.
|
||||
|
||||
### Script
|
||||
|
||||
The [`script`](../../ci/yaml/README.md#script) keyword
|
||||
The [`script`](../../ci/yaml/index.md#script) keyword
|
||||
is used to specify the commands to run the scanner.
|
||||
Because the `script` entry can't be left empty, it must be set to the command that performs the scan.
|
||||
It is not possible to rely on the predefined `ENTRYPOINT` and `CMD` of the Docker image
|
||||
to perform the scan automatically, without passing any command.
|
||||
|
||||
The [`before_script`](../../ci/yaml/README.md#before_script)
|
||||
The [`before_script`](../../ci/yaml/index.md#before_script)
|
||||
should not be used in the job definition because users may rely on this to prepare their projects before performing the scan.
|
||||
For instance, it is common practice to use `before_script` to install system libraries
|
||||
a particular project needs before performing SAST or Dependency Scanning.
|
||||
|
||||
Similarly, [`after_script`](../../ci/yaml/README.md#after_script)
|
||||
Similarly, [`after_script`](../../ci/yaml/index.md#after_script)
|
||||
should not be used in the job definition, because it may be overridden by users.
|
||||
|
||||
### Stage
|
||||
|
||||
For consistency, scanning jobs should belong to the `test` stage when possible.
|
||||
The [`stage`](../../ci/yaml/README.md#stage) keyword can be omitted because `test` is the default value.
|
||||
The [`stage`](../../ci/yaml/index.md#stage) keyword can be omitted because `test` is the default value.
|
||||
|
||||
### Fail-safe
|
||||
|
||||
To be aligned with the [GitLab Security paradigm](https://about.gitlab.com/direction/secure/#security-paradigm),
|
||||
scanning jobs should not block the pipeline when they fail,
|
||||
so the [`allow_failure`](../../ci/yaml/README.md#allow_failure) parameter should be set to `true`.
|
||||
so the [`allow_failure`](../../ci/yaml/index.md#allow_failure) parameter should be set to `true`.
|
||||
|
||||
### Artifacts
|
||||
|
||||
Scanning jobs must declare a report that corresponds to the type of scanning they perform,
|
||||
using the [`artifacts:reports`](../../ci/yaml/README.md#artifactsreports) keyword.
|
||||
using the [`artifacts:reports`](../../ci/yaml/index.md#artifactsreports) keyword.
|
||||
Valid reports are: `dependency_scanning`, `container_scanning`, `dast`, `api_fuzzing`, `coverage_fuzzing`, and `sast`.
|
||||
|
||||
For example, here is the definition of a SAST job that generates a file named `gl-sast-report.json`,
|
||||
|
|
@ -209,7 +209,7 @@ It is recommended to name the output file after the type of scanning, and to use
|
|||
Since all Secure reports are JSON files, it is recommended to use `.json` as a file extension.
|
||||
For instance, a suggested filename for a Dependency Scanning report is `gl-dependency-scanning.json`.
|
||||
|
||||
The [`artifacts:reports`](../../ci/yaml/README.md#artifactsreports) keyword
|
||||
The [`artifacts:reports`](../../ci/yaml/index.md#artifactsreports) keyword
|
||||
of the job definition must be consistent with the file path where the Security report is written.
|
||||
For instance, if a Dependency Scanning analyzer writes its report to the CI project directory,
|
||||
and if this report filename is `depscan.json`,
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ and complete an integration with the Secure stage.
|
|||
1. Ensure your pipeline jobs create a report artifact that GitLab can process
|
||||
to successfully display your own product's results with the rest of GitLab.
|
||||
- See detailed [technical directions](secure.md) for this step.
|
||||
- Read more about [job report artifacts](../../ci/yaml/README.md#artifactsreports).
|
||||
- Read more about [job report artifacts](../../ci/yaml/index.md#artifactsreports).
|
||||
- Read about [job artifacts](../../ci/pipelines/job_artifacts.md).
|
||||
- Your report artifact must be in one of our currently supported formats.
|
||||
For more information, see the [documentation on reports](secure.md#report).
|
||||
|
|
|
|||
|
|
@ -14,12 +14,12 @@ which itself includes files under
|
|||
for easier maintenance.
|
||||
|
||||
We're striving to [dogfood](https://about.gitlab.com/handbook/engineering/#dogfooding)
|
||||
GitLab [CI/CD features and best-practices](../ci/yaml/README.md)
|
||||
GitLab [CI/CD features and best-practices](../ci/yaml/index.md)
|
||||
as much as possible.
|
||||
|
||||
## Overview
|
||||
|
||||
Pipelines for the GitLab project are created using the [`workflow:rules` keyword](../ci/yaml/README.md#workflow)
|
||||
Pipelines for the GitLab project are created using the [`workflow:rules` keyword](../ci/yaml/index.md#workflow)
|
||||
feature of the GitLab CI/CD.
|
||||
|
||||
Pipelines are always created for the following scenarios:
|
||||
|
|
@ -49,7 +49,7 @@ depending on the changes made in the MR:
|
|||
- [Frontend-only MR pipeline](#frontend-only-mr-pipeline): This is typically created for an MR that only changes frontend code.
|
||||
- [QA-only MR pipeline](#qa-only-mr-pipeline): This is typically created for an MR that only changes end to end tests related code.
|
||||
|
||||
We use the [`rules:`](../ci/yaml/README.md#rules) and [`needs:`](../ci/yaml/README.md#needs) keywords extensively
|
||||
We use the [`rules:`](../ci/yaml/index.md#rules) and [`needs:`](../ci/yaml/index.md#needs) keywords extensively
|
||||
to determine the jobs that need to be run in a pipeline. Note that an MR that includes multiple types of changes would
|
||||
have a pipelines that include jobs from multiple types (e.g. a combination of docs-only and code-only pipelines).
|
||||
|
||||
|
|
@ -537,7 +537,7 @@ the `gitlab-org/gitlab-foss` project.
|
|||
|
||||
### Interruptible pipelines
|
||||
|
||||
By default, all jobs are [interruptible](../ci/yaml/README.md#interruptible), except the
|
||||
By default, all jobs are [interruptible](../ci/yaml/index.md#interruptible), except the
|
||||
`dont-interrupt-me` job which runs automatically on `main`, and is `manual`
|
||||
otherwise.
|
||||
|
||||
|
|
@ -717,13 +717,13 @@ each pipeline includes default variables defined in
|
|||
|
||||
### Common job definitions
|
||||
|
||||
Most of the jobs [extend from a few CI definitions](../ci/yaml/README.md#extends)
|
||||
Most of the jobs [extend from a few CI definitions](../ci/yaml/index.md#extends)
|
||||
defined in [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml)
|
||||
that are scoped to a single [configuration keyword](../ci/yaml/README.md#job-keywords).
|
||||
that are scoped to a single [configuration keyword](../ci/yaml/index.md#job-keywords).
|
||||
|
||||
| Job definitions | Description |
|
||||
|------------------|-------------|
|
||||
| `.default-retry` | Allows a job to [retry](../ci/yaml/README.md#retry) upon `unknown_failure`, `api_failure`, `runner_system_failure`, `job_execution_timeout`, or `stuck_or_timeout_failure`. |
|
||||
| `.default-retry` | Allows a job to [retry](../ci/yaml/index.md#retry) upon `unknown_failure`, `api_failure`, `runner_system_failure`, `job_execution_timeout`, or `stuck_or_timeout_failure`. |
|
||||
| `.default-before_script` | Allows a job to use a default `before_script` definition suitable for Ruby/Rails tasks that may need a database running (e.g. tests). |
|
||||
| `.setup-test-env-cache` | Allows a job to use a default `cache` definition suitable for setting up test environment for subsequent Ruby/Rails tasks. |
|
||||
| `.rails-cache` | Allows a job to use a default `cache` definition suitable for Ruby/Rails tasks. |
|
||||
|
|
@ -742,16 +742,16 @@ that are scoped to a single [configuration keyword](../ci/yaml/README.md#job-key
|
|||
|
||||
### `rules`, `if:` conditions and `changes:` patterns
|
||||
|
||||
We're using the [`rules` keyword](../ci/yaml/README.md#rules) extensively.
|
||||
We're using the [`rules` keyword](../ci/yaml/index.md#rules) extensively.
|
||||
|
||||
All `rules` definitions are defined in
|
||||
[`rules.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/rules.gitlab-ci.yml),
|
||||
then included in individual jobs via [`extends`](../ci/yaml/README.md#extends).
|
||||
then included in individual jobs via [`extends`](../ci/yaml/index.md#extends).
|
||||
|
||||
The `rules` definitions are composed of `if:` conditions and `changes:` patterns,
|
||||
which are also defined in
|
||||
[`rules.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/rules.gitlab-ci.yml)
|
||||
and included in `rules` definitions via [YAML anchors](../ci/yaml/README.md#anchors)
|
||||
and included in `rules` definitions via [YAML anchors](../ci/yaml/index.md#anchors)
|
||||
|
||||
#### `if:` conditions
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ Have a look at some of our most popular topics:
|
|||
|:-------------------------------------------------------------------------------------------|:------------|
|
||||
| [Two-factor authentication](user/profile/account/two_factor_authentication.md) | Improve the security of your GitLab account. |
|
||||
| [GitLab groups](user/group/index.md) | Manage projects together. |
|
||||
| [GitLab CI/CD pipeline configuration reference](ci/yaml/README.md) | Available configuration options for `.gitlab-ci.yml` files. |
|
||||
| [GitLab CI/CD pipeline configuration reference](ci/yaml/index.md) | Available configuration options for `.gitlab-ci.yml` files. |
|
||||
| [Activate GitLab EE with a license](user/admin_area/license.md) | Activate GitLab Enterprise Edition functionality with a license. |
|
||||
| [Back up and restore GitLab](raketasks/backup_restore.md) | Rake tasks for backing up and restoring GitLab self-managed instances. |
|
||||
| [GitLab release and maintenance policy](policy/maintenance.md) | Policies for version naming and cadence, and also upgrade recommendations. |
|
||||
|
|
|
|||
|
|
@ -841,6 +841,6 @@ If you see this page when trying to set a password via the web interface, make s
|
|||
|
||||
### Some job logs are not uploaded to object storage
|
||||
|
||||
When the GitLab deployment is scaled up to more than one node, some job logs may not be uploaded to [object storage](../../administration/object_storage.md) properly. [Incremental logging is required](../../administration/object_storage.md#incremental-logging-is-required-for-ci-to-use-object-storage) for CI to use object storage.
|
||||
When the GitLab deployment is scaled up to more than one node, some job logs may not be uploaded to [object storage](../../administration/object_storage.md) properly. [Incremental logging is required](../../administration/object_storage.md#other-alternatives-to-file-system-storage) for CI to use object storage.
|
||||
|
||||
Enable [incremental logging](../../administration/job_logs.md#enable-or-disable-incremental-logging) if it has not already been enabled.
|
||||
|
|
|
|||
|
|
@ -187,11 +187,11 @@ to the desired environment. See [Limit environment scope of CI/CD variables](../
|
|||
|
||||
Auto DevOps is completely customizable because the
|
||||
[Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
|
||||
is just an implementation of a [`.gitlab-ci.yml`](../../ci/yaml/README.md) file,
|
||||
is just an implementation of a [`.gitlab-ci.yml`](../../ci/yaml/index.md) file,
|
||||
and uses only features available to any implementation of `.gitlab-ci.yml`.
|
||||
|
||||
To modify the CI/CD pipeline used by Auto DevOps,
|
||||
[`include` the template](../../ci/yaml/README.md#includetemplate), and customize
|
||||
[`include` the template](../../ci/yaml/index.md#includetemplate), and customize
|
||||
it as needed by adding a `.gitlab-ci.yml` file to the root of your repository
|
||||
containing the following:
|
||||
|
||||
|
|
@ -202,7 +202,7 @@ include:
|
|||
|
||||
Add your changes, and your additions are merged with the
|
||||
[Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
|
||||
using the behavior described for [`include`](../../ci/yaml/README.md#include).
|
||||
using the behavior described for [`include`](../../ci/yaml/index.md#include).
|
||||
|
||||
If you need to specifically remove a part of the file, you can also copy and paste the contents of the
|
||||
[Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
|
||||
|
|
@ -254,13 +254,13 @@ include:
|
|||
See the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) for information on available jobs.
|
||||
|
||||
WARNING:
|
||||
Auto DevOps templates using the [`only`](../../ci/yaml/README.md#only--except) or
|
||||
[`except`](../../ci/yaml/README.md#only--except) syntax have switched
|
||||
to the [`rules`](../../ci/yaml/README.md#rules) syntax, starting in
|
||||
Auto DevOps templates using the [`only`](../../ci/yaml/index.md#only--except) or
|
||||
[`except`](../../ci/yaml/index.md#only--except) syntax have switched
|
||||
to the [`rules`](../../ci/yaml/index.md#rules) syntax, starting in
|
||||
[GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/213336).
|
||||
If your `.gitlab-ci.yml` extends these Auto DevOps templates and override the `only` or
|
||||
`except` keywords, you must migrate your templates to use the
|
||||
[`rules`](../../ci/yaml/README.md#rules) syntax after the
|
||||
[`rules`](../../ci/yaml/index.md#rules) syntax after the
|
||||
base template is migrated to use the `rules` syntax.
|
||||
For users who cannot migrate just yet, you can alternatively pin your templates to
|
||||
the [GitLab 12.10 based templates](https://gitlab.com/gitlab-org/auto-devops-v12-10).
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ Since [GitLab 12.7](https://gitlab.com/gitlab-org/gitlab/-/issues/26655),
|
|||
Auto DevOps runs on pipelines automatically only if a [`Dockerfile` or matching buildpack](stages.md#auto-build)
|
||||
exists.
|
||||
|
||||
If a [CI/CD configuration file](../../ci/yaml/README.md) is present in the
|
||||
If a [CI/CD configuration file](../../ci/yaml/index.md) is present in the
|
||||
project, it isn't changed and won't be affected by Auto DevOps.
|
||||
|
||||
### At the project level
|
||||
|
|
|
|||
|
|
@ -125,7 +125,7 @@ only the deployment to Kubernetes runs.
|
|||
WARNING:
|
||||
Setting the `AUTO_DEVOPS_PLATFORM_TARGET` variable to `ECS` triggers jobs
|
||||
defined in the [`Jobs/Deploy/ECS.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy/ECS.gitlab-ci.yml).
|
||||
However, it's not recommended to [include](../../ci/yaml/README.md#includetemplate)
|
||||
However, it's not recommended to [include](../../ci/yaml/index.md#includetemplate)
|
||||
it on its own. This template is designed to be used with Auto DevOps only. It may change
|
||||
unexpectedly causing your pipeline to fail if included on its own. Also, the job
|
||||
names within this template may also change. Do not override these jobs' names in your
|
||||
|
|
|
|||
|
|
@ -31,11 +31,11 @@ are using. First verify which template is in use:
|
|||
- [The GitLab.com stable Auto Deploy template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml)
|
||||
is being used if **one** of the following is true:
|
||||
- Your Auto DevOps project doesn't have a `.gitlab-ci.yml` file.
|
||||
- Your Auto DevOps project has a `.gitlab-ci.yml` and [includes](../../ci/yaml/README.md#includetemplate)
|
||||
- Your Auto DevOps project has a `.gitlab-ci.yml` and [includes](../../ci/yaml/index.md#includetemplate)
|
||||
the `Auto-DevOps.gitlab-ci.yml` template.
|
||||
- [The latest Auto Deploy template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.latest.gitlab-ci.yml)
|
||||
is being used if **both** of the following is true:
|
||||
- Your Auto DevOps project has a `.gitlab-ci.yml` file and [includes](../../ci/yaml/README.md#includetemplate)
|
||||
- Your Auto DevOps project has a `.gitlab-ci.yml` file and [includes](../../ci/yaml/index.md#includetemplate)
|
||||
the `Auto-DevOps.gitlab-ci.yml` template.
|
||||
- It also includes [the latest Auto Deploy template](#early-adopters)
|
||||
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ The setting at all levels is only available to GitLab administrators.
|
|||
|
||||
The default expiration time of the [job artifacts](../../../administration/job_artifacts.md)
|
||||
can be set in the Admin Area of your GitLab instance. The syntax of duration is
|
||||
described in [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in)
|
||||
described in [`artifacts:expire_in`](../../../ci/yaml/index.md#artifactsexpire_in)
|
||||
and the default value is `30 days`.
|
||||
|
||||
1. On the top bar, select **Menu >** **{admin}** **Admin**.
|
||||
|
|
@ -97,7 +97,7 @@ and the default value is `30 days`.
|
|||
1. Click **Save changes** for the changes to take effect.
|
||||
|
||||
This setting is set per job and can be overridden in
|
||||
[`.gitlab-ci.yml`](../../../ci/yaml/README.md#artifactsexpire_in).
|
||||
[`.gitlab-ci.yml`](../../../ci/yaml/index.md#artifactsexpire_in).
|
||||
To disable the expiration, set it to `0`. The default unit is in seconds.
|
||||
|
||||
NOTE:
|
||||
|
|
@ -233,13 +233,13 @@ use a template from:
|
|||
|
||||
NOTE:
|
||||
When you use a configuration defined in an instance template repository,
|
||||
nested [`include:`](../../../ci/yaml/README.md#include) keywords
|
||||
nested [`include:`](../../../ci/yaml/index.md#include) keywords
|
||||
(including `include:file`, `include:local`, `include:remote`, and `include:template`)
|
||||
[do not work](https://gitlab.com/gitlab-org/gitlab/-/issues/35345).
|
||||
|
||||
The project CI/CD configuration merges into the required pipeline configuration when
|
||||
a pipeline runs. The merged configuration is the same as if the required pipeline configuration
|
||||
added the project configuration with the [`include` keyword](../../../ci/yaml/README.md#include).
|
||||
added the project configuration with the [`include` keyword](../../../ci/yaml/index.md#include).
|
||||
To view a project's full merged configuration, [View the merged YAML](../../../ci/pipeline_editor/index.md#view-expanded-configuration)
|
||||
in the pipeline editor.
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue