Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
0cc59b1649
commit
7734690def
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Changes limit for terraform artifacts to 5MB
|
||||
merge_request: 37018
|
||||
author:
|
||||
type: changed
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class ChangeDefaultValueOfCiMaxArtifactSizeTerraformOfPlanLimitsFrom0To5 < ActiveRecord::Migration[6.0]
|
||||
include Gitlab::Database::MigrationHelpers
|
||||
|
||||
DOWNTIME = false
|
||||
|
||||
def up
|
||||
with_lock_retries do
|
||||
change_column_default :plan_limits, :ci_max_artifact_size_terraform, 5
|
||||
execute('UPDATE plan_limits SET ci_max_artifact_size_terraform = 5 WHERE ci_max_artifact_size_terraform = 0')
|
||||
end
|
||||
end
|
||||
|
||||
def down
|
||||
with_lock_retries do
|
||||
change_column_default :plan_limits, :ci_max_artifact_size_terraform, 0
|
||||
execute('UPDATE plan_limits SET ci_max_artifact_size_terraform = 0 WHERE ci_max_artifact_size_terraform = 5')
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
@ -13885,7 +13885,7 @@ CREATE TABLE public.plan_limits (
|
|||
ci_max_artifact_size_network_referee integer DEFAULT 0 NOT NULL,
|
||||
ci_max_artifact_size_dotenv integer DEFAULT 0 NOT NULL,
|
||||
ci_max_artifact_size_cobertura integer DEFAULT 0 NOT NULL,
|
||||
ci_max_artifact_size_terraform integer DEFAULT 0 NOT NULL,
|
||||
ci_max_artifact_size_terraform integer DEFAULT 5 NOT NULL,
|
||||
ci_max_artifact_size_accessibility integer DEFAULT 0 NOT NULL,
|
||||
ci_max_artifact_size_cluster_applications integer DEFAULT 0 NOT NULL,
|
||||
ci_max_artifact_size_secret_detection integer DEFAULT 0 NOT NULL,
|
||||
|
|
@ -23839,6 +23839,7 @@ COPY "schema_migrations" (version) FROM STDIN;
|
|||
20200701093859
|
||||
20200701190523
|
||||
20200701205710
|
||||
20200701221303
|
||||
20200702123805
|
||||
20200702201039
|
||||
20200703064117
|
||||
|
|
|
|||
|
|
@ -649,94 +649,98 @@ This follows the usual rules for [`only` / `except` policies](../yaml/README.md#
|
|||
|
||||
### Syntax of environment variable expressions
|
||||
|
||||
Below you can find supported syntax reference:
|
||||
Below you can find supported syntax reference.
|
||||
|
||||
1. Equality matching using a string
|
||||
#### Equality matching using a string
|
||||
|
||||
Examples:
|
||||
Examples:
|
||||
|
||||
- `$VARIABLE == "some value"`
|
||||
- `$VARIABLE != "some value"` (introduced in GitLab 11.11)
|
||||
- `$VARIABLE == "some value"`
|
||||
- `$VARIABLE != "some value"` (introduced in GitLab 11.11)
|
||||
|
||||
You can use equality operator `==` or `!=` to compare a variable content to a
|
||||
string. We support both, double quotes and single quotes to define a string
|
||||
value, so both `$VARIABLE == "some value"` and `$VARIABLE == 'some value'`
|
||||
are supported. `"some value" == $VARIABLE` is correct too.
|
||||
You can use equality operator `==` or `!=` to compare a variable content to a
|
||||
string. We support both, double quotes and single quotes to define a string
|
||||
value, so both `$VARIABLE == "some value"` and `$VARIABLE == 'some value'`
|
||||
are supported. `"some value" == $VARIABLE` is correct too.
|
||||
|
||||
1. Checking for an undefined value
|
||||
#### Checking for an undefined value
|
||||
|
||||
Examples:
|
||||
Examples:
|
||||
|
||||
- `$VARIABLE == null`
|
||||
- `$VARIABLE != null` (introduced in GitLab 11.11)
|
||||
- `$VARIABLE == null`
|
||||
- `$VARIABLE != null` (introduced in GitLab 11.11)
|
||||
|
||||
It sometimes happens that you want to check whether a variable is defined
|
||||
or not. To do that, you can compare a variable to `null` keyword, like
|
||||
`$VARIABLE == null`. This expression evaluates to true if
|
||||
variable is not defined when `==` is used, or to false if `!=` is used.
|
||||
It sometimes happens that you want to check whether a variable is defined
|
||||
or not. To do that, you can compare a variable to `null` keyword, like
|
||||
`$VARIABLE == null`. This expression evaluates to true if
|
||||
variable is not defined when `==` is used, or to false if `!=` is used.
|
||||
|
||||
1. Checking for an empty variable
|
||||
#### Checking for an empty variable
|
||||
|
||||
Examples:
|
||||
Examples:
|
||||
|
||||
- `$VARIABLE == ""`
|
||||
- `$VARIABLE != ""` (introduced in GitLab 11.11)
|
||||
- `$VARIABLE == ""`
|
||||
- `$VARIABLE != ""` (introduced in GitLab 11.11)
|
||||
|
||||
If you want to check whether a variable is defined, but is empty, you can
|
||||
simply compare it against an empty string, like `$VAR == ''` or non-empty
|
||||
string `$VARIABLE != ""`.
|
||||
If you want to check whether a variable is defined, but is empty, you can
|
||||
simply compare it against an empty string, like `$VAR == ''` or non-empty
|
||||
string `$VARIABLE != ""`.
|
||||
|
||||
1. Comparing two variables
|
||||
#### Comparing two variables
|
||||
|
||||
Examples:
|
||||
Examples:
|
||||
|
||||
- `$VARIABLE_1 == $VARIABLE_2`
|
||||
- `$VARIABLE_1 != $VARIABLE_2` (introduced in GitLab 11.11)
|
||||
- `$VARIABLE_1 == $VARIABLE_2`
|
||||
- `$VARIABLE_1 != $VARIABLE_2` (introduced in GitLab 11.11)
|
||||
|
||||
It is possible to compare two variables. This is going to compare values
|
||||
of these variables.
|
||||
It is possible to compare two variables. This is going to compare values
|
||||
of these variables.
|
||||
|
||||
1. Variable presence check
|
||||
#### Variable presence check
|
||||
|
||||
Example: `$STAGING`
|
||||
Example: `$STAGING`
|
||||
|
||||
If you only want to create a job when there is some variable present,
|
||||
which means that it is defined and non-empty, you can simply use
|
||||
variable name as an expression, like `$STAGING`. If `$STAGING` variable
|
||||
is defined, and is non empty, expression will evaluate to truth.
|
||||
`$STAGING` value needs to be a string, with length higher than zero.
|
||||
Variable that contains only whitespace characters is not an empty variable.
|
||||
If you only want to create a job when there is some variable present,
|
||||
which means that it is defined and non-empty, you can simply use
|
||||
variable name as an expression, like `$STAGING`. If `$STAGING` variable
|
||||
is defined, and is non empty, expression will evaluate to truth.
|
||||
`$STAGING` value needs to be a string, with length higher than zero.
|
||||
Variable that contains only whitespace characters is not an empty variable.
|
||||
|
||||
1. Pattern matching (introduced in GitLab 11.0)
|
||||
#### Regex pattern matching
|
||||
|
||||
Examples:
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/43601) in GitLab 11.0
|
||||
|
||||
- `=~`: True if pattern is matched. Ex: `$VARIABLE =~ /^content.*/`
|
||||
- `!~`: True if pattern is not matched. Ex: `$VARIABLE_1 !~ /^content.*/` ([Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/61900) in GitLab 11.11)
|
||||
Examples:
|
||||
|
||||
Variable pattern matching with regular expressions uses the
|
||||
[RE2 regular expression syntax](https://github.com/google/re2/wiki/Syntax).
|
||||
Expressions evaluate as `true` if:
|
||||
- `=~`: True if pattern is matched. Ex: `$VARIABLE =~ /^content.*/`
|
||||
- `!~`: True if pattern is not matched. Ex: `$VARIABLE_1 !~ /^content.*/` ([Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/61900) in GitLab 11.11)
|
||||
|
||||
- Matches are found when using `=~`.
|
||||
- Matches are *not* found when using `!~`.
|
||||
Variable pattern matching with regular expressions uses the
|
||||
[RE2 regular expression syntax](https://github.com/google/re2/wiki/Syntax).
|
||||
Expressions evaluate as `true` if:
|
||||
|
||||
Pattern matching is case-sensitive by default. Use `i` flag modifier, like
|
||||
`/pattern/i` to make a pattern case-insensitive.
|
||||
- Matches are found when using `=~`.
|
||||
- Matches are *not* found when using `!~`.
|
||||
|
||||
1. Conjunction / Disjunction ([introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/27925) in GitLab 12.0)
|
||||
Pattern matching is case-sensitive by default. Use `i` flag modifier, like
|
||||
`/pattern/i` to make a pattern case-insensitive.
|
||||
|
||||
Examples:
|
||||
#### Conjunction / Disjunction
|
||||
|
||||
- `$VARIABLE1 =~ /^content.*/ && $VARIABLE2 == "something"`
|
||||
- `$VARIABLE1 =~ /^content.*/ && $VARIABLE2 =~ /thing$/ && $VARIABLE3`
|
||||
- `$VARIABLE1 =~ /^content.*/ || $VARIABLE2 =~ /thing$/ && $VARIABLE3`
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/62867) in GitLab 12.0
|
||||
|
||||
It is possible to join multiple conditions using `&&` or `||`. Any of the otherwise
|
||||
supported syntax may be used in a conjunctive or disjunctive statement.
|
||||
Precedence of operators follows the
|
||||
[Ruby 2.5 standard](https://ruby-doc.org/core-2.5.0/doc/syntax/precedence_rdoc.html),
|
||||
so `&&` is evaluated before `||`.
|
||||
Examples:
|
||||
|
||||
- `$VARIABLE1 =~ /^content.*/ && $VARIABLE2 == "something"`
|
||||
- `$VARIABLE1 =~ /^content.*/ && $VARIABLE2 =~ /thing$/ && $VARIABLE3`
|
||||
- `$VARIABLE1 =~ /^content.*/ || $VARIABLE2 =~ /thing$/ && $VARIABLE3`
|
||||
|
||||
It is possible to join multiple conditions using `&&` or `||`. Any of the otherwise
|
||||
supported syntax may be used in a conjunctive or disjunctive statement.
|
||||
Precedence of operators follows the
|
||||
[Ruby 2.5 standard](https://ruby-doc.org/core-2.5.0/doc/syntax/precedence_rdoc.html),
|
||||
so `&&` is evaluated before `||`.
|
||||
|
||||
### Storing regular expressions in variables
|
||||
|
||||
|
|
|
|||
|
|
@ -99,6 +99,11 @@ deployment platform. Changes performed outside of this tab are
|
|||
reflected upon refresh. Enforcement status changes are deployed
|
||||
directly to a deployment namespace of the selected environment.
|
||||
|
||||
By default, the network policy list contains predefined policies in a
|
||||
disabled state. Once enabled,a predefined policy deploys to the
|
||||
selected environment's deployment platform and you can manage it like
|
||||
the regular policies.
|
||||
|
||||
NOTE: **Note:**
|
||||
If you're using [Auto DevOps](../../../topics/autodevops/index.md) and
|
||||
change a policy in this section, your `auto-deploy-values.yaml` file
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ Without mirroring, to work locally you'll have to use `git pull` to update your
|
|||
with the upstream project, then push the changes back to your fork to update it.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
With mirroring, before approving a merge request, you'll likely be asked to sync; hence automating it is recommend.
|
||||
With mirroring, before approving a merge request, you'll likely be asked to sync; hence automating it is recommended.
|
||||
|
||||
Read more about [How to keep your fork up to date with its origin](https://about.gitlab.com/blog/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/).
|
||||
|
||||
|
|
@ -61,7 +61,7 @@ When you are ready to send your code back to the upstream project,
|
|||
choose your forked project's branch. For **Target branch**, choose the original project's branch.
|
||||
|
||||
NOTE: **Note:**
|
||||
When creating a merge request, if the forked project's visibility is more restrictive than the parent project (for example the fork is private, parent is public), the target branch will default to the forked project's default branch. This prevents potentially exposing private code of the forked project.
|
||||
When creating a merge request, if the forked project's visibility is more restrictive than the parent project (for example the fork is private, the parent is public), the target branch will default to the forked project's default branch. This prevents potentially exposing the private code of the forked project.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -197,7 +197,6 @@ RSpec.describe PlanLimits do
|
|||
ci_max_artifact_size_network_referee
|
||||
ci_max_artifact_size_dotenv
|
||||
ci_max_artifact_size_cobertura
|
||||
ci_max_artifact_size_terraform
|
||||
ci_max_artifact_size_accessibility
|
||||
ci_max_artifact_size_cluster_applications
|
||||
ci_max_artifact_size_secret_detection
|
||||
|
|
|
|||
Loading…
Reference in New Issue