kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

Browse source
This commit is contained in:
GitLab Bot 2022-10-19 21:10:55 +00:00
parent b45b4fa37b
commit f7f930eadb
21 changed files with 134 additions and 88 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
.gitlab/merge_request_templates/Documentation.md
View file

@ -14,7 +14,7 @@
- [Documentation guidelines](https://docs.gitlab.com/ee/development/documentation/).
- [Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/).
- [ ] If you're adding or changing the main heading of the page (H1), ensure that the [product tier badge](https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#product-tier-badges) is added.
- [ ] If you are a GitLab team member, [request a review](https://docs.gitlab.com/ee/development/code_review.html#dogfooding-the-attention-request-feature) based on:
- [ ] If you are a GitLab team member, [request a review](https://docs.gitlab.com/ee/development/code_review.html#dogfooding-the-reviewers-feature) based on:
- The documentation page's [metadata](https://docs.gitlab.com/ee/development/documentation/#metadata).
- The [associated Technical Writer](https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments).

42
app/assets/javascripts/editor/schema/ci.json
View file

@ -858,46 +858,10 @@
]
},
"when": {
"markdownDescription": "Describes the conditions for when to run the job. Defaults to 'on_success'.",
"markdownDescription": "Describes the conditions for when to run the job. Defaults to 'on_success'. [Learn More](https://docs.gitlab.com/ee/ci/yaml/#when).",
"default": "on_success",
"oneOf": [
{
"enum": [
"on_success"
],
"description": "Execute job only when all jobs from prior stages succeed."
},
{
"enum": [
"on_failure"
],
"description": "Execute job when at least one job from prior stages fails."
},
{
"enum": [
"always"
],
"description": "Execute job regardless of the status from prior stages."
},
{
"enum": [
"manual"
],
"markdownDescription": "Execute the job manually from Gitlab UI or API. [Learn More](https://docs.gitlab.com/ee/ci/yaml/#when)."
},
{
"enum": [
"delayed"
],
"markdownDescription": "Execute a job after the time limit in 'start_in' expires. [Learn More](https://docs.gitlab.com/ee/ci/yaml/#when)."
},
{
"enum": [
"never"
],
"description": "Never execute the job."
}
]
"type": "string",
"enum": ["on_success", "on_failure", "always", "never", "manual", "delayed"]
},
"cache": {
"properties": {

34
doc/administration/operations/rails_console.md
View file

@ -59,6 +59,40 @@ you may run in the console. To turn off logging again, run:
ActiveRecord::Base.logger = nil
```
## Attributes
View available attributes, formatted using pretty print (`pp`).
For example, determine what attributes contain users' names and email addresses:
```ruby
u = User.find_by_username('someuser')
pp u.attributes
```
Partial output:
```plaintext
{"id"=>1234,
"email"=>"someuser@example.com",
"sign_in_count"=>99,
"name"=>"S User",
"username"=>"someuser",
"first_name"=>nil,
"last_name"=>nil,
"bot_type"=>nil}
```
Then make use of the attributes, [testing SMTP, for example](https://docs.gitlab.com/omnibus/settings/smtp.html#testing-the-smtp-configuration):
```ruby
e = u.email
n = u.name
Notify.test_email(e, "Test email for #{n}", 'Test email').deliver_now
#
Notify.test_email(u.email, "Test email for #{u.name}", 'Test email').deliver_now
```
## Disable database statement timeout
You can disable the PostgreSQL statement timeout for the current Rails console

1
doc/administration/package_information/supported_os.md
View file

@ -29,6 +29,7 @@ The following lists the currently supported OSs and their possible EOL dates.
| Scientific Linux | GitLab CE / GitLab EE 8.14.0 | x86_64 | [Use CentOS Install Documentation](https://about.gitlab.com/install/#centos-7) | June 2024 | <https://scientificlinux.org/downloads/sl-versions/sl7/> |
| Ubuntu 18.04 | GitLab CE / GitLab EE 10.7.0 | amd64 | [Ubuntu Install Documentation](https://about.gitlab.com/install/#ubuntu) | April 2023 | <https://wiki.ubuntu.com/Releases> |
| Ubuntu 20.04 | GitLab CE / GitLab EE 13.2.0 | amd64, arm64 | [Ubuntu Install Documentation](https://about.gitlab.com/install/#ubuntu) | April 2025 | <https://wiki.ubuntu.com/Releases> |
| Ubuntu 22.04 | GitLab CE / GitLab EE 15.5.0 | amd64, arm64 | [Ubuntu Install Documentation](https://about.gitlab.com/install/#ubuntu) | April 2027 | <https://wiki.ubuntu.com/Releases> |
| Amazon Linux 2 | GitLab CE / GitLab EE 14.9.0 | amd64, arm64 | [Amazon Linux 2 Install Documentation](https://about.gitlab.com/install/#amazonlinux-2) | June 2023 | <https://aws.amazon.com/amazon-linux-2/faqs/> |
| Raspberry Pi OS (Buster) (formerly known as Raspbian Buster) | GitLab CE 12.2.0 | armhf | [Raspberry Pi Install Documentation](https://about.gitlab.com/install/#raspberry-pi-os) | 2024 | [Raspberry Pi Details](https://www.raspberrypi.com/news/new-old-functionality-with-raspberry-pi-os-legacy/) |
| Raspberry Pi OS (Bullseye) | GitLab CE 15.5.0 | armhf | [Raspberry Pi Install Documentation](https://about.gitlab.com/install/#raspberry-pi-os) | 2026 | [Raspberry Pi Details](https://www.raspberrypi.com/news/raspberry-pi-os-debian-bullseye/) |

34
doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
View file

@ -28,40 +28,6 @@ mentioned above, we recommend running these scripts under the supervision of a
Support Engineer, who can also verify that they continue to work as they
should and, if needed, update the script for the latest version of GitLab.
## Attributes
View available attributes, formatted using pretty print (`pp`).
For example, determine what attributes contain users' names and email addresses:
```ruby
u = User.find_by_username('someuser')
pp u.attributes
```
Partial output:
```plaintext
{"id"=>1234,
"email"=>"someuser@example.com",
"sign_in_count"=>99,
"name"=>"S User",
"username"=>"someuser",
"first_name"=>nil,
"last_name"=>nil,
"bot_type"=>nil}
```
Then make use of the attributes, [testing SMTP, for example](https://docs.gitlab.com/omnibus/settings/smtp.html#testing-the-smtp-configuration):
```ruby
e = u.email
n = u.name
Notify.test_email(e, "Test email for #{n}", 'Test email').deliver_now
#
Notify.test_email(u.email, "Test email for #{u.name}", 'Test email').deliver_now
```
## Imports and exports
### Import a project

4
doc/api/packages/nuget.md
View file

@ -97,7 +97,7 @@ PUT projects/:id/packages/nuget
```shell
curl --request PUT \
--upload-file path/to/mynugetpkg.1.3.0.17.nupkg \
--form 'package=@path/to/mynugetpkg.1.3.0.17.nupkg' \
--user <username>:<personal_access_token> \
"https://gitlab.example.com/api/v4/projects/1/packages/nuget"
```
@ -121,7 +121,7 @@ PUT projects/:id/packages/nuget/symbolpackage
```shell
curl --request PUT \
--upload-file path/to/mynugetpkg.1.3.0.17.snupkg \
--form 'package=@path/to/mynugetpkg.1.3.0.17.snupkg' \
--user <username>:<personal_access_token> \
"https://gitlab.example.com/api/v4/projects/1/packages/nuget/symbolpackage"
```

4
doc/development/code_review.md
View file

@ -56,8 +56,8 @@ We make the following assumption with regards to automatically being considered
- Team members working in a specific stage/group (for example, create: source code) are considered domain experts for that area of the app they work on.
- Team members working on a specific feature (for example, search) are considered domain experts for that feature.
We default to assigning reviews to team members with domain expertise.
When a suitable [domain expert](#domain-experts) isn't available, you can choose any team member to review the MR, or follow the [Reviewer roulette](#reviewer-roulette) recommendation.
We default to assigning reviews to team members with domain expertise for code reviews. For UX reviews we default to the recommended designer from the Reviewer roulette.
When a suitable [domain expert](#domain-experts) isn't available, you can choose any team member to review the MR, or follow the [Reviewer roulette](#reviewer-roulette) recommendation (see above for UX reviews).
To find a domain expert:

2
doc/development/documentation/topic_types/troubleshooting.md
View file

@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
Troubleshooting topics should be the last topics on a page.
If a page has more than five troubleshooting topics, put the content on a separate page that has troubleshooting information exclusively. Name the page `Troubleshooting <feature>`
and in the left nav, use the word `Troubleshoot` only.
and in the left nav, use the word `Troubleshooting` only.
Troubleshooting can be one of three types.

4
doc/topics/autodevops/cloud_deployments/auto_devops_with_gke.md
View file

@ -102,9 +102,9 @@ or manually with Google Cloud Shell:
```shell
kubectl create ns gitlab-managed-apps
helm repo add stable https://charts.helm.sh/stable
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install ingress stable/nginx-ingress -n gitlab-managed-apps
helm install ingress ngress-nginx/ingress-nginx -n gitlab-managed-apps
# Check that the ingress controller is installed successfully
kubectl get service ingress-nginx-ingress-controller -n gitlab-managed-apps

2
doc/user/infrastructure/clusters/manage/management_project_applications/ingress.md
View file

@ -22,5 +22,5 @@ of your cluster.
You can customize the installation of Ingress by updating the
`applications/ingress/values.yaml` file in your cluster
management project. Refer to the
[chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress)
[chart](https://github.com/kubernetes/ingress-nginx/tree/master/charts/ingress-nginx)
for the available configuration options.

2
doc/user/packages/helm_repository/index.md
View file

@ -134,6 +134,8 @@ for any related errors. If you see `Validation failed: Version is invalid`, it m
version in your `Chart.yaml` file does not follow [Helm Chart versioning specifications](https://helm.sh/docs/topics/charts/#charts-and-versioning).
To fix the error, use the correct version syntax and upload the chart again.
Support for providing better error messages for package processing errors in the UI is proposed in issue [330515](https://gitlab.com/gitlab-org/gitlab/-/issues/330515).
### `helm push` results in an error
Helm 3.7 introduced a breaking change for the `helm-push` plugin. You can update the

2
doc/user/project/integrations/prometheus_library/nginx_ingress.md
View file

@ -38,7 +38,7 @@ Next, the Ingress needs to be annotated for Prometheus monitoring. Two new annot
- `prometheus.io/scrape: "true"`
- `prometheus.io/port: "10254"`
Managing these settings depends on how NGINX Ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible to edit the NGINX Ingress YAML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
Managing these settings depends on how NGINX Ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/kubernetes/ingress-nginx/tree/master/charts/ingress-nginx), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible to edit the NGINX Ingress YAML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
## Specifying the Environment label

2
doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md
View file

@ -38,7 +38,7 @@ Next, the Ingress needs to be annotated for Prometheus monitoring. Two new annot
- `prometheus.io/scrape: "true"`
- `prometheus.io/port: "10254"`
Managing these settings depends on how NGINX Ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible edit the NGINX Ingress YAML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
Managing these settings depends on how NGINX Ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/kubernetes/ingress-nginx/tree/master/charts/ingress-nginx), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible edit the NGINX Ingress YAML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
## Specifying the Environment label

2
lib/gitlab/ci/config/entry/bridge.rb
View file

@ -18,7 +18,7 @@ module Gitlab
validates :config, allowed_keys: ALLOWED_KEYS + PROCESSABLE_ALLOWED_KEYS
with_options allow_nil: true do
validates :when, inclusion: {
validates :when, type: String, inclusion: {
in: ALLOWED_WHEN,
message: "should be one of: #{ALLOWED_WHEN.join(', ')}"
}

2
lib/gitlab/ci/config/entry/job.rb
View file

@ -21,7 +21,7 @@ module Gitlab
validates :script, presence: true
with_options allow_nil: true do
validates :when, inclusion: {
validates :when, type: String, inclusion: {
in: ALLOWED_WHEN,
message: "should be one of: #{ALLOWED_WHEN.join(', ')}"
}

2
qa/qa/page/component/legacy_clone_panel.rb
View file

@ -28,7 +28,7 @@ module QA
end
def repository_location
Git::Location.new(find_element(:clone_url_content).text)
Git::Location.new(find_element(:clone_url_content).value)
end
private

4
spec/frontend/editor/schema/ci/ci_schema_spec.js
View file

@ -31,6 +31,7 @@ import IncludeYaml from './yaml_tests/positive_tests/include.yml';
import RulesYaml from './yaml_tests/positive_tests/rules.yml';
import ProjectPathYaml from './yaml_tests/positive_tests/project_path.yml';
import VariablesYaml from './yaml_tests/positive_tests/variables.yml';
import JobWhenYaml from './yaml_tests/positive_tests/job_when.yml';
// YAML NEGATIVE TEST
import ArtifactsNegativeYaml from './yaml_tests/negative_tests/artifacts.yml';
@ -38,6 +39,7 @@ import CacheNegativeYaml from './yaml_tests/negative_tests/cache.yml';
import IncludeNegativeYaml from './yaml_tests/negative_tests/include.yml';
import RulesNegativeYaml from './yaml_tests/negative_tests/rules.yml';
import VariablesNegativeYaml from './yaml_tests/negative_tests/variables.yml';
import JobWhenNegativeYaml from './yaml_tests/negative_tests/job_when.yml';
import ProjectPathIncludeEmptyYaml from './yaml_tests/negative_tests/project_path/include/empty.yml';
import ProjectPathIncludeInvalidVariableYaml from './yaml_tests/negative_tests/project_path/include/invalid_variable.yml';
@ -90,6 +92,7 @@ describe('positive tests', () => {
CacheYaml,
FilterYaml,
IncludeYaml,
JobWhenYaml,
RulesYaml,
VariablesYaml,
ProjectPathYaml,
@ -115,6 +118,7 @@ describe('negative tests', () => {
ArtifactsNegativeYaml,
CacheNegativeYaml,
IncludeNegativeYaml,
JobWhenNegativeYaml,
RulesNegativeYaml,
VariablesNegativeYaml,
ProjectPathIncludeEmptyYaml,

11
spec/frontend/editor/schema/ci/yaml_tests/negative_tests/job_when.yml Normal file
View file

@ -0,0 +1,11 @@
job_with_wrong_when:
script: exit 0
when: on_xyz
job_with_boolean_when:
script: exit 0
when: true
job_with_array_when:
script: exit 0
when: [on_success]

10
spec/frontend/editor/schema/ci/yaml_tests/positive_tests/job_when.yml Normal file
View file

@ -0,0 +1,10 @@
job_with_no_when:
script: exit 0
job_with_when_always:
script: exit 0
when: always
job_with_when_on_failure:
script: exit 0
when: on_failure

36
spec/lib/gitlab/ci/config/entry/bridge_spec.rb
View file

@ -3,7 +3,7 @@
require 'spec_helper'
RSpec.describe Gitlab::Ci::Config::Entry::Bridge do
subject { described_class.new(config, name: :my_bridge) }
subject(:entry) { described_class.new(config, name: :my_bridge) }
it_behaves_like 'with inheritable CI config' do
let(:inheritable_key) { 'default' }
@ -380,4 +380,38 @@ RSpec.describe Gitlab::Ci::Config::Entry::Bridge do
end
end
end
describe '#when' do
context 'when bridge is a manual action' do
let(:config) { { script: 'deploy', when: 'manual' } }
it { expect(entry.when).to eq('manual') }
end
context 'when bridge has no `when` attribute' do
let(:config) { { script: 'deploy' } }
it { expect(entry.when).to be_nil }
end
context 'when the `when` keyword is not a string' do
context 'when it is an array' do
let(:config) { { script: 'exit 0', when: ['always'] } }
it 'returns error' do
expect(entry).not_to be_valid
expect(entry.errors).to include 'bridge when should be a string'
end
end
context 'when it is a boolean' do
let(:config) { { script: 'exit 0', when: true } }
it 'returns error' do
expect(entry).not_to be_valid
expect(entry.errors).to include 'bridge when should be a string'
end
end
end
end
end

20
spec/lib/gitlab/ci/config/entry/job_spec.rb
View file

@ -317,6 +317,26 @@ RSpec.describe Gitlab::Ci::Config::Entry::Job do
end
end
context 'when the `when` keyword is not a string' do
context 'when it is an array' do
let(:config) { { script: 'exit 0', when: ['always'] } }
it 'returns error' do
expect(entry).not_to be_valid
expect(entry.errors).to include 'job when should be a string'
end
end
context 'when it is a boolean' do
let(:config) { { script: 'exit 0', when: true } }
it 'returns error' do
expect(entry).not_to be_valid
expect(entry.errors).to include 'job when should be a string'
end
end
end
context 'when only: is used with rules:' do
let(:config) { { only: ['merge_requests'], rules: [{ if: '$THIS' }] } }