Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
f7f7703e1e
commit
a9c068633f
|
|
@ -3,6 +3,7 @@ stages:
|
|||
- preflight
|
||||
- prepare
|
||||
- build-images
|
||||
- release-environments
|
||||
- fixtures
|
||||
- lint
|
||||
- test-frontend
|
||||
|
|
@ -14,7 +15,6 @@ stages:
|
|||
- pre-merge
|
||||
- pages
|
||||
- notify
|
||||
- release-environments
|
||||
- benchmark
|
||||
- ai-gateway
|
||||
|
||||
|
|
|
|||
|
|
@ -10,6 +10,7 @@ start-release-environments-security-pipeline:
|
|||
# https://gitlab.com/gitlab-org/gitlab/-/issues/387183
|
||||
needs:
|
||||
- compile-production-assets
|
||||
- build-qa-image
|
||||
inherit:
|
||||
variables:
|
||||
- RUBY_VERSION_DEFAULT
|
||||
|
|
|
|||
|
|
@ -1422,6 +1422,10 @@
|
|||
|
||||
.frontend:rules:compile-test-assets:
|
||||
rules:
|
||||
- <<: *if-dot-com-gitlab-org-schedule
|
||||
variables:
|
||||
BABEL_ENV: "istanbul"
|
||||
CACHE_ASSETS_AS_PACKAGE: "false"
|
||||
- if: '$ENABLE_COMPILE_TEST_ASSETS == "true"'
|
||||
- if: '$ENABLE_RSPEC == "true"'
|
||||
- <<: *if-merge-request-labels-run-all-rspec
|
||||
|
|
@ -1432,10 +1436,6 @@
|
|||
changes: *code-backstage-qa-patterns
|
||||
- <<: *if-default-refs
|
||||
changes: *workhorse-patterns
|
||||
- <<: *if-dot-com-gitlab-org-schedule
|
||||
variables:
|
||||
BABEL_ENV: "istanbul"
|
||||
CACHE_ASSETS_AS_PACKAGE: "false"
|
||||
|
||||
.frontend:rules:eslint-changed-files:
|
||||
rules:
|
||||
|
|
|
|||
2
Gemfile
2
Gemfile
|
|
@ -534,7 +534,7 @@ group :development, :test do
|
|||
gem 'influxdb-client', '~> 3.1', require: false, feature_category: :tooling
|
||||
|
||||
gem 'knapsack', '~> 4.0.0', feature_category: :tooling
|
||||
gem 'gitlab-crystalball', '~> 1.0.0', require: false, feature_category: :tooling
|
||||
gem 'gitlab-crystalball', '~> 1.1.0', require: false, feature_category: :tooling
|
||||
gem 'test_file_finder', '~> 0.3.1', feature_category: :tooling
|
||||
|
||||
gem 'simple_po_parser', '~> 1.1.6', require: false, feature_category: :shared
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@
|
|||
{"name":"gitlab","version":"4.19.0","platform":"ruby","checksum":"3f645e3e195dbc24f0834fbf83e8ccfb2056d8e9712b01a640aad418a6949679"},
|
||||
{"name":"gitlab-chronic","version":"0.10.6","platform":"ruby","checksum":"a244d11a1396d2aac6ae9b2f326adf1605ec1ad20c29f06e8b672047d415a9ac"},
|
||||
{"name":"gitlab-cloud-connector","version":"1.15.0","platform":"ruby","checksum":"19c45cd38e0d8721c61809bb05a4d593a365854bb60bb7e78ad765613d668193"},
|
||||
{"name":"gitlab-crystalball","version":"1.0.0","platform":"ruby","checksum":"74f56646345a5bc130da64ee5c2a90fad1bd70b26b551928676030fddaf76201"},
|
||||
{"name":"gitlab-crystalball","version":"1.1.0","platform":"ruby","checksum":"bd314742a89cad8cb858fec41fc5282ff64ccf262cffa1d5b118f053c5c382a8"},
|
||||
{"name":"gitlab-dangerfiles","version":"4.9.2","platform":"ruby","checksum":"d5c050f685d8720f6e70191a7d1216854d860dbdea5b455f87abe7542e005798"},
|
||||
{"name":"gitlab-experiment","version":"0.9.1","platform":"ruby","checksum":"f230ee742154805a755d5f2539dc44d93cdff08c5bbbb7656018d61f93d01f48"},
|
||||
{"name":"gitlab-fog-azure-rm","version":"2.2.0","platform":"ruby","checksum":"31aa7c2170f57874053144e7f716ec9e15f32e71ffbd2c56753dce46e2e78ba9"},
|
||||
|
|
|
|||
|
|
@ -747,7 +747,7 @@ GEM
|
|||
gitlab-cloud-connector (1.15.0)
|
||||
activesupport (~> 7.0)
|
||||
jwt (~> 2.9.3)
|
||||
gitlab-crystalball (1.0.0)
|
||||
gitlab-crystalball (1.1.0)
|
||||
git (< 4)
|
||||
ostruct (< 1)
|
||||
gitlab-dangerfiles (4.9.2)
|
||||
|
|
@ -2159,7 +2159,7 @@ DEPENDENCIES
|
|||
gitlab-backup-cli!
|
||||
gitlab-chronic (~> 0.10.5)
|
||||
gitlab-cloud-connector (~> 1.14)
|
||||
gitlab-crystalball (~> 1.0.0)
|
||||
gitlab-crystalball (~> 1.1.0)
|
||||
gitlab-dangerfiles (~> 4.9.0)
|
||||
gitlab-duo-workflow-service-client (~> 0.2)!
|
||||
gitlab-experiment (~> 0.9.1)
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@
|
|||
{"name":"gitlab","version":"4.19.0","platform":"ruby","checksum":"3f645e3e195dbc24f0834fbf83e8ccfb2056d8e9712b01a640aad418a6949679"},
|
||||
{"name":"gitlab-chronic","version":"0.10.6","platform":"ruby","checksum":"a244d11a1396d2aac6ae9b2f326adf1605ec1ad20c29f06e8b672047d415a9ac"},
|
||||
{"name":"gitlab-cloud-connector","version":"1.15.0","platform":"ruby","checksum":"19c45cd38e0d8721c61809bb05a4d593a365854bb60bb7e78ad765613d668193"},
|
||||
{"name":"gitlab-crystalball","version":"1.0.0","platform":"ruby","checksum":"74f56646345a5bc130da64ee5c2a90fad1bd70b26b551928676030fddaf76201"},
|
||||
{"name":"gitlab-crystalball","version":"1.1.0","platform":"ruby","checksum":"bd314742a89cad8cb858fec41fc5282ff64ccf262cffa1d5b118f053c5c382a8"},
|
||||
{"name":"gitlab-dangerfiles","version":"4.9.2","platform":"ruby","checksum":"d5c050f685d8720f6e70191a7d1216854d860dbdea5b455f87abe7542e005798"},
|
||||
{"name":"gitlab-experiment","version":"0.9.1","platform":"ruby","checksum":"f230ee742154805a755d5f2539dc44d93cdff08c5bbbb7656018d61f93d01f48"},
|
||||
{"name":"gitlab-fog-azure-rm","version":"2.2.0","platform":"ruby","checksum":"31aa7c2170f57874053144e7f716ec9e15f32e71ffbd2c56753dce46e2e78ba9"},
|
||||
|
|
|
|||
|
|
@ -741,7 +741,7 @@ GEM
|
|||
gitlab-cloud-connector (1.15.0)
|
||||
activesupport (~> 7.0)
|
||||
jwt (~> 2.9.3)
|
||||
gitlab-crystalball (1.0.0)
|
||||
gitlab-crystalball (1.1.0)
|
||||
git (< 4)
|
||||
ostruct (< 1)
|
||||
gitlab-dangerfiles (4.9.2)
|
||||
|
|
@ -2154,7 +2154,7 @@ DEPENDENCIES
|
|||
gitlab-backup-cli!
|
||||
gitlab-chronic (~> 0.10.5)
|
||||
gitlab-cloud-connector (~> 1.14)
|
||||
gitlab-crystalball (~> 1.0.0)
|
||||
gitlab-crystalball (~> 1.1.0)
|
||||
gitlab-dangerfiles (~> 4.9.0)
|
||||
gitlab-duo-workflow-service-client (~> 0.2)!
|
||||
gitlab-experiment (~> 0.9.1)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,41 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module Mutations
|
||||
module Wikis
|
||||
class WikiPageSubscribe < BaseMutation
|
||||
graphql_name 'WikiPageSubscribe'
|
||||
|
||||
argument :id, ::Types::GlobalIDType[::WikiPage::Meta],
|
||||
required: true,
|
||||
description: 'Global ID of the wiki page meta record.'
|
||||
|
||||
argument :subscribed,
|
||||
GraphQL::Types::Boolean,
|
||||
required: true,
|
||||
description: 'Desired state of the subscription.'
|
||||
|
||||
field :wiki_page, ::Types::Wikis::WikiPageType,
|
||||
null: true,
|
||||
description: 'Wiki page after mutation.'
|
||||
|
||||
authorize :update_subscription
|
||||
|
||||
def resolve(args)
|
||||
wiki_page_meta = authorized_find!(id: args[:id])
|
||||
|
||||
update_subscription(wiki_page_meta, args[:subscribed])
|
||||
|
||||
{
|
||||
wiki_page: wiki_page_meta,
|
||||
errors: []
|
||||
}
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
def update_subscription(wiki_page_meta, subscribed_state)
|
||||
wiki_page_meta.set_subscription(current_user, subscribed_state, wiki_page_meta.project)
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
@ -259,6 +259,7 @@ module Types
|
|||
mount_mutation Mutations::BranchRules::Delete, experiment: { milestone: '16.9' }
|
||||
mount_mutation Mutations::Pages::Deployment::Delete, experiment: { milestone: '17.1' }
|
||||
mount_mutation Mutations::Pages::Deployment::Restore, experiment: { milestone: '17.1' }
|
||||
mount_mutation Mutations::Wikis::WikiPageSubscribe, experiment: { milestone: '18.1' }
|
||||
end
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -20,6 +20,14 @@ module Types
|
|||
field :title, GraphQL::Types::String,
|
||||
null: false, description: 'Wiki page title.'
|
||||
|
||||
field :subscribed, GraphQL::Types::Boolean,
|
||||
null: false,
|
||||
description: 'Whether the current user is subscribed to notifications on the wiki page.'
|
||||
|
||||
def subscribed
|
||||
object.subscribed?(current_user, object.project)
|
||||
end
|
||||
|
||||
def web_url
|
||||
Gitlab::UrlBuilder.build(object)
|
||||
end
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
#
|
||||
# Users can subscribe to these models.
|
||||
#
|
||||
# Used by Issue, MergeRequest, Label
|
||||
# Used by Issue, MergeRequest, Label, WikiPage::Meta
|
||||
#
|
||||
|
||||
module Subscribable
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@ class WikiPage
|
|||
include Gitlab::Utils::StrongMemoize
|
||||
include Mentionable
|
||||
include Noteable
|
||||
include Subscribable
|
||||
include Todoable
|
||||
|
||||
self.table_name = 'wiki_page_meta'
|
||||
|
|
|
|||
|
|
@ -9,5 +9,6 @@ class WikiPagePolicy < BasePolicy
|
|||
enable :read_wiki_page
|
||||
enable :read_note
|
||||
enable :create_note
|
||||
enable :update_subscription
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@
|
|||
module Environments
|
||||
# This class creates an environment record for a pipeline job.
|
||||
class CreateForJobService
|
||||
include Gitlab::InternalEventsTracking
|
||||
|
||||
def execute(job)
|
||||
return unless job.is_a?(::Ci::Processable) && job.has_environment_keyword?
|
||||
|
||||
|
|
@ -11,6 +13,8 @@ module Environments
|
|||
if environment.persisted?
|
||||
job.persisted_environment = environment
|
||||
job.assign_attributes(metadata_attributes: { expanded_environment_name: environment.name })
|
||||
|
||||
track_environment_usage(job, environment)
|
||||
else
|
||||
job.assign_attributes(status: :failed, failure_reason: :environment_creation_failure)
|
||||
end
|
||||
|
|
@ -76,5 +80,18 @@ module Environments
|
|||
|
||||
ExpandVariables.expand(cluster_agent_path(job), -> { job.simple_variables.sort_and_expand_all })
|
||||
end
|
||||
|
||||
def track_environment_usage(job, environment)
|
||||
track_internal_event(
|
||||
'create_job_with_environment',
|
||||
user: job.user,
|
||||
project: job.project,
|
||||
additional_properties: {
|
||||
label: job.environment_action,
|
||||
value: environment.id,
|
||||
property: environment.tier
|
||||
}
|
||||
)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -0,0 +1,24 @@
|
|||
---
|
||||
description: Job created that references an environment
|
||||
internal_events: true
|
||||
action: create_job_with_environment
|
||||
identifiers:
|
||||
- project
|
||||
- namespace
|
||||
- user
|
||||
additional_properties:
|
||||
label:
|
||||
description: Environment action
|
||||
property:
|
||||
description: Environment tier
|
||||
value:
|
||||
description: Environment ID
|
||||
product_group: environments
|
||||
product_categories:
|
||||
- environment_management
|
||||
milestone: '18.1'
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/192323
|
||||
tiers:
|
||||
- free
|
||||
- premium
|
||||
- ultimate
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
key_path: redis_hll_counters.count_distinct_project_id_from_create_job_with_environment
|
||||
description: Count of unique projects that created a job referencing an environment
|
||||
product_group: environments
|
||||
product_categories:
|
||||
- environment_management
|
||||
performance_indicator_type: []
|
||||
value_type: number
|
||||
status: active
|
||||
milestone: '18.1'
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/192323
|
||||
time_frame:
|
||||
- 28d
|
||||
- 7d
|
||||
data_source: internal_events
|
||||
data_category: optional
|
||||
tiers:
|
||||
- free
|
||||
- premium
|
||||
- ultimate
|
||||
events:
|
||||
- name: create_job_with_environment
|
||||
unique: project.id
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
key_path: redis_hll_counters.count_distinct_user_id_from_create_job_with_environment
|
||||
description: Count of unique users who created a job that references an environment
|
||||
product_group: environments
|
||||
product_categories:
|
||||
- environment_management
|
||||
performance_indicator_type: []
|
||||
value_type: number
|
||||
status: active
|
||||
milestone: '18.1'
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/192323
|
||||
time_frame:
|
||||
- 28d
|
||||
- 7d
|
||||
data_source: internal_events
|
||||
data_category: optional
|
||||
tiers:
|
||||
- free
|
||||
- premium
|
||||
- ultimate
|
||||
events:
|
||||
- name: create_job_with_environment
|
||||
unique: user.id
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
key_path: redis_hll_counters.count_distinct_value_from_create_job_with_environment
|
||||
description: Count of unique environment IDs from jobs that referenced environments
|
||||
product_group: environments
|
||||
product_categories:
|
||||
- environment_management
|
||||
performance_indicator_type: []
|
||||
value_type: number
|
||||
status: active
|
||||
milestone: '18.1'
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/192323
|
||||
time_frame:
|
||||
- 28d
|
||||
- 7d
|
||||
data_source: internal_events
|
||||
data_category: optional
|
||||
tiers:
|
||||
- free
|
||||
- premium
|
||||
- ultimate
|
||||
events:
|
||||
- name: create_job_with_environment
|
||||
unique: value
|
||||
|
|
@ -12708,6 +12708,31 @@ Input type: `VulnerabilityRevertToDetectedInput`
|
|||
| <a id="mutationvulnerabilityreverttodetectederrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during the mutation. |
|
||||
| <a id="mutationvulnerabilityreverttodetectedvulnerability"></a>`vulnerability` | [`Vulnerability`](#vulnerability) | Vulnerability after state change. |
|
||||
|
||||
### `Mutation.wikiPageSubscribe`
|
||||
|
||||
{{< details >}}
|
||||
**Introduced** in GitLab 18.1.
|
||||
**Status**: Experiment.
|
||||
{{< /details >}}
|
||||
|
||||
Input type: `WikiPageSubscribeInput`
|
||||
|
||||
#### Arguments
|
||||
|
||||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="mutationwikipagesubscribeclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
|
||||
| <a id="mutationwikipagesubscribeid"></a>`id` | [`WikiPageMetaID!`](#wikipagemetaid) | Global ID of the wiki page meta record. |
|
||||
| <a id="mutationwikipagesubscribesubscribed"></a>`subscribed` | [`Boolean!`](#boolean) | Desired state of the subscription. |
|
||||
|
||||
#### Fields
|
||||
|
||||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="mutationwikipagesubscribeclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
|
||||
| <a id="mutationwikipagesubscribeerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during the mutation. |
|
||||
| <a id="mutationwikipagesubscribewikipage"></a>`wikiPage` | [`WikiPage`](#wikipage) | Wiki page after mutation. |
|
||||
|
||||
### `Mutation.workItemAddClosingMergeRequest`
|
||||
|
||||
Adds a closing merge request to a work item.
|
||||
|
|
@ -42275,6 +42300,7 @@ A wiki page.
|
|||
| <a id="wikipagediscussions"></a>`discussions` | [`DiscussionConnection!`](#discussionconnection) | All discussions on the noteable. (see [Connections](#connections)) |
|
||||
| <a id="wikipageid"></a>`id` | [`WikiPageMetaID!`](#wikipagemetaid) | Global ID of the wiki page metadata record. |
|
||||
| <a id="wikipagename"></a>`name` | [`String`](#string) | Name or title of the object. |
|
||||
| <a id="wikipagesubscribed"></a>`subscribed` | [`Boolean!`](#boolean) | Whether the current user is subscribed to notifications on the wiki page. |
|
||||
| <a id="wikipagetitle"></a>`title` | [`String!`](#string) | Wiki page title. |
|
||||
| <a id="wikipageuserpermissions"></a>`userPermissions` | [`WikiPagePermissions!`](#wikipagepermissions) | Permissions for the current user on the resource. |
|
||||
| <a id="wikipageweburl"></a>`webUrl` | [`String`](#string) | URL of the object. |
|
||||
|
|
|
|||
|
|
@ -841,7 +841,7 @@ the ones defined in the upstream project take precedence.
|
|||
|
||||
{{< /details >}}
|
||||
|
||||
You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](../variables/_index.md#pass-an-environment-variable-to-another-job).
|
||||
You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](../variables/job_scripts.md#pass-an-environment-variable-to-another-job).
|
||||
|
||||
For example, in a [multi-project pipeline](#multi-project-pipelines):
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ If no jobs in the child pipeline can run due to missing or incorrect `rules` con
|
|||
|
||||
## Variable with `$` character does not get passed to a downstream pipeline properly
|
||||
|
||||
You cannot use [`$$` to escape the `$` character in a CI/CD variable](../variables/_index.md#use-the--character-in-cicd-variables),
|
||||
You cannot use [`$$` to escape the `$` character in a CI/CD variable](../variables/job_scripts.md#use-the--character-in-cicd-variables),
|
||||
when [passing a CI/CD variable to a downstream pipeline](downstream_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline).
|
||||
The downstream pipeline still treats the `$` as the start of a variable reference.
|
||||
|
||||
|
|
|
|||
|
|
@ -310,7 +310,12 @@ You can also use or adapt the [documented Ruff GitLab CI/CD integration](https:/
|
|||
If you already have a [`golangci-lint`](https://golangci-lint.run/) job in your CI/CD pipelines, you should add a report to send its output to Code Quality.
|
||||
To integrate its output:
|
||||
|
||||
1. Add the arguments `--out-format code-climate:gl-code-quality-report.json,line-number` to the command you use to run golangci-lint.
|
||||
1. Add the arguments to the command you use to run `golangci-lint`.
|
||||
|
||||
For v1 add `--out-format code-climate:gl-code-quality-report.json,line-number`.
|
||||
|
||||
For v2 add `--output.code-climate.path=gl-code-quality-report.json`.
|
||||
|
||||
1. Declare a [`codequality` report artifact](../yaml/artifacts_reports.md#artifactsreportscodequality) that points to the location of the report file.
|
||||
|
||||
You can also use or adapt the [golangci-lint CI/CD component](https://gitlab.com/explore/catalog/components/code-quality-oss/codequality-os-scanners-integration) to run the scan and integrate its output with Code Quality.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ description: Configuration, usage, and security.
|
|||
CI/CD variables are a type of environment variable. You can use them to:
|
||||
|
||||
- Control the behavior of jobs and [pipelines](../pipelines/_index.md).
|
||||
- Store values you want to re-use.
|
||||
- Store values you want to re-use, for example in [job scripts](job_scripts.md).
|
||||
- Avoid hard-coding values in your `.gitlab-ci.yml` file.
|
||||
|
||||
You can [override variable values](#cicd-variable-precedence) for a specific pipeline when you [run a pipeline manually](../pipelines/_index.md#run-a-pipeline-manually), [run a manual job](../jobs/job_control.md#specify-variables-when-running-manual-jobs),
|
||||
|
|
@ -209,7 +209,7 @@ To add or update variables in the project settings:
|
|||
or [**Masked and hidden**](#hide-a-cicd-variable) (only available for new variables).
|
||||
|
||||
After you create a variable, you can use it in the pipeline configuration
|
||||
or in [job scripts](#use-cicd-variables-in-job-scripts).
|
||||
or in [job scripts](job_scripts.md).
|
||||
|
||||
### For a group
|
||||
|
||||
|
|
@ -505,297 +505,7 @@ job:
|
|||
- mytool --url-file="site-url.txt"
|
||||
```
|
||||
|
||||
## Use CI/CD variables in job scripts
|
||||
|
||||
All CI/CD variables are set as environment variables in the job's environment.
|
||||
You can use variables in job scripts with the standard formatting for each environment's
|
||||
shell.
|
||||
|
||||
To access environment variables, use the syntax for your [runner executor's shell](https://docs.gitlab.com/runner/executors/).
|
||||
|
||||
### With Bash, `sh` and similar
|
||||
|
||||
To access environment variables in Bash, `sh`, and similar shells, prefix the
|
||||
CI/CD variable with (`$`):
|
||||
|
||||
```yaml
|
||||
job_name:
|
||||
script:
|
||||
- echo "$CI_JOB_ID"
|
||||
```
|
||||
|
||||
### With PowerShell
|
||||
|
||||
To access variables in a Windows PowerShell environment, including environment
|
||||
variables set by the system, prefix the variable name with `$env:` or `$`:
|
||||
|
||||
```yaml
|
||||
job_name:
|
||||
script:
|
||||
- echo $env:CI_JOB_ID
|
||||
- echo $CI_JOB_ID
|
||||
- echo $env:PATH
|
||||
```
|
||||
|
||||
In [some cases](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4115#note_157692820)
|
||||
environment variables must be surrounded by quotes to expand properly:
|
||||
|
||||
```yaml
|
||||
job_name:
|
||||
script:
|
||||
- D:\\qislsf\\apache-ant-1.10.5\\bin\\ant.bat "-DsosposDailyUsr=$env:SOSPOS_DAILY_USR" portal_test
|
||||
```
|
||||
|
||||
### With Windows Batch
|
||||
|
||||
To access CI/CD variables in Windows Batch, surround the variable with `%`:
|
||||
|
||||
```yaml
|
||||
job_name:
|
||||
script:
|
||||
- echo %CI_JOB_ID%
|
||||
```
|
||||
|
||||
You can also surround the variable with `!` for [delayed expansion](https://ss64.com/nt/delayedexpansion.html).
|
||||
Delayed expansion might be needed for variables that contain white spaces or newlines:
|
||||
|
||||
```yaml
|
||||
job_name:
|
||||
script:
|
||||
- echo !ERROR_MESSAGE!
|
||||
```
|
||||
|
||||
### In service containers
|
||||
|
||||
[Service containers](../docker/using_docker_images.md) can use CI/CD variables, but
|
||||
by default can only access [variables saved in the `.gitlab-ci.yml` file](#define-a-cicd-variable-in-the-gitlab-ciyml-file).
|
||||
Variables [added in the GitLab UI](#define-a-cicd-variable-in-the-ui) are not available to
|
||||
service containers, because service containers are not trusted by default.
|
||||
|
||||
To make a UI-defined variable available in a service container, you can re-assign
|
||||
it to another variable in your `.gitlab-ci.yml`:
|
||||
|
||||
```yaml
|
||||
variables:
|
||||
SA_PASSWORD_YAML_FILE: $SA_PASSWORD_UI
|
||||
```
|
||||
|
||||
The re-assigned variable cannot have the same name as the original variable. Otherwise it does not get expanded.
|
||||
|
||||
### Pass an environment variable to another job
|
||||
|
||||
You can create a new environment variable in a job, and pass it to another job
|
||||
in a later stage. These variables cannot be used as CI/CD variables to configure a pipeline
|
||||
(for example with the [`rules` keyword](../yaml/_index.md#rules)), but they can be used in job scripts.
|
||||
|
||||
To pass a job-created environment variable to other jobs:
|
||||
|
||||
1. In the job script, save the variable as a `.env` file.
|
||||
- The format of the file must be one variable definition per line.
|
||||
- Each line must be formatted as: `VARIABLE_NAME=ANY VALUE HERE`.
|
||||
- Values can be wrapped in quotes, but cannot contain newline characters.
|
||||
1. Save the `.env` file as an [`artifacts:reports:dotenv`](../yaml/artifacts_reports.md#artifactsreportsdotenv)
|
||||
artifact.
|
||||
1. Jobs in later stages can then [use the variable in scripts](#use-cicd-variables-in-job-scripts),
|
||||
unless [jobs are configured not to receive `dotenv` variables](#control-which-jobs-receive-dotenv-variables).
|
||||
|
||||
For example:
|
||||
|
||||
```yaml
|
||||
build-job:
|
||||
stage: build
|
||||
script:
|
||||
- echo "BUILD_VARIABLE=value_from_build_job" >> build.env
|
||||
artifacts:
|
||||
reports:
|
||||
dotenv: build.env
|
||||
|
||||
test-job:
|
||||
stage: test
|
||||
script:
|
||||
- echo "$BUILD_VARIABLE" # Output is: 'value_from_build_job'
|
||||
```
|
||||
|
||||
Variables from `dotenv` reports [take precedence](#cicd-variable-precedence) over
|
||||
certain types of new variable definitions such as job defined variables.
|
||||
|
||||
You can also [pass `dotenv` variables to downstream pipelines](../pipelines/downstream_pipelines.md#pass-dotenv-variables-created-in-a-job).
|
||||
|
||||
#### Control which jobs receive `dotenv` variables
|
||||
|
||||
You can use the [`dependencies`](../yaml/_index.md#dependencies) or [`needs`](../yaml/_index.md#needs)
|
||||
keywords to control which jobs receive the `dotenv` artifacts.
|
||||
|
||||
To have no environment variables from a `dotenv` artifact:
|
||||
|
||||
- Pass an empty `dependencies` or `needs` array.
|
||||
- Pass [`needs:artifacts`](../yaml/_index.md#needsartifacts) as `false`.
|
||||
- Set `needs` to only list jobs that do not have a `dotenv` artifact.
|
||||
|
||||
For example:
|
||||
|
||||
```yaml
|
||||
build-job1:
|
||||
stage: build
|
||||
script:
|
||||
- echo "BUILD_VERSION=v1.0.0" >> build.env
|
||||
artifacts:
|
||||
reports:
|
||||
dotenv: build.env
|
||||
|
||||
build-job2:
|
||||
stage: build
|
||||
needs: []
|
||||
script:
|
||||
- echo "This job has no dotenv artifacts"
|
||||
|
||||
test-job1:
|
||||
stage: test
|
||||
script:
|
||||
- echo "$BUILD_VERSION" # Output is: 'v1.0.0'
|
||||
dependencies:
|
||||
- build-job1
|
||||
|
||||
test-job2:
|
||||
stage: test
|
||||
script:
|
||||
- echo "$BUILD_VERSION" # Output is ''
|
||||
dependencies: []
|
||||
|
||||
test-job3:
|
||||
stage: test
|
||||
script:
|
||||
- echo "$BUILD_VERSION" # Output is: 'v1.0.0'
|
||||
needs:
|
||||
- build-job1
|
||||
|
||||
test-job4:
|
||||
stage: test
|
||||
script:
|
||||
- echo "$BUILD_VERSION" # Output is: 'v1.0.0'
|
||||
needs:
|
||||
- job: build-job1
|
||||
artifacts: true
|
||||
|
||||
test-job5:
|
||||
stage: deploy
|
||||
script:
|
||||
- echo "$BUILD_VERSION" # Output is ''
|
||||
needs:
|
||||
- job: build-job1
|
||||
artifacts: false
|
||||
|
||||
test-job6:
|
||||
stage: deploy
|
||||
script:
|
||||
- echo "$BUILD_VERSION" # Output is ''
|
||||
needs:
|
||||
- build-job2
|
||||
```
|
||||
|
||||
### Pass an environment variable from the `script` section to another section in the same job
|
||||
|
||||
Use `$GITLAB_ENV` to pass environment variables defined in the `script` section to another section.
|
||||
|
||||
For example:
|
||||
|
||||
```yaml
|
||||
build-job:
|
||||
stage: build
|
||||
script:
|
||||
- echo "ARCH=$(arch)" >> $GITLAB_ENV
|
||||
- touch some-file-$(arch)
|
||||
artifacts:
|
||||
paths:
|
||||
- some-file-$ARCH
|
||||
```
|
||||
|
||||
To also reference the variable in other stages, write the variable to both the `$GITLAB_ENV` and `.env` files:
|
||||
|
||||
```yaml
|
||||
build-job:
|
||||
stage: build
|
||||
script:
|
||||
- echo "ARCH=$(arch)" | tee -a $GITLAB_ENV >> build.env
|
||||
- touch some-file-$(arch)
|
||||
artifacts:
|
||||
paths:
|
||||
- some-file-$ARCH
|
||||
reports:
|
||||
dotenv: build.env
|
||||
|
||||
release-job:
|
||||
stage: release
|
||||
script:
|
||||
- curl --upload-file some-file-$ARCH "https://example.com/some-file-$ARCH"
|
||||
```
|
||||
|
||||
### Store multiple values in one variable
|
||||
|
||||
You cannot create a CI/CD variable that is an array of values, but you
|
||||
can use shell scripting techniques for similar behavior.
|
||||
|
||||
For example, you can store multiple values separated by a space in a variable,
|
||||
then loop through the values with a script:
|
||||
|
||||
```yaml
|
||||
job1:
|
||||
variables:
|
||||
FOLDERS: src test docs
|
||||
script:
|
||||
- |
|
||||
for FOLDER in $FOLDERS
|
||||
do
|
||||
echo "The path is root/${FOLDER}"
|
||||
done
|
||||
```
|
||||
|
||||
### As part of a string
|
||||
|
||||
You can use variables as part of a string. You can surround the variables with curly brackets (`{}`)
|
||||
to help distinguish the variable name from the surrounding text. Without curly brackets,
|
||||
the adjacent text is interpreted as part of the variable name. For example:
|
||||
|
||||
```yaml
|
||||
job:
|
||||
variables:
|
||||
FLAGS: '-al'
|
||||
DIR: 'path/to/directory'
|
||||
LS_CMD: 'ls "$FLAGS"'
|
||||
CD_CMD: 'cd "${DIR}_files"'
|
||||
script:
|
||||
- 'eval "$LS_CMD"' # Executes 'ls -al'
|
||||
- 'eval "$CD_CMD"' # Executes 'cd path/to/directory_files'
|
||||
```
|
||||
|
||||
## Use CI/CD variables in other variables
|
||||
|
||||
You can use variables inside other variables:
|
||||
|
||||
```yaml
|
||||
job:
|
||||
variables:
|
||||
FLAGS: '-al'
|
||||
LS_CMD: 'ls "$FLAGS"'
|
||||
script:
|
||||
- 'eval "$LS_CMD"' # Executes 'ls -al'
|
||||
```
|
||||
|
||||
### Use the `$` character in CI/CD variables
|
||||
|
||||
If you do not want the `$` character interpreted as the start of another variable,
|
||||
use `$$` instead:
|
||||
|
||||
```yaml
|
||||
job:
|
||||
variables:
|
||||
FLAGS: '-al'
|
||||
LS_CMD: 'ls "$FLAGS" $$TMP_DIR'
|
||||
script:
|
||||
- 'eval "$LS_CMD"' # Executes 'ls -al $TMP_DIR'
|
||||
```
|
||||
|
||||
### Prevent CI/CD variable expansion
|
||||
## Prevent CI/CD variable expansion
|
||||
|
||||
{{< history >}}
|
||||
|
||||
|
|
@ -848,7 +558,7 @@ The order of precedence for variables is (from highest to lowest):
|
|||
you have `Group > Subgroup 1 > Subgroup 2 > Project`, the variable defined in
|
||||
`Subgroup 2` takes precedence.
|
||||
1. Instance [variables](#for-an-instance).
|
||||
1. [Variables from `dotenv` reports](#pass-an-environment-variable-to-another-job).
|
||||
1. [Variables from `dotenv` reports](job_scripts.md#pass-an-environment-variable-to-another-job).
|
||||
1. Job variables, defined in jobs in the `.gitlab-ci.yml` file.
|
||||
1. Default variables for all jobs, defined at the top-level of the `.gitlab-ci.yml` file.
|
||||
1. [Deployment variables](predefined_variables.md#deployment-variables).
|
||||
|
|
|
|||
|
|
@ -0,0 +1,287 @@
|
|||
---
|
||||
stage: Verify
|
||||
group: Pipeline Authoring
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
title: Use CI/CD variables in job scripts
|
||||
description: Configuration, usage, and security.
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
|
||||
- Tier: Free, Premium, Ultimate
|
||||
- Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
All CI/CD variables are set as environment variables in the job's environment.
|
||||
You can use variables in job scripts with the standard formatting for each environment's
|
||||
shell.
|
||||
|
||||
To access environment variables, use the syntax for your [runner executor's shell](https://docs.gitlab.com/runner/executors/).
|
||||
|
||||
## With Bash, `sh` and similar
|
||||
|
||||
To access environment variables in Bash, `sh`, and similar shells, prefix the
|
||||
CI/CD variable with (`$`):
|
||||
|
||||
```yaml
|
||||
job_name:
|
||||
script:
|
||||
- echo "$CI_JOB_ID"
|
||||
```
|
||||
|
||||
## With PowerShell
|
||||
|
||||
To access variables in a Windows PowerShell environment, including environment
|
||||
variables set by the system, prefix the variable name with `$env:` or `$`:
|
||||
|
||||
```yaml
|
||||
job_name:
|
||||
script:
|
||||
- echo $env:CI_JOB_ID
|
||||
- echo $CI_JOB_ID
|
||||
- echo $env:PATH
|
||||
```
|
||||
|
||||
In [some cases](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4115#note_157692820)
|
||||
environment variables must be surrounded by quotes to expand properly:
|
||||
|
||||
```yaml
|
||||
job_name:
|
||||
script:
|
||||
- D:\\qislsf\\apache-ant-1.10.5\\bin\\ant.bat "-DsosposDailyUsr=$env:SOSPOS_DAILY_USR" portal_test
|
||||
```
|
||||
|
||||
## With Windows Batch
|
||||
|
||||
To access CI/CD variables in Windows Batch, surround the variable with `%`:
|
||||
|
||||
```yaml
|
||||
job_name:
|
||||
script:
|
||||
- echo %CI_JOB_ID%
|
||||
```
|
||||
|
||||
You can also surround the variable with `!` for [delayed expansion](https://ss64.com/nt/delayedexpansion.html).
|
||||
Delayed expansion might be needed for variables that contain white spaces or newlines:
|
||||
|
||||
```yaml
|
||||
job_name:
|
||||
script:
|
||||
- echo !ERROR_MESSAGE!
|
||||
```
|
||||
|
||||
## In service containers
|
||||
|
||||
[Service containers](../docker/using_docker_images.md) can use CI/CD variables, but
|
||||
by default can only access [variables saved in the `.gitlab-ci.yml` file](_index.md#define-a-cicd-variable-in-the-gitlab-ciyml-file).
|
||||
Variables [added in the GitLab UI](_index.md#define-a-cicd-variable-in-the-ui) are not available to
|
||||
service containers, because service containers are not trusted by default.
|
||||
|
||||
To make a UI-defined variable available in a service container, you can re-assign
|
||||
it to another variable in your `.gitlab-ci.yml`:
|
||||
|
||||
```yaml
|
||||
variables:
|
||||
SA_PASSWORD_YAML_FILE: $SA_PASSWORD_UI
|
||||
```
|
||||
|
||||
The re-assigned variable cannot have the same name as the original variable. Otherwise it does not get expanded.
|
||||
|
||||
## Pass an environment variable to another job
|
||||
|
||||
You can create a new environment variable in a job, and pass it to another job
|
||||
in a later stage. These variables cannot be used as CI/CD variables to configure a pipeline
|
||||
(for example with the [`rules` keyword](../yaml/_index.md#rules)), but they can be used in job scripts.
|
||||
|
||||
To pass a job-created environment variable to other jobs:
|
||||
|
||||
1. In the job script, save the variable as a `.env` file.
|
||||
- The format of the file must be one variable definition per line.
|
||||
- Each line must be formatted as: `VARIABLE_NAME=ANY VALUE HERE`.
|
||||
- Values can be wrapped in quotes, but cannot contain newline characters.
|
||||
1. Save the `.env` file as an [`artifacts:reports:dotenv`](../yaml/artifacts_reports.md#artifactsreportsdotenv)
|
||||
artifact.
|
||||
1. Jobs in later stages can then use the variable in scripts, unless
|
||||
[jobs are configured to not receive `dotenv` variables](#control-which-jobs-receive-dotenv-variables).
|
||||
|
||||
For example:
|
||||
|
||||
```yaml
|
||||
build-job:
|
||||
stage: build
|
||||
script:
|
||||
- echo "BUILD_VARIABLE=value_from_build_job" >> build.env
|
||||
artifacts:
|
||||
reports:
|
||||
dotenv: build.env
|
||||
|
||||
test-job:
|
||||
stage: test
|
||||
script:
|
||||
- echo "$BUILD_VARIABLE" # Output is: 'value_from_build_job'
|
||||
```
|
||||
|
||||
Variables from `dotenv` reports [take precedence](_index.md#cicd-variable-precedence) over
|
||||
certain types of new variable definitions such as job defined variables.
|
||||
|
||||
You can also [pass `dotenv` variables to downstream pipelines](../pipelines/downstream_pipelines.md#pass-dotenv-variables-created-in-a-job).
|
||||
|
||||
### Control which jobs receive `dotenv` variables
|
||||
|
||||
You can use the [`dependencies`](../yaml/_index.md#dependencies) or [`needs`](../yaml/_index.md#needs)
|
||||
keywords to control which jobs receive the `dotenv` artifacts.
|
||||
|
||||
To have no environment variables from a `dotenv` artifact:
|
||||
|
||||
- Pass an empty `dependencies` or `needs` array.
|
||||
- Pass [`needs:artifacts`](../yaml/_index.md#needsartifacts) as `false`.
|
||||
- Set `needs` to only list jobs that do not have a `dotenv` artifact.
|
||||
|
||||
For example:
|
||||
|
||||
```yaml
|
||||
build-job1:
|
||||
stage: build
|
||||
script:
|
||||
- echo "BUILD_VERSION=v1.0.0" >> build.env
|
||||
artifacts:
|
||||
reports:
|
||||
dotenv: build.env
|
||||
|
||||
build-job2:
|
||||
stage: build
|
||||
needs: []
|
||||
script:
|
||||
- echo "This job has no dotenv artifacts"
|
||||
|
||||
test-job1:
|
||||
stage: test
|
||||
script:
|
||||
- echo "$BUILD_VERSION" # Output is: 'v1.0.0'
|
||||
dependencies:
|
||||
- build-job1
|
||||
|
||||
test-job2:
|
||||
stage: test
|
||||
script:
|
||||
- echo "$BUILD_VERSION" # Output is ''
|
||||
dependencies: []
|
||||
|
||||
test-job3:
|
||||
stage: test
|
||||
script:
|
||||
- echo "$BUILD_VERSION" # Output is: 'v1.0.0'
|
||||
needs:
|
||||
- build-job1
|
||||
|
||||
test-job4:
|
||||
stage: test
|
||||
script:
|
||||
- echo "$BUILD_VERSION" # Output is: 'v1.0.0'
|
||||
needs:
|
||||
- job: build-job1
|
||||
artifacts: true
|
||||
|
||||
test-job5:
|
||||
stage: deploy
|
||||
script:
|
||||
- echo "$BUILD_VERSION" # Output is ''
|
||||
needs:
|
||||
- job: build-job1
|
||||
artifacts: false
|
||||
|
||||
test-job6:
|
||||
stage: deploy
|
||||
script:
|
||||
- echo "$BUILD_VERSION" # Output is ''
|
||||
needs:
|
||||
- build-job2
|
||||
```
|
||||
|
||||
## Pass an environment variable from the `script` section to `artifacts` or `cache`
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29391) in GitLab 16.4.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
Use `$GITLAB_ENV` to use environment variables defined in the `script` section in the
|
||||
`artifacts` or `cache` keywords. For example:
|
||||
|
||||
```yaml
|
||||
build-job:
|
||||
stage: build
|
||||
script:
|
||||
- echo "ARCH=$(arch)" >> $GITLAB_ENV
|
||||
- touch some-file-$(arch)
|
||||
artifacts:
|
||||
paths:
|
||||
- some-file-$ARCH
|
||||
```
|
||||
|
||||
## Store multiple values in one variable
|
||||
|
||||
You cannot create a CI/CD variable that is an array of values, but you
|
||||
can use shell scripting techniques for similar behavior.
|
||||
|
||||
For example, you can store multiple values separated by a space in a variable,
|
||||
then loop through the values with a script:
|
||||
|
||||
```yaml
|
||||
job1:
|
||||
variables:
|
||||
FOLDERS: src test docs
|
||||
script:
|
||||
- |
|
||||
for FOLDER in $FOLDERS
|
||||
do
|
||||
echo "The path is root/${FOLDER}"
|
||||
done
|
||||
```
|
||||
|
||||
## Use CI/CD variables in other variables
|
||||
|
||||
You can use variables inside other variables:
|
||||
|
||||
```yaml
|
||||
job:
|
||||
variables:
|
||||
FLAGS: '-al'
|
||||
LS_CMD: 'ls "$FLAGS"'
|
||||
script:
|
||||
- 'eval "$LS_CMD"' # Executes 'ls -al'
|
||||
```
|
||||
|
||||
### As part of a string
|
||||
|
||||
You can use variables as part of a string. You can surround the variables with curly brackets (`{}`)
|
||||
to help distinguish the variable name from the surrounding text. Without curly brackets,
|
||||
the adjacent text is interpreted as part of the variable name. For example:
|
||||
|
||||
```yaml
|
||||
job:
|
||||
variables:
|
||||
FLAGS: '-al'
|
||||
DIR: 'path/to/directory'
|
||||
LS_CMD: 'ls "$FLAGS"'
|
||||
CD_CMD: 'cd "${DIR}_files"'
|
||||
script:
|
||||
- 'eval "$LS_CMD"' # Executes 'ls -al'
|
||||
- 'eval "$CD_CMD"' # Executes 'cd path/to/directory_files'
|
||||
```
|
||||
|
||||
### Use the `$` character in CI/CD variables
|
||||
|
||||
If you do not want the `$` character interpreted as the start of another variable,
|
||||
use `$$` instead:
|
||||
|
||||
```yaml
|
||||
job:
|
||||
variables:
|
||||
FLAGS: '-al'
|
||||
LS_CMD: 'ls "$FLAGS" $$TMP_DIR'
|
||||
script:
|
||||
- 'eval "$LS_CMD"' # Executes 'ls -al $TMP_DIR'
|
||||
```
|
||||
|
|
@ -164,7 +164,7 @@ so you should only use the variable in GitLab itself.
|
|||
|
||||
{{< /alert >}}
|
||||
|
||||
## "argument list too long"
|
||||
## `argument list too long` error
|
||||
|
||||
This issue occurs when the combined length of all CI/CD variables defined for a job exceeds the limit imposed by the
|
||||
shell where the job executes. This includes the names and values of pre-defined and user defined variables. This limit
|
||||
|
|
|
|||
|
|
@ -4213,7 +4213,7 @@ job:
|
|||
|
||||
- The `description` is evaluated by the shell that runs `release-cli`.
|
||||
You can use CI/CD variables to define the description, but some shells
|
||||
[use different syntax](../variables/_index.md#use-cicd-variables-in-job-scripts)
|
||||
[use different syntax](../variables/job_scripts.md)
|
||||
to reference variables. Similarly, some shells might require special characters
|
||||
to be escaped. For example, backticks (`` ` ``) might need to be escaped with a backslash (` \ `).
|
||||
|
||||
|
|
@ -4534,7 +4534,7 @@ job:
|
|||
defined for the job, which defaults to `on_success` if not defined.
|
||||
- You can [mix `when` at the job-level with `when` in rules](https://gitlab.com/gitlab-org/gitlab/-/issues/219437).
|
||||
`when` configuration in `rules` takes precedence over `when` at the job-level.
|
||||
- Unlike variables in [`script`](../variables/_index.md#use-cicd-variables-in-job-scripts)
|
||||
- Unlike variables in [`script`](../variables/job_scripts.md)
|
||||
sections, variables in rules expressions are always formatted as `$VARIABLE`.
|
||||
- You can use `rules:if` with `include` to [conditionally include other configuration files](includes.md#use-rules-with-include).
|
||||
- CI/CD variables on the right side of `=~` and `!~` expressions are [evaluated as regular expressions](../jobs/job_rules.md#store-a-regular-expression-in-a-variable).
|
||||
|
|
|
|||
|
|
@ -299,7 +299,7 @@ GitLab can display the results of one or more reports in:
|
|||
The `dotenv` report collects a set of environment variables as artifacts.
|
||||
|
||||
The collected variables are registered as runtime-created variables of the job,
|
||||
which you can [use in subsequent job scripts](../variables/_index.md#pass-an-environment-variable-to-another-job)
|
||||
which you can [use in subsequent job scripts](../variables/job_scripts.md#pass-an-environment-variable-to-another-job)
|
||||
or to [set dynamic environment URLs after a job finishes](../environments/_index.md#set-a-dynamic-environment-url).
|
||||
|
||||
If duplicate environment variables are present in a `dotenv` report, the last one specified is used.
|
||||
|
|
|
|||
|
|
@ -244,3 +244,21 @@ Information, such as open tabs in their IDE, files, and folders,
|
|||
that the user provides from their local environment to extend the default AI
|
||||
Context. This is sometimes called "pinned context" internally. GitLab Duo Chat users
|
||||
can provide supplementary user context with the `/include` command (IDE only).
|
||||
|
||||
### AI Context Abstraction Layer
|
||||
|
||||
A [Ruby gem](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-active-context) that provides a unified interface for Retrieval Augmented Generation (RAG) across multiple vector databases within GitLab. The system abstracts away the differences between Elasticsearch, OpenSearch, and PostgreSQL with pgvector, enabling AI features to work regardless of the underlying storage solution.
|
||||
|
||||
Key components include collections that define data schemas and reference classes that handle serialization, migrations for schema management, and preprocessors for chunking and embedding generation. The layer supports automatic model migration between different LLMs without downtime, asynchronous processing through Redis-backed queues, and permission-aware search with automatic redaction.
|
||||
|
||||
This [architecture](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/ai_context_abstraction_layer/) prevents vendor lock-in and enables GitLab customers without Elasticsearch to access RAG-powered features through pgvector.
|
||||
|
||||
### GitLab Zoekt
|
||||
|
||||
A scalable exact code search service and file-based database system, with flexible architecture supporting various AI context use cases beyond traditional search. It's built on top of open-source code search engine Zoekt.
|
||||
|
||||
The system consists of a unified `gitlab-zoekt` binary that can operate in both indexer and webserver modes, managing index files on persistent storage for fast searches. Key features include bi-directional communication with GitLab and self-registering node [architecture](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/code_search_with_zoekt/) for easy scaling.
|
||||
|
||||
The system is designed to handle enterprise-scale deployments, with GitLab.com successfully operating over 48 TiB of indexed data.
|
||||
|
||||
Most likely, this distributed database system will be used to power [Knowledge Graph](#knowledge-graph). Also, we might leverage Exact Code Search to provide additional context and/or tools for GitLab Duo.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,46 @@
|
|||
---
|
||||
stage: GitLab Delivery
|
||||
group: Self Managed
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
title: GitLab 18 changes
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
|
||||
- Tier: Free, Premium, Ultimate
|
||||
- Offering: GitLab Self-Managed
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
This page contains upgrade information for minor and patch versions of GitLab 18.
|
||||
Ensure you review these instructions for:
|
||||
|
||||
- Your installation type.
|
||||
- All versions between your current version and your target version.
|
||||
|
||||
For more information about upgrading GitLab Helm Chart, see [the release notes for 9.0](https://docs.gitlab.com/charts/releases/9_0/).
|
||||
|
||||
## 18.0.0
|
||||
|
||||
### Geo installations 18.0.0
|
||||
|
||||
- If you deployed GitLab Enterprise Edition and then reverted to GitLab Community Edition,
|
||||
your database schema may deviate from the schema that the GitLab application expects,
|
||||
leading to migration errors. Four particular errors can be encountered on upgrade to 18.0.0
|
||||
because a migration was added in that version which changes the defaults of those columns.
|
||||
|
||||
The errors are:
|
||||
|
||||
- `No such column: geo_nodes.verification_max_capacity`
|
||||
- `No such column: geo_nodes.minimum_reverification_interval`
|
||||
- `No such column: geo_nodes.repos_max_capacity`
|
||||
- `No such column: geo_nodes.container_repositories_max_capacity`
|
||||
|
||||
This migration was patched in GitLab 18.0.2 to add those columns if they are missing.
|
||||
See [issue #543146](https://gitlab.com/gitlab-org/gitlab/-/issues/543146).
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
| Affected minor releases | Affected patch releases | Fixed in |
|
||||
| ----------------------- | ----------------------- | -------- |
|
||||
| 18.0 | 18.0.0 - 18.0.1 | 18.0.2 |
|
||||
|
|
@ -948,3 +948,11 @@ This error means a timeout occurred. To resolve it, add the `TRIVY_TIMEOUT` envi
|
|||
|
||||
Changes to the container scanning analyzer can be found in the project's
|
||||
[changelog](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/blob/master/CHANGELOG.md).
|
||||
|
||||
### Container Scanning v6.x: outdated vulnerability database error
|
||||
|
||||
Using Container Scanning with `registry.gitlab.com/security-products/container-scanning/grype:6` and `registry.gitlab.com/security-products/container-scanning/grype:6-fips` analyzer images may fail with an outdated vulnerability database error, for example:
|
||||
|
||||
`1 error occurred: * the vulnerability database was built 6 days ago (max allowed age is 5 days)`
|
||||
|
||||
This happens when one of the Container Scanning images above is copied to a user's own repository and not updated to the image (images are rebuilt daily).
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ In this CI/CD example the release preparation is split into separate jobs for gr
|
|||
|
||||
- The `prepare_job` job generates the release metadata. Any image can be used to run the job,
|
||||
including a custom image. The generated metadata is stored in the variable file `variables.env`.
|
||||
This metadata is [passed to the downstream job](../../../ci/variables/_index.md#pass-an-environment-variable-to-another-job).
|
||||
This metadata is [passed to the downstream job](../../../ci/variables/job_scripts.md#pass-an-environment-variable-to-another-job).
|
||||
- The `release_job` uses the content from the variables file to create a release, using the
|
||||
metadata passed to it in the variables file. This job must use the
|
||||
`registry.gitlab.com/gitlab-org/release-cli:latest` image because it contains the release CLI.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,11 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module CrystalballEnv
|
||||
EXCLUDED_PREFIXES = %w[vendor/ruby].freeze
|
||||
EXCLUDED_PREFIXES = [
|
||||
%r{vendor/ruby},
|
||||
%r{(ee/)?db/migrate/\d{14}_init_schema\.rb},
|
||||
%r{(ee/)?db/fixtures/development}
|
||||
].freeze
|
||||
|
||||
extend self
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ RSpec.describe GitlabSchema.types['WikiPage'], feature_category: :wiki do
|
|||
let_it_be(:wiki_page_meta) { create(:wiki_page_meta, :for_wiki_page, container: project) }
|
||||
|
||||
it 'has the correct fields' do
|
||||
expected_fields = [:id, :title, :notes, :discussions, :commenters, :user_permissions, :web_url, :name]
|
||||
expected_fields = [:id, :title, :notes, :discussions, :commenters, :user_permissions, :web_url, :name, :subscribed]
|
||||
|
||||
expect(described_class).to have_graphql_fields(*expected_fields)
|
||||
end
|
||||
|
|
|
|||
|
|
@ -28,10 +28,12 @@ RSpec.describe WikiPagePolicy, feature_category: :wiki do
|
|||
expect(policy).to be_allowed(:read_wiki_page)
|
||||
expect(policy).to be_allowed(:read_note)
|
||||
expect(policy).to be_allowed(:create_note)
|
||||
expect(policy).to be_allowed(:update_subscription)
|
||||
else
|
||||
expect(policy).to be_disallowed(:read_wiki_page)
|
||||
expect(policy).to be_disallowed(:read_note)
|
||||
expect(policy).to be_disallowed(:create_note)
|
||||
expect(policy).to be_disallowed(:update_subscription)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -0,0 +1,60 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
RSpec.describe 'Subscribe to a wiki page', feature_category: :wiki do
|
||||
include GraphqlHelpers
|
||||
|
||||
let_it_be(:project) { create(:project, :private) }
|
||||
let_it_be(:guest) { create(:user, guest_of: project) }
|
||||
let_it_be(:wiki_page_meta) { create(:wiki_page_meta, container: project) }
|
||||
|
||||
let(:subscribed_state) { true }
|
||||
let(:mutation_input) { { 'id' => wiki_page_meta.to_global_id.to_s, 'subscribed' => subscribed_state } }
|
||||
let(:mutation) { graphql_mutation(:wikiPageSubscribe, mutation_input, fields) }
|
||||
let(:mutation_response) { graphql_mutation_response(:wiki_page_subscribe) }
|
||||
let(:fields) do
|
||||
<<~FIELDS
|
||||
wikiPage {
|
||||
subscribed
|
||||
}
|
||||
errors
|
||||
FIELDS
|
||||
end
|
||||
|
||||
context 'when user is not allowed to update subscription wiki pages' do
|
||||
let(:current_user) { create(:user) }
|
||||
|
||||
it_behaves_like 'a mutation that returns a top-level access error'
|
||||
end
|
||||
|
||||
shared_examples 'sets the subscription to the wiki pages notifications', :aggregate_failures do |setting|
|
||||
it 'successfully adds the subscription' do
|
||||
expect { post_graphql_mutation(mutation, current_user: current_user) }
|
||||
.to change { wiki_page_meta.subscribed?(current_user, project) }
|
||||
.to(setting)
|
||||
|
||||
expect(response).to have_gitlab_http_status(:success)
|
||||
|
||||
expect(mutation_response['wikiPage']).to include({
|
||||
'subscribed' => setting
|
||||
})
|
||||
end
|
||||
end
|
||||
|
||||
context 'when user has permissions to update its subscription to the wiki pages' do
|
||||
let(:current_user) { guest }
|
||||
|
||||
include_examples 'sets the subscription to the wiki pages notifications', true
|
||||
|
||||
context 'when unsubscribing' do
|
||||
let(:subscribed_state) { false }
|
||||
|
||||
before do
|
||||
create(:subscription, project: project, user: current_user, subscribable: wiki_page_meta, subscribed: true)
|
||||
end
|
||||
|
||||
include_examples 'sets the subscription to the wiki pages notifications', false
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
RSpec.shared_examples 'create environment for job' do
|
||||
let!(:job) { build(factory_type, project: project, pipeline: pipeline, **attributes) }
|
||||
let!(:job) { build(factory_type, project: project, pipeline: pipeline, user: user, **attributes) }
|
||||
let(:merge_request) {} # rubocop:disable Lint/EmptyBlock
|
||||
|
||||
describe '#execute' do
|
||||
|
|
@ -41,6 +41,14 @@ RSpec.shared_examples 'create environment for job' do
|
|||
expect(subject).to be_persisted
|
||||
expect(subject).to eq(environment)
|
||||
end
|
||||
|
||||
it_behaves_like 'internal event tracking' do
|
||||
let(:event) { 'create_job_with_environment' }
|
||||
let(:category) { described_class.name }
|
||||
let(:additional_properties) do
|
||||
{ label: job.environment_action, value: environment.id, property: environment.tier }
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue