Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2020-05-18 18:08:22 +00:00
parent e35f91f05b
commit 40cdcdd45b
25 changed files with 304 additions and 76 deletions

View file

@ -88,14 +88,14 @@ export default {
</div>
<tabs v-else class="ide-pipeline-list">
<tab :active="!pipelineFailed">
<template slot="title">
<template #title>
{{ __('Jobs') }}
<span v-if="jobsCount" class="badge badge-pill"> {{ jobsCount }} </span>
</template>
<jobs-list :loading="isLoadingJobs" :stages="stages" />
</tab>
<tab :active="pipelineFailed">
<template slot="title">
<template #title>
{{ __('Failed Jobs') }}
<span v-if="failedJobsCount" class="badge badge-pill"> {{ failedJobsCount }} </span>
</template>

View file

@ -184,18 +184,19 @@ export default {
:add-spacing-classes="false"
class="prepend-top-10 append-bottom-10"
>
<textarea
id="release-notes"
slot="textarea"
v-model="releaseNotes"
class="note-textarea js-gfm-input js-autosize markdown-area"
dir="auto"
data-supports-quick-actions="false"
:aria-label="__('Release notes')"
:placeholder="__('Write your release notes or drag your files here…')"
@keydown.meta.enter="updateRelease()"
@keydown.ctrl.enter="updateRelease()"
></textarea>
<template #textarea>
<textarea
id="release-notes"
v-model="releaseNotes"
class="note-textarea js-gfm-input js-autosize markdown-area"
dir="auto"
data-supports-quick-actions="false"
:aria-label="__('Release notes')"
:placeholder="__('Write your release notes or drag your files here…')"
@keydown.meta.enter="updateRelease()"
@keydown.ctrl.enter="updateRelease()"
></textarea>
</template>
</markdown-field>
</div>
</gl-form-group>

View file

@ -86,8 +86,8 @@ class Blob < SimpleDelegator
new(blob, container)
end
def self.lazy(container, commit_id, path, blob_size_limit: Gitlab::Git::Blob::MAX_DATA_DISPLAY_SIZE)
BatchLoader.for([commit_id, path]).batch(key: container.repository) do |items, loader, args|
def self.lazy(repository, commit_id, path, blob_size_limit: Gitlab::Git::Blob::MAX_DATA_DISPLAY_SIZE)
BatchLoader.for([commit_id, path]).batch(key: repository) do |items, loader, args|
args[:key].blobs_at(items, blob_size_limit: blob_size_limit).each do |blob|
loader.call([blob.commit_id, blob.path], blob) if blob
end

View file

@ -204,7 +204,7 @@ class Snippet < ApplicationRecord
def blobs
return [] unless repository_exists?
repository.ls_files(repository.root_ref).map { |file| Blob.lazy(self, repository.root_ref, file) }
repository.ls_files(repository.root_ref).map { |file| Blob.lazy(repository, repository.root_ref, file) }
end
def hook_attrs

View file

@ -12,7 +12,9 @@ module Deployments
return unless @deployment&.running?
older_deployments.find_each do |older_deployment|
older_deployment.deployable&.drop!(:forward_deployment_failure)
Gitlab::OptimisticLocking.retry_lock(older_deployment.deployable) do |deployable|
deployable.drop(:forward_deployment_failure)
end
rescue => e
Gitlab::ErrorTracking.track_exception(e, subject_id: @deployment.id, deployment_id: older_deployment.id)
end

View file

@ -0,0 +1,5 @@
---
title: Add ability to create merge request from vulnerability page
merge_request: 31620
author:
type: added

View file

@ -0,0 +1,5 @@
---
title: Update deprecated slot syntax in ./app/assets/javascripts/releases/components/app_edit.vue
merge_request: 32018
author: Gilang Gumilar
type: other

View file

@ -0,0 +1,5 @@
---
title: Update deprecated slot syntax in ./app/assets/javascripts/ide/components/pipelines/list.vue
merge_request: 32027
author: Gilang Gumilar
type: other

View file

@ -219,6 +219,12 @@ alerts in the following ways:
Prometheus alert payloads sent to the `notify.json` endpoint are limited to 1 MB in size.
### Generic Alert JSON payloads
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16441) in GitLab 12.4.
Alert payloads sent to the `notify.json` endpoint are limited to 1 MB in size.
## Environment data on Deploy Boards
[Deploy Boards](../user/project/deploy_boards.md) load information from Kubernetes about

View file

@ -106,7 +106,7 @@ The following table lists available parameters for jobs:
| [`when`](#when) | When to run job. Also available: `when:manual` and `when:delayed`. |
| [`environment`](#environment) | Name of an environment to which the job deploys. Also available: `environment:name`, `environment:url`, `environment:on_stop`, `environment:auto_stop_in` and `environment:action`. |
| [`cache`](#cache) | List of files that should be cached between subsequent runs. Also available: `cache:paths`, `cache:key`, `cache:untracked`, and `cache:policy`. |
| [`artifacts`](#artifacts) | List of files and directories to attach to a job on success. Also available: `artifacts:paths`, `artifacts:expose_as`, `artifacts:name`, `artifacts:untracked`, `artifacts:when`, `artifacts:expire_in`, `artifacts:reports`, `artifacts:reports:junit`, `artifacts:reports:cobertura`, and `artifacts:reports:terraform`.<br><br>In GitLab [Enterprise Edition](https://about.gitlab.com/pricing/), these are available: `artifacts:reports:codequality`, `artifacts:reports:sast`, `artifacts:reports:dependency_scanning`, `artifacts:reports:container_scanning`, `artifacts:reports:dast`, `artifacts:reports:license_scanning`, `artifacts:reports:license_management` (removed in 13.0),`artifacts:reports:performance` and `artifacts:reports:metrics`. |
| [`artifacts`](#artifacts) | List of files and directories to attach to a job on success. Also available: `artifacts:paths`, `artifacts:expose_as`, `artifacts:name`, `artifacts:untracked`, `artifacts:when`, `artifacts:expire_in`, `artifacts:reports`, `artifacts:reports:junit`, `artifacts:reports:cobertura`, and `artifacts:reports:terraform`.<br><br>In GitLab [Enterprise Edition](https://about.gitlab.com/pricing/), these are available: `artifacts:reports:codequality`, `artifacts:reports:sast`, `artifacts:reports:dependency_scanning`, `artifacts:reports:container_scanning`, `artifacts:reports:dast`, `artifacts:reports:license_scanning`, `artifacts:reports:license_management` (removed in GitLab 13.0),`artifacts:reports:performance` and `artifacts:reports:metrics`. |
| [`dependencies`](#dependencies) | Restrict which artifacts are passed to a specific job by providing a list of jobs to fetch artifacts from. |
| [`coverage`](#coverage) | Code coverage settings for a given job. |
| [`retry`](#retry) | When and how many times a job can be auto-retried in case of a failure. |
@ -2770,7 +2770,7 @@ These are the available report types:
| [`artifacts:reports:dependency_scanning`](../pipelines/job_artifacts.md#artifactsreportsdependency_scanning-ultimate) **(ULTIMATE)** | The `dependency_scanning` report collects Dependency Scanning vulnerabilities. |
| [`artifacts:reports:container_scanning`](../pipelines/job_artifacts.md#artifactsreportscontainer_scanning-ultimate) **(ULTIMATE)** | The `container_scanning` report collects Container Scanning vulnerabilities. |
| [`artifacts:reports:dast`](../pipelines/job_artifacts.md#artifactsreportsdast-ultimate) **(ULTIMATE)** | The `dast` report collects Dynamic Application Security Testing vulnerabilities. |
| [`artifacts:reports:license_management`](../pipelines/job_artifacts.md#artifactsreportslicense_management-ultimate) **(ULTIMATE)** | The `license_management` report collects Licenses (*removed from 13.0*). |
| [`artifacts:reports:license_management`](../pipelines/job_artifacts.md#artifactsreportslicense_management-ultimate) **(ULTIMATE)** | The `license_management` report collects Licenses (*removed from GitLab 13.0*). |
| [`artifacts:reports:license_scanning`](../pipelines/job_artifacts.md#artifactsreportslicense_scanning-ultimate) **(ULTIMATE)** | The `license_scanning` report collects Licenses. |
| [`artifacts:reports:performance`](../pipelines/job_artifacts.md#artifactsreportsperformance-premium) **(PREMIUM)** | The `performance` report collects Performance metrics. |
| [`artifacts:reports:metrics`](../pipelines/job_artifacts.md#artifactsreportsmetrics-premium) **(PREMIUM)** | The `metrics` report collects Metrics. |

View file

@ -264,7 +264,7 @@ release. There are three levels of Release Scoping labels:
milestone. If these issues are not done in the current release, they will
strongly be considered for the next release.
- ~"Next Patch Release": Issues to put in the next patch release. Work on these
first, and add the "Pick Into X" label to the merge request, along with the
first, and add the `~"Pick into X.Y"` label to the merge request, along with the
appropriate milestone.
Each issue scheduled for the current milestone should be labeled ~Deliverable

View file

@ -183,7 +183,7 @@ in a follow-up MR or issue.
NOTE: **Note:**
If the release version you want to add the documentation to has already been
frozen or released, use the label `Pick into X.Y` to get it merged into
frozen or released, use the label `~"Pick into X.Y"` to get it merged into
the correct release. Avoid picking into a past release as much as you can, as
it increases the work of the release managers.
@ -203,7 +203,7 @@ to the MR.
For example, let's say your merge request has a milestone set to 11.3, which
will be released on 2018-09-22. If it gets merged on 2018-09-15, it will be
available online on 2018-09-15, but, as the feature freeze date has passed, if
the MR does not have a "pick into 11.3" label, the milestone has to be changed
the MR does not have a `~"Pick into 11.3"` label, the milestone has to be changed
to 11.4 and it will be shipped with all GitLab packages only on 2018-10-22,
with GitLab 11.4. Meaning, it will only be available under `/help` from GitLab
11.4 onward, but available on <https://docs.gitlab.com/> on the same day it was merged.

View file

@ -192,7 +192,7 @@ feature flag. This ensures the change is available to all users and self-managed
instances. Make sure to add the ~"feature flag" label to this merge request so
release managers are aware the changes are hidden behind a feature flag. If the
merge request has to be picked into a stable branch, make sure to also add the
appropriate "Pick into X" label (e.g. "Pick into XX.X").
appropriate `~"Pick into X.Y"` label (e.g. `~"Pick into 13.0"`).
See [the process document](process.md#including-a-feature-behind-feature-flag-in-the-final-release) for further details.
When a feature gate has been removed from the code base, the feature

View file

@ -341,7 +341,7 @@ To use Auto Deploy on a Kubernetes 1.16+ cluster:
1. On GitLab 12.10 or older, set the following in the [`.gitlab/auto-deploy-values.yaml` file](customize.md#customize-values-for-helm-chart):
```yml
```yaml
deploymentApiVersion: apps/v1
```

View file

@ -470,21 +470,15 @@ include:
variables:
DS_ANALYZER_IMAGE_PREFIX: "docker-registry.example.com/analyzers"
GEMNASIUM_DB_REMOTE_URL: "gitlab.example.com/gemnasium-db.git"
GIT_SSL_NO_VERIFY: "true"
```
See explanations of the variables above in the [configuration section](#configuration).
### Specific settings for languages and package managers
For every language and package manager, add the following to the variables section of
`.gitlab-ci.yml`:
```yaml
GEMNASIUM_DB_REMOTE_URL: "gitlab.example.com/gemnasium-db.git"
GIT_SSL_NO_VERIFY: "true"
```
See the following sections for additional instructions on specific languages and package managers.
See the following sections for configuring specific languages and package managers.
#### JavaScript (npm and yarn) projects
@ -540,26 +534,6 @@ gemnasium-maven-dependency_scanning:
This adds the self-signed certificates of your Maven repository to the Java KeyStore of the analyzer's Docker image.
#### Python (pip) and Python (Pipfile) projects
Add the following `pip.conf` to your repository to define your index URL and trust its self-signed
certificate:
```toml
[global]
index-url = https://pypi.example.com
trusted-host = pypi.example.com
```
Add the following job section to `.gitlab-ci.yml`:
```yaml
gemnasium-python-dependency_scanning:
before_script:
- mkdir -p ~/.config/pip
- cp pip.conf ~/.config/pip/pip.conf
```
#### Python (setuptools)
When using self-signed certificates for your private PyPi repository, no extra job configuration (aside
@ -591,15 +565,18 @@ ensure that it can reach your private repository. Here is an example configurati
### Referencing local dependencies using a path in JavaScript projects
Although dependency scanning doesn't support it, you can reference dependencies by using a
[local path](https://docs.npmjs.com/files/package.json#local-paths) in the `package.json` for a
JavaScript project. The dependency scan generates the following error when you use
`file: <path/to/dependency-name>` to reference a package:
The [Retire.js](https://gitlab.com/gitlab-org/security-products/analyzers/retire.js) analyzer
doesn't support dependency references made with [local paths](https://docs.npmjs.com/files/package.json#local-paths)
in the `package.json` of JavaScript projects. The dependency scan outputs the following error for
such references:
```text
ERROR: Could not find dependencies: <dependency-name>. You may need to run npm install
```
As a workaround, remove the [`retire.js`](analyzers.md#selecting-specific-analyzers) analyzer from
[DS_DEFAULT_ANALYZERS](#configuring-dependency-scanning).
## Troubleshooting
### Error response from daemon: error processing tar file: docker-tar: relocation error

View file

@ -100,7 +100,7 @@ For GitLab versions earlier than 11.9, you can copy and use the job as defined
that template.
NOTE: **Note:**
In GitLab 13.0, the `License-Management.gitlab-ci.yml` template was removed.
GitLab 13.0 removes the `License-Management.gitlab-ci.yml` template.
Use `License-Scanning.gitlab-ci.yml` instead.
Add the following to your `.gitlab-ci.yml` file:
@ -115,7 +115,7 @@ and scan your dependencies to find their licenses.
NOTE: **Note:**
Before GitLab 12.8, the `license_scanning` job was named `license_management`.
In GitLab 13.0, the `license_management` job was removed,
GitLab 13.0 removes the `license_management` job,
so you're advised to migrate to the `license_scanning` job and used the new
`License-Scanning.gitlab-ci.yml` template.
@ -329,13 +329,13 @@ strict-ssl = false
### Migration from `license_management` to `license_scanning`
In GitLab 12.8 a new name for `license_management` job was introduced. This change was made to improve clarity around the purpose of the scan, which is to scan and collect the types of licenses present in a projects dependencies.
The support of `license_management` was dropped in GitLab 13.0.
GitLab 13.0 drops support for `license_management`.
If you're using a custom setup for License Compliance, you're required
to update your CI config accordingly:
1. Change the CI template to `License-Scanning.gitlab-ci.yml`.
1. Change the job name to `license_scanning` (if you mention it in `.gitlab-ci.yml`).
1. Change the artifact name to `license_scanning` and file name to `gl-license-scanning-report.json` (if you mention it in `.gitlab-ci.yml`).
1. Change the artifact name to `license_scanning`, and the file name to `gl-license-scanning-report.json` (if you mention it in `.gitlab-ci.yml`).
For example, the following `.gitlab-ci.yml`:
@ -361,7 +361,7 @@ license_scanning:
license_scanning: gl-license-scanning-report.json
```
Since GitLab 13.0, if you use `license_management` artifact, you will encounter an error while running the License Compliance job:
If you use the `license_management` artifact in GitLab 13.0 or later, the License Compliance job generates this error:
```text
WARNING: Uploading artifacts to coordinator... failed id=:id responseStatus=400 Bad Request status=400 Bad Request token=:sha
@ -369,7 +369,7 @@ WARNING: Uploading artifacts to coordinator... failed id=:id responseStatus=400
FATAL: invalid_argument
```
If you encounter this error, you're encouraged to follow the instructions described in this section.
If you encounter this error, follow the instructions described in this section.
## Running License Compliance in an offline environment

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

View file

@ -4,7 +4,9 @@ group: Configure
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/#designated-technical-writers
---
# Infrastructure as code with GitLab managed Terraform State
# Infrastructure as code with Terraform and GitLab
## GitLab managed Terraform State
[Terraform remote backends](https://www.terraform.io/docs/backends/index.html)
enable you to store the state file in a remote, shared store. GitLab uses the
@ -156,3 +158,186 @@ The output from the above `terraform` commands should be viewable in the job log
## Example project
See [this reference project](https://gitlab.com/nicholasklick/gitlab-terraform-aws) using GitLab and Terraform to deploy a basic AWS EC2 within a custom VPC.
## Output Terraform Plan information into a merge request
Using the [GitLab Terraform Report Artifact](../../ci/pipelines/job_artifacts.md#artifactsreportsterraform),
you can expose details from `terraform plan` runs directly into a merge request widget,
enabling you to see statistics about the resources that Terraform will create,
modify, or destroy.
Let's explore how to configure a GitLab Terraform Report Artifact:
1. First, for simplicity, let's define a few reusable variables to allow us to
refer to these files multiple times:
```yaml
variables:
PLAN: plan.tfplan
PLAN_JSON: tfplan.json
```
1. Next we need to install `jq`, a [lightweight and flexible command-line JSON processor](https://stedolan.github.io/jq/). We will also create an alias for a specific `jq` command that parses out the extact information we want to extract from the `terraform plan` output:
```yaml
before_script:
- apk --no-cache add jq
- alias convert_report="jq -r '([.resource_changes[]?.change.actions?]|flatten)|{\"create\":(map(select(.==\"create\"))|length),\"update\":(map(select(.==\"update\"))|length),\"delete\":(map(select(.==\"delete\"))|length)}'"
```
1. Finally, we define a `script` that runs `terraform plan` and also a `terraform show` which pipes the output and converts the relevant bits into a store variable `PLAN_JSON`. This json is then leveraged to create a [GitLab Terraform Report Artifact](../../ci/pipelines/job_artifacts.md#artifactsreportsterraform).
The terraform report obtains a Terraform tfplan.json file. The collected Terraform plan report will be uploaded to GitLab as an artifact and will be automatically shown in merge requests.
```yaml
plan:
stage: build
script:
- terraform plan -out=$PLAN
- terraform show --json $PLAN | convert_report > $PLAN_JSON
artifacts:
name: plan
paths:
- $PLAN
reports:
terraform: $PLAN_JSON
```
A full `.gitlab-ci.yaml` file could look like this:
```yaml
image:
name: hashicorp/terraform:light
entrypoint:
- '/usr/bin/env'
- 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
# Default output file for Terraform plan
variables:
GITLAB_TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/${CI_PROJECT_NAME}
PLAN: plan.tfplan
PLAN_JSON: tfplan.json
TF_ROOT: ${CI_PROJECT_DIR}
cache:
paths:
- .terraform
before_script:
- apk --no-cache add jq
- alias convert_report="jq -r '([.resource_changes[]?.change.actions?]|flatten)|{\"create\":(map(select(.==\"create\"))|length),\"update\":(map(select(.==\"update\"))|length),\"delete\":(map(select(.==\"delete\"))|length)}'"
- cd ${TF_ROOT}
- terraform --version
- terraform init -backend-config="address=${GITLAB_TF_ADDRESS}" -backend-config="lock_address=${GITLAB_TF_ADDRESS}/lock" -backend-config="unlock_address=${GITLAB_TF_ADDRESS}/lock" -backend-config="username=${GITLAB_USER_LOGIN}" -backend-config="password=${GITLAB_TF_PASSWORD}" -backend-config="lock_method=POST" -backend-config="unlock_method=DELETE" -backend-config="retry_wait_min=5"
stages:
- validate
- build
- deploy
validate:
stage: validate
script:
- terraform validate
plan:
stage: build
script:
- terraform plan -out=$PLAN
- terraform show --json $PLAN | convert_report > $PLAN_JSON
artifacts:
name: plan
paths:
- ${TF_ROOT}/plan.tfplan
reports:
terraform: ${TF_ROOT}/tfplan.json
# Separate apply job for manual launching Terraform as it can be destructive
# action.
apply:
stage: deploy
environment:
name: production
script:
- terraform apply -input=false $PLAN
dependencies:
- plan
when: manual
only:
- master
```
1. Running the pipeline displays the widget in the merge request, like this:
![MR Terraform widget](img/terraform_plan_widget_v13_0.png)
1. Clicking the **View Full Log** button in the widget takes you directly to the
plan output present in the pipeline logs:
![Terraform plan logs](img/terraform_plan_log_v13_0.png)
### Example `.gitlab-ci.yaml` file
```yaml
image:
name: hashicorp/terraform:light
entrypoint:
- '/usr/bin/env'
- 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
# Default output file for Terraform plan
variables:
GITLAB_TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/${CI_PROJECT_NAME}
PLAN: plan.tfplan
PLAN_JSON: tfplan.json
TF_ROOT: ${CI_PROJECT_DIR}
cache:
paths:
- .terraform
before_script:
- apk --no-cache add jq
- alias convert_report="jq -r '([.resource_changes[]?.change.actions?]|flatten)|{\"create\":(map(select(.==\"create\"))|length),\"update\":(map(select(.==\"update\"))|length),\"delete\":(map(select(.==\"delete\"))|length)}'"
- cd ${TF_ROOT}
- terraform --version
- terraform init -backend-config="address=${GITLAB_TF_ADDRESS}" -backend-config="lock_address=${GITLAB_TF_ADDRESS}/lock" -backend-config="unlock_address=${GITLAB_TF_ADDRESS}/lock" -backend-config="username=${GITLAB_USER_LOGIN}" -backend-config="password=${GITLAB_TF_PASSWORD}" -backend-config="lock_method=POST" -backend-config="unlock_method=DELETE" -backend-config="retry_wait_min=5"
stages:
- validate
- build
- deploy
validate:
stage: validate
script:
- terraform validate
plan:
stage: build
script:
- terraform plan -out=$PLAN
- terraform show --json $PLAN | convert_report > $PLAN_JSON
artifacts:
name: plan
paths:
- ${TF_ROOT}/plan.tfplan
reports:
terraform: ${TF_ROOT}/tfplan.json
# Separate apply job for manual launching Terraform as it can be destructive
# action.
apply:
stage: deploy
environment:
name: production
script:
- terraform apply -input=false $PLAN
dependencies:
- plan
when: manual
only:
- master
```

View file

@ -40,6 +40,9 @@ You can customize the payload by sending the following parameters. All fields ar
| `hosts` | String or Array | One or more hosts, as to where this incident occurred. |
| `severity` | String | The severity of the alert. Must be one of `critical`, `high`, `medium`, `low`, `info`, `unknown`. Default is `critical`. |
TIP: **Payload size:**
Ensure your requests are smaller than the [payload application limits](../../../administration/instance_limits.md#generic-alert-json-payloads).
Example request:
```shell

View file

@ -10,12 +10,14 @@ The relationship only shows up in the UI if the user can see both issues.
## Adding a related issue
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/2035) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.8.
> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/34239) in [GitLab Starter](https://about.gitlab.com/pricing/) 13.0.
> When you try to close an issue with open blockers, you'll see a warning that you can dismiss.
You can relate one issue to another by clicking the related issues "+" button
in the header of the related issue block. Then, input the issue reference number
or paste in the full URL of the issue.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/2035) in GitLab 12.8.
Additionally, you can select whether the current issue relates to, blocks, or is blocked by the issues being entered.
![Adding a related issue](img/related_issues_add_v12_8.png)

View file

@ -357,7 +357,7 @@ module Gitlab
def fetch_blob(sha, path)
return unless sha
Blob.lazy(repository.project, sha, path)
Blob.lazy(repository, sha, path)
end
def total_blob_lines(blob)

View file

@ -141,7 +141,7 @@ describe Gitlab::ImportExport::Group::LegacyTreeRestorer do
let(:filepath) { "group_exports/visibility_levels/#{visibility_level}" }
it "imports all subgroups as #{visibility_level}" do
expect(group.children.map(&:visibility_level)).to eq(expected_visibilities)
expect(group.children.map(&:visibility_level)).to match_array(expected_visibilities)
end
end
end

View file

@ -32,7 +32,7 @@ describe Blob do
it 'does not fetch blobs when none are accessed' do
expect(container.repository).not_to receive(:blobs_at)
described_class.lazy(container, commit_id, 'CHANGELOG')
described_class.lazy(container.repository, commit_id, 'CHANGELOG')
end
it 'fetches all blobs for the same repository when one is accessed' do
@ -41,10 +41,10 @@ describe Blob do
.once.and_call_original
expect(other_container.repository).not_to receive(:blobs_at)
changelog = described_class.lazy(container, commit_id, 'CHANGELOG')
contributing = described_class.lazy(same_container, commit_id, 'CONTRIBUTING.md')
changelog = described_class.lazy(container.repository, commit_id, 'CHANGELOG')
contributing = described_class.lazy(same_container.repository, commit_id, 'CONTRIBUTING.md')
described_class.lazy(other_container, commit_id, 'CHANGELOG')
described_class.lazy(other_container.repository, commit_id, 'CHANGELOG')
# Access property so the values are loaded
changelog.id
@ -52,14 +52,14 @@ describe Blob do
end
it 'does not include blobs from previous requests in later requests' do
changelog = described_class.lazy(container, commit_id, 'CHANGELOG')
contributing = described_class.lazy(same_container, commit_id, 'CONTRIBUTING.md')
changelog = described_class.lazy(container.repository, commit_id, 'CHANGELOG')
contributing = described_class.lazy(same_container.repository, commit_id, 'CONTRIBUTING.md')
# Access property so the values are loaded
changelog.id
contributing.id
readme = described_class.lazy(container, commit_id, 'README.md')
readme = described_class.lazy(container.repository, commit_id, 'README.md')
expect(container.repository).to receive(:blobs_at)
.with([[commit_id, 'README.md']], blob_size_limit: blob_size_limit).once.and_call_original

View file

@ -66,6 +66,43 @@ describe Deployments::OlderDeploymentsDropService do
expect(deployable.reload.failed?).to be_truthy
end
context 'when older deployable is a manual job' do
let(:older_deployment) { create(:deployment, :created, environment: environment, deployable: build) }
let(:build) { create(:ci_build, :manual) }
it 'does not drop any builds nor track the exception' do
expect(Gitlab::ErrorTracking).not_to receive(:track_exception)
expect { subject }.not_to change { Ci::Build.failed.count }
end
end
context 'when deployable.drop raises RuntimeError' do
before do
allow_any_instance_of(Ci::Build).to receive(:drop).and_raise(RuntimeError)
end
it 'does not drop an older deployment and tracks the exception' do
expect(Gitlab::ErrorTracking).to receive(:track_exception)
.with(kind_of(RuntimeError), subject_id: deployment.id, deployment_id: older_deployment.id)
expect { subject }.not_to change { Ci::Build.failed.count }
end
end
context 'when ActiveRecord::StaleObjectError is raised' do
before do
allow_any_instance_of(Ci::Build)
.to receive(:drop).and_raise(ActiveRecord::StaleObjectError)
end
it 'resets the object via Gitlab::OptimisticLocking' do
allow_any_instance_of(Ci::Build).to receive(:reset).at_least(:once)
subject
end
end
context 'and there is no deployable for that older deployment' do
let(:older_deployment) { create(:deployment, :running, environment: environment, deployable: nil) }