Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
353c244f5c
commit
6c36d81714
|
|
@ -38,11 +38,7 @@ module UpdateRepositoryStorageMethods
|
|||
rescue StandardError => e
|
||||
repository_storage_move.do_fail!
|
||||
|
||||
Gitlab::ErrorTracking.track_exception(e, container_klass: container.class.to_s, container_path: container.full_path)
|
||||
|
||||
ServiceResponse.error(
|
||||
message: s_("UpdateRepositoryStorage|Error moving repository storage for %{container_full_path} - %{message}") % { container_full_path: container.full_path, message: e.message }
|
||||
)
|
||||
Gitlab::ErrorTracking.track_and_raise_exception(e, container_klass: container.class.to_s, container_path: container.full_path)
|
||||
end
|
||||
|
||||
private
|
||||
|
|
|
|||
|
|
@ -24,13 +24,13 @@ restart()
|
|||
fi
|
||||
|
||||
pkill -u $gitlab_user -f 'sidekiq [0-9]'
|
||||
start_sidekiq -P $sidekiq_pidfile -d -L $sidekiq_logfile >> $sidekiq_logfile 2>&1
|
||||
start_sidekiq -P $sidekiq_pidfile -d -L $sidekiq_logfile "$@" >> $sidekiq_logfile 2>&1
|
||||
}
|
||||
|
||||
# Starts on foreground but output to the logfile instead stdout.
|
||||
start_silent()
|
||||
{
|
||||
start_sidekiq >> $sidekiq_logfile 2>&1
|
||||
start_sidekiq "$@" >> $sidekiq_logfile 2>&1
|
||||
}
|
||||
|
||||
start_sidekiq()
|
||||
|
|
@ -50,17 +50,17 @@ case "$1" in
|
|||
stop
|
||||
;;
|
||||
start)
|
||||
restart
|
||||
restart "$@"
|
||||
;;
|
||||
start_silent)
|
||||
warn "Deprecated: Will be removed at 13.0 (see https://gitlab.com/gitlab-org/gitlab/-/issues/196731)."
|
||||
start_silent
|
||||
;;
|
||||
start_foreground)
|
||||
start_sidekiq
|
||||
start_sidekiq "$@"
|
||||
;;
|
||||
restart)
|
||||
restart
|
||||
restart "$@"
|
||||
;;
|
||||
*)
|
||||
echo "Usage: RAILS_ENV=<env> $0 {stop|start|start_silent|start_foreground|restart}"
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ warn()
|
|||
echo "$@" 1>&2
|
||||
}
|
||||
|
||||
get_sidekiq_pid()
|
||||
get_sidekiq_pid()
|
||||
{
|
||||
if [ ! -f $sidekiq_pidfile ]; then
|
||||
warn "No pidfile found at $sidekiq_pidfile; is Sidekiq running?"
|
||||
|
|
@ -37,7 +37,7 @@ restart()
|
|||
fi
|
||||
|
||||
warn "Sidekiq output will be written to $sidekiq_logfile"
|
||||
start_sidekiq >> $sidekiq_logfile 2>&1
|
||||
start_sidekiq "$@" >> $sidekiq_logfile 2>&1
|
||||
}
|
||||
|
||||
start_sidekiq()
|
||||
|
|
@ -55,7 +55,7 @@ start_sidekiq()
|
|||
processes_args+=("*")
|
||||
done
|
||||
|
||||
${cmd} bin/sidekiq-cluster "${processes_args[@]}" -P $sidekiq_pidfile -e $RAILS_ENV
|
||||
${cmd} bin/sidekiq-cluster "${processes_args[@]}" -P $sidekiq_pidfile -e $RAILS_ENV "$@"
|
||||
}
|
||||
|
||||
case "$1" in
|
||||
|
|
@ -63,13 +63,13 @@ case "$1" in
|
|||
stop
|
||||
;;
|
||||
start)
|
||||
restart &
|
||||
restart "$@" &
|
||||
;;
|
||||
start_foreground)
|
||||
start_sidekiq
|
||||
start_sidekiq "$@"
|
||||
;;
|
||||
restart)
|
||||
restart &
|
||||
restart "$@" &
|
||||
;;
|
||||
*)
|
||||
echo "Usage: RAILS_ENV=<env> SIDEKIQ_WORKERS=<n> $0 {stop|start|start_foreground|restart}"
|
||||
|
|
|
|||
|
|
@ -120,7 +120,8 @@ From there, you can see the following actions:
|
|||
- Project access token was successfully created or revoked ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/230007) in GitLab 13.9)
|
||||
- Failed attempt to create or revoke a project access token ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/230007) in GitLab 13.9)
|
||||
- When default branch changes for a project ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/52339) in GitLab 13.9)
|
||||
- Created, updated, or deleted DAST profiles, DAST scanner profiles, and DAST site profiles ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217872))
|
||||
- Created, updated, or deleted DAST profiles, DAST scanner profiles, and DAST site profiles
|
||||
([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217872) in GitLab 14.1)
|
||||
|
||||
Project events can also be accessed via the [Project Audit Events API](../api/audit_events.md#project-audit-events).
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 82 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 37 KiB After Width: | Height: | Size: 80 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 35 KiB After Width: | Height: | Size: 76 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 62 KiB |
|
|
@ -6,21 +6,133 @@ disqus_identifier: 'https://docs.gitlab.com/ee/user/project/pipelines/settings.h
|
|||
type: reference, howto
|
||||
---
|
||||
|
||||
# Pipeline settings **(FREE)**
|
||||
# Customize pipeline configuration **(FREE)**
|
||||
|
||||
To reach the pipelines settings navigate to your project's
|
||||
**Settings > CI/CD**.
|
||||
|
||||
The following settings can be configured per project.
|
||||
You can customize how pipelines run for your project.
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
For an overview, watch the video [GitLab CI Pipeline, Artifacts, and Environments](https://www.youtube.com/watch?v=PCKDICEe10s).
|
||||
For an overview of pipelines, watch the video [GitLab CI Pipeline, Artifacts, and Environments](https://www.youtube.com/watch?v=PCKDICEe10s).
|
||||
Watch also [GitLab CI pipeline tutorial for beginners](https://www.youtube.com/watch?v=Jav4vbUrqII).
|
||||
|
||||
You can use the pipeline status to determine if a merge request can be merged:
|
||||
## Visibility of pipelines
|
||||
|
||||
- [Merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md).
|
||||
- [Only allow merge requests to be merged if the pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds).
|
||||
Pipeline visibility is determined by:
|
||||
|
||||
- Your current [user access level](../../user/permissions.md).
|
||||
- The **Public pipelines** project setting under your project's **Settings > CI/CD > General pipelines**.
|
||||
|
||||
NOTE:
|
||||
If the project visibility is set to **Private**, the [**Public pipelines** setting has no effect](../enable_or_disable_ci.md#per-project-user-setting).
|
||||
|
||||
This also determines the visibility of these related features:
|
||||
|
||||
- Job output logs
|
||||
- Job artifacts
|
||||
- The [pipeline security dashboard](../../user/application_security/security_dashboard/index.md#pipeline-security) **(ULTIMATE)**
|
||||
|
||||
Job logs and artifacts are [not visible for guest users and non-project members](https://gitlab.com/gitlab-org/gitlab/-/issues/25649).
|
||||
|
||||
If **Public pipelines** is enabled (default):
|
||||
|
||||
- For **public** projects, anyone can view the pipelines and related features.
|
||||
- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines
|
||||
and related features.
|
||||
- For **private** projects, any project member (Guest or higher) can view the pipelines
|
||||
and related features.
|
||||
|
||||
If **Public pipelines** is disabled:
|
||||
|
||||
- For **public** projects, anyone can view the pipelines, but only members
|
||||
(Reporter or higher) can access the related features.
|
||||
- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines.
|
||||
However, only members (reporter or higher) can access the job related features.
|
||||
- For **private** projects, only project members (reporter or higher)
|
||||
can view the pipelines or access the related features.
|
||||
|
||||
## Auto-cancel redundant pipelines
|
||||
|
||||
You can set pending or running pipelines to cancel automatically when a new pipeline runs on the same branch. You can enable this in the project settings:
|
||||
|
||||
1. Go to **Settings > CI/CD**.
|
||||
1. Expand **General Pipelines**.
|
||||
1. Check the **Auto-cancel redundant pipelines** checkbox.
|
||||
1. Click **Save changes**.
|
||||
|
||||
Use the [`interruptible`](../yaml/index.md#interruptible) keyword to indicate if a
|
||||
running job can be cancelled before it completes.
|
||||
|
||||
## Skip outdated deployment jobs
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25276) in GitLab 12.9.
|
||||
|
||||
Your project may have multiple concurrent deployment jobs that are
|
||||
scheduled to run in the same time frame.
|
||||
|
||||
This can lead to a situation where an older deployment job runs after a
|
||||
newer one, which may not be what you want.
|
||||
|
||||
To avoid this scenario:
|
||||
|
||||
1. Go to **Settings > CI/CD**.
|
||||
1. Expand **General pipelines**.
|
||||
1. Check the **Skip outdated deployment jobs** checkbox.
|
||||
1. Click **Save changes**.
|
||||
|
||||
When enabled, any older deployments job are skipped when a new deployment starts.
|
||||
|
||||
For more information, see [Deployment safety](../environments/deployment_safety.md).
|
||||
|
||||
## Retry outdated jobs
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211339) in GitLab 13.6.
|
||||
|
||||
A deployment job can fail because a newer one has run. If you retry the failed deployment job, the
|
||||
environment could be overwritten with older source code. If you click **Retry**, a modal warns you
|
||||
about this and asks for confirmation.
|
||||
|
||||
For more information, see [Deployment safety](../environments/deployment_safety.md).
|
||||
|
||||
## Custom CI/CD configuration file
|
||||
|
||||
> [Support for external `.gitlab-ci.yml` locations](https://gitlab.com/gitlab-org/gitlab/-/issues/14376) introduced in GitLab 12.6.
|
||||
|
||||
By default we look for the `.gitlab-ci.yml` file in the project's root
|
||||
directory. If needed, you can specify an alternate path and filename, including locations outside the project.
|
||||
|
||||
To customize the path:
|
||||
|
||||
1. Go to the project's **Settings > CI/CD**.
|
||||
1. Expand the **General pipelines** section.
|
||||
1. Provide a value in the **CI/CD configuration file** field.
|
||||
1. Click **Save changes**.
|
||||
|
||||
If the CI/CD configuration file is stored in the repository in a non-default
|
||||
location, the path must be relative to the root directory. Examples of valid
|
||||
paths and file names include:
|
||||
|
||||
- `.gitlab-ci.yml` (default)
|
||||
- `.my-custom-file.yml`
|
||||
- `my/path/.gitlab-ci.yml`
|
||||
- `my/path/.my-custom-file.yml`
|
||||
|
||||
If hosting the CI/CD configuration file on an external site, the URL link must end with `.yml`:
|
||||
|
||||
- `http://example.com/generate/ci/config.yml`
|
||||
|
||||
If hosting the CI/CD configuration file in a different project in GitLab, the path must be relative
|
||||
to the root directory in the other project. Include the group and project name at the end:
|
||||
|
||||
- `.gitlab-ci.yml@mygroup/another-project`
|
||||
- `my/path/.my-custom-file.yml@mygroup/another-project`
|
||||
|
||||
Hosting the configuration file in a separate project allows stricter control of the
|
||||
configuration file. For example:
|
||||
|
||||
- Create a public project to host the configuration file.
|
||||
- Give write permissions on the project only to users who are allowed to edit the file.
|
||||
|
||||
Other users and projects can access the configuration file without being
|
||||
able to edit it.
|
||||
|
||||
## Git strategy
|
||||
|
||||
|
|
@ -68,53 +180,6 @@ if the job surpasses the threshold, it is marked as failed.
|
|||
Project defined timeout (either specific timeout set by user or the default
|
||||
60 minutes timeout) may be [overridden for runners](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner).
|
||||
|
||||
## Maximum artifacts size **(FREE SELF)**
|
||||
|
||||
For information about setting a maximum artifact size for a project, see
|
||||
[Maximum artifacts size](../../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size).
|
||||
|
||||
## Custom CI/CD configuration file
|
||||
|
||||
> [Support for external `.gitlab-ci.yml` locations](https://gitlab.com/gitlab-org/gitlab/-/issues/14376) introduced in GitLab 12.6.
|
||||
|
||||
By default we look for the `.gitlab-ci.yml` file in the project's root
|
||||
directory. If needed, you can specify an alternate path and filename, including locations outside the project.
|
||||
|
||||
To customize the path:
|
||||
|
||||
1. Go to the project's **Settings > CI/CD**.
|
||||
1. Expand the **General pipelines** section.
|
||||
1. Provide a value in the **CI/CD configuration file** field.
|
||||
1. Click **Save changes**.
|
||||
|
||||
If the CI/CD configuration file is stored in the repository in a non-default
|
||||
location, the path must be relative to the root directory. Examples of valid
|
||||
paths and file names include:
|
||||
|
||||
- `.gitlab-ci.yml` (default)
|
||||
- `.my-custom-file.yml`
|
||||
- `my/path/.gitlab-ci.yml`
|
||||
- `my/path/.my-custom-file.yml`
|
||||
|
||||
If hosting the CI/CD configuration file on an external site, the URL link must end with `.yml`:
|
||||
|
||||
- `http://example.com/generate/ci/config.yml`
|
||||
|
||||
If hosting the CI/CD configuration file in a different project in GitLab, the path must be relative
|
||||
to the root directory in the other project. Include the group and project name at the end:
|
||||
|
||||
- `.gitlab-ci.yml@mygroup/another-project`
|
||||
- `my/path/.my-custom-file.yml@mygroup/another-project`
|
||||
|
||||
Hosting the configuration file in a separate project allows stricter control of the
|
||||
configuration file. For example:
|
||||
|
||||
- Create a public project to host the configuration file.
|
||||
- Give write permissions on the project only to users who are allowed to edit the file.
|
||||
|
||||
Other users and projects can access the configuration file without being
|
||||
able to edit it.
|
||||
|
||||
## Test coverage parsing
|
||||
|
||||
If you use test coverage in your code, GitLab can capture its output in the
|
||||
|
|
@ -184,84 +249,6 @@ For example:
|
|||
lein cloverage | perl -pe 's/\e\[?.*?[\@-~]//g'
|
||||
```
|
||||
|
||||
## Visibility of pipelines
|
||||
|
||||
Pipeline visibility is determined by:
|
||||
|
||||
- Your current [user access level](../../user/permissions.md).
|
||||
- The **Public pipelines** project setting under your project's **Settings > CI/CD > General pipelines**.
|
||||
|
||||
NOTE:
|
||||
If the project visibility is set to **Private**, the [**Public pipelines** setting has no effect](../enable_or_disable_ci.md#per-project-user-setting).
|
||||
|
||||
This also determines the visibility of these related features:
|
||||
|
||||
- Job output logs
|
||||
- Job artifacts
|
||||
- The [pipeline security dashboard](../../user/application_security/security_dashboard/index.md#pipeline-security) **(ULTIMATE)**
|
||||
|
||||
Job logs and artifacts are [not visible for guest users and non-project members](https://gitlab.com/gitlab-org/gitlab/-/issues/25649).
|
||||
|
||||
If **Public pipelines** is enabled (default):
|
||||
|
||||
- For **public** projects, anyone can view the pipelines and related features.
|
||||
- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines
|
||||
and related features.
|
||||
- For **private** projects, any project member (guest or higher) can view the pipelines
|
||||
and related features.
|
||||
|
||||
If **Public pipelines** is disabled:
|
||||
|
||||
- For **public** projects, anyone can view the pipelines, but only members
|
||||
(reporter or higher) can access the related features.
|
||||
- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines.
|
||||
However, only members (reporter or higher) can access the job related features.
|
||||
- For **private** projects, only project members (reporter or higher)
|
||||
can view the pipelines or access the related features.
|
||||
|
||||
## Auto-cancel redundant pipelines
|
||||
|
||||
You can set pending or running pipelines to cancel automatically when a new pipeline runs on the same branch. You can enable this in the project settings:
|
||||
|
||||
1. Go to **Settings > CI/CD**.
|
||||
1. Expand **General Pipelines**.
|
||||
1. Check the **Auto-cancel redundant pipelines** checkbox.
|
||||
1. Click **Save changes**.
|
||||
|
||||
Use the [`interruptible`](../yaml/index.md#interruptible) keyword to indicate if a
|
||||
running job can be cancelled before it completes.
|
||||
|
||||
## Skip outdated deployment jobs
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25276) in GitLab 12.9.
|
||||
|
||||
Your project may have multiple concurrent deployment jobs that are
|
||||
scheduled to run in the same time frame.
|
||||
|
||||
This can lead to a situation where an older deployment job runs after a
|
||||
newer one, which may not be what you want.
|
||||
|
||||
To avoid this scenario:
|
||||
|
||||
1. Go to **Settings > CI/CD**.
|
||||
1. Expand **General pipelines**.
|
||||
1. Check the **Skip outdated deployment jobs** checkbox.
|
||||
1. Click **Save changes**.
|
||||
|
||||
When enabled, any older deployments job are skipped when a new deployment starts.
|
||||
|
||||
For more information, see [Deployment safety](../environments/deployment_safety.md).
|
||||
|
||||
## Retry outdated jobs
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211339) in GitLab 13.6.
|
||||
|
||||
A deployment job can fail because a newer one has run. If you retry the failed deployment job, the
|
||||
environment could be overwritten with older source code. If you click **Retry**, a modal warns you
|
||||
about this and asks for confirmation.
|
||||
|
||||
For more information, see [Deployment safety](../environments/deployment_safety.md).
|
||||
|
||||
## Pipeline Badges
|
||||
|
||||
In the pipelines settings page you can find pipeline status and test coverage
|
||||
|
|
@ -353,6 +340,10 @@ https://gitlab.com/gitlab-org/gitlab/badges/main/coverage.svg?job=karma&key_text
|
|||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
- [Maximum artifacts size](../../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size).
|
||||
|
||||
<!-- ## Troubleshooting
|
||||
|
||||
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
|
||||
|
|
|
|||
|
|
@ -752,6 +752,7 @@ You can use CI/CD variables to customize DAST.
|
|||
| `DAST_AUTH_REPORT` | boolean | Used in combination with exporting the `gl-dast-debug-auth-report.html` artifact to aid in debugging authentication issues. |
|
||||
| `DAST_AUTH_VERIFICATION_SELECTOR` | selector | Verifies successful authentication by checking for presence of a selector once the login form has been submitted. Example: `css:.user-photo` |
|
||||
| `DAST_AUTH_VERIFICATION_LOGIN_FORM` | boolean | Verifies successful authentication by checking for the lack of a login form once the login form has been submitted. |
|
||||
| `DAST_ADVERTISE_SCAN` | boolean | Set to `true` to add a `Via` header to every request sent, advertising that the request was sent as part of a GitLab DAST scan. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/334947) in GitLab 14.1. |
|
||||
|
||||
1. Available to an on-demand DAST scan.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,94 @@
|
|||
---
|
||||
stage: Configure
|
||||
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/#assignments
|
||||
---
|
||||
|
||||
# New GKE cluster through IaC
|
||||
|
||||
Learn how to create a new cluster on Google Kubernetes Engine (GKE) through
|
||||
[Infrastructure as Code (IaC)](../../index.md).
|
||||
|
||||
This process combines the GitLab Terraform and Google Terraform providers
|
||||
with Kubernetes to help you create GKE clusters and deploy them through
|
||||
GitLab.
|
||||
|
||||
This document describes how to set up a [group-level cluster](../../../group/clusters/index.md) on GKE by importing an example project to get you started.
|
||||
You can then modify the project files according to your needs.
|
||||
|
||||
**Prerequisites:**
|
||||
|
||||
- A GitLab group.
|
||||
- A GitLab user with maintainer permissions to the group.
|
||||
- A [GitLab personal access token](../../../profile/personal_access_tokens.md) with `api` access, created by a user with maintainer permissions to the group.
|
||||
- A [Google Cloud Platform (GCP) service account](https://cloud.google.com/docs/authentication/getting-started).
|
||||
|
||||
**Steps:**
|
||||
|
||||
1. [Import the example project](#import-the-example-project).
|
||||
1. [Add your GCP credentials to GitLab](#add-your-gcp-credentials-to-gitlab).
|
||||
1. [Configure your project](#configure-your-project).
|
||||
1. [Deploy your cluster](#deploy-your-cluster).
|
||||
|
||||
## Import the example project
|
||||
|
||||
Start by [importing the example project by URL](../../../project/import/repo_by_url.md). Use `https://gitlab.com/gitlab-org/configure/examples/gitlab-terraform-gke.git` as URL.
|
||||
|
||||
## Add your GCP credentials to GitLab
|
||||
|
||||
After importing the project, you need to set up [CI environment variables](../../../../ci/variables/index.md) to associate your cluster on GCP to your group in GitLab.
|
||||
|
||||
We advise that you [set environment variables through the GitLab UI](../../../../ci/variables/index.md#add-a-cicd-variable-to-a-project)
|
||||
so that your credentials are not exposed through the code. To do so, follow the steps below.
|
||||
|
||||
### Prepare your credentials on GCP
|
||||
|
||||
1. Create a [GCP service account](https://cloud.google.com/docs/authentication/getting-started) to authenticate GCP with GitLab. It needs the following roles: `Computer Network Viewer`, `Kubernetes Engine Admin`, and `Service Account User`.
|
||||
1. Download the JSON file with the service account key.
|
||||
1. On your computer, encode the JSON file to `base64` (replace `/path/to/sa-key.json` to the path to your key):
|
||||
|
||||
```shell
|
||||
base64 /path/to/sa-key.json | tr -d \\n`
|
||||
```
|
||||
|
||||
1. Use the output of this command as the `BASE64_GOOGLE_CREDENTIALS` environment variable in the next step.
|
||||
|
||||
### Add your credentials to GitLab as environment variables
|
||||
|
||||
1. On GitLab, from your project's sidebar, go to **Settings > CI/CD** and expand **Variables**.
|
||||
1. Add your `GITLAB_TOKEN` ([personal access token](../../../profile/personal_access_tokens.md)).
|
||||
1. Add the variable `BASE64_GOOGLE_CREDENTIALS` from the previous step.
|
||||
|
||||
## Configure your project
|
||||
|
||||
After authenticating with GCP, replace the project's defaults from the example
|
||||
project with your own. To do so, edit the files as described below.
|
||||
|
||||
Edit `gke.tf`:
|
||||
|
||||
1. **(Required)** Replace the GCP `project` with a unique project name.
|
||||
1. **(Optional)** Choose the `name` of your cluster.
|
||||
1. **(Optional)** Choose the `region` and `zone` that you would like to deploy your cluster to.
|
||||
1. Push the changes to your project's default branch.
|
||||
|
||||
Edit `group_cluster.tf`:
|
||||
|
||||
1. **(Required)**: Replace the `full_path` with the path to your group.
|
||||
1. **(Optional)**: Choose your cluster base domain through `domain`.
|
||||
1. **(Optional)**: Choose your environment through `environment_scope`.
|
||||
1. Push the changes to your project's default branch.
|
||||
|
||||
Refer to the [GitLab Terraform provider](https://registry.terraform.io/providers/gitlabhq/gitlab/latest/docs) and the [Google Terraform provider](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference) documentation for further resource options.
|
||||
|
||||
## Deploy your cluster
|
||||
|
||||
After adjusting the files in the previous step, manually trigger the deployment of your cluster. In GitLab:
|
||||
|
||||
1. From your project's sidebar, go to **CI/CD > Pipelines**.
|
||||
1. Select the dropdown icon (**{angle-down}**) next to the play icon (**{play}**).
|
||||
1. Select **deploy** to manually trigger the deployment job.
|
||||
|
||||
When the pipeline finishes successfully, you can see your new cluster:
|
||||
|
||||
- In GCP: on your [GCP console's Kubernetes list](https://console.cloud.google.com/kubernetes/list).
|
||||
- In GitLab: from your project's sidebar, select **Infrastructure > Kubernetes clusters**.
|
||||
|
|
@ -101,3 +101,7 @@ owned by GitLab, where everyone can contribute.
|
|||
|
||||
The [documentation of the provider](https://registry.terraform.io/providers/gitlabhq/gitlab/latest/docs)
|
||||
is available as part of the official Terraform provider documentations.
|
||||
|
||||
## Create a new cluster through IaC
|
||||
|
||||
Learn how to [create a new cluster on Google Kubernetes Engine (GKE)](clusters/connect/new_gke_cluster.md).
|
||||
|
|
|
|||
|
|
@ -10,17 +10,22 @@ type: reference, howto
|
|||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1984) in GitLab 9.3.
|
||||
> - Made [available in all tiers](https://gitlab.com/gitlab-org/gitlab/-/issues/212499) in 13.2.
|
||||
|
||||
Ensuring your project's code stays simple, readable and easy to contribute to can be problematic. With the help of [GitLab CI/CD](../../../ci/index.md), you can analyze your
|
||||
source code quality using GitLab Code Quality.
|
||||
To ensure your project's code stays simple, readable, and easy to contribute to,
|
||||
you can use [GitLab CI/CD](../../../ci/index.md) to analyze your source code quality.
|
||||
|
||||
For example, while you're implementing a feature, you can run Code Quality reports
|
||||
to analyze how your improvements are impacting your code's quality. You can
|
||||
use this information to ensure that your changes are improving performance rather
|
||||
than degrading it.
|
||||
|
||||
Code Quality:
|
||||
|
||||
- Uses [Engines](https://docs.codeclimate.com/docs/list-of-engines) supported by Code Climate, which are
|
||||
- Uses [plugins](https://docs.codeclimate.com/docs/list-of-engines) supported by Code Climate, which are
|
||||
free and open source. Code Quality does not require a Code Climate
|
||||
subscription.
|
||||
- Runs in [pipelines](../../../ci/pipelines/index.md) using a Docker image built in the
|
||||
[GitLab Code
|
||||
Quality](https://gitlab.com/gitlab-org/ci-cd/codequality) project using [default Code Climate configurations](https://gitlab.com/gitlab-org/ci-cd/codequality/-/tree/master/codeclimate_defaults).
|
||||
- Runs in [pipelines](../../../ci/pipelines/index.md) by using a Docker image built in the
|
||||
[GitLab Code Quality](https://gitlab.com/gitlab-org/ci-cd/codequality) project.
|
||||
- Uses [default Code Climate configurations](https://gitlab.com/gitlab-org/ci-cd/codequality/-/tree/master/codeclimate_defaults).
|
||||
- Can make use of a [template](#example-configuration).
|
||||
- Is available by using [Auto Code Quality](../../../topics/autodevops/stages.md#auto-code-quality), provided by [Auto DevOps](../../../topics/autodevops/index.md).
|
||||
- Can be extended through [Analysis Plugins](https://docs.codeclimate.com/docs/list-of-engines) or a [custom tool](#implementing-a-custom-tool).
|
||||
|
|
@ -75,21 +80,6 @@ Feature.disable(:codequality_mr_diff_annotations)
|
|||
Feature.disable(:codequality_mr_diff_annotations, Project.find(<project id>))
|
||||
```
|
||||
|
||||
## Use cases
|
||||
|
||||
For instance, consider the following workflow:
|
||||
|
||||
1. Your backend team member starts a new implementation for making a certain
|
||||
feature in your app faster.
|
||||
1. With Code Quality reports, they analyze how their implementation is impacting
|
||||
the code quality.
|
||||
1. The metrics show that their code degrades the quality by 10 points.
|
||||
1. You ask a co-worker to help them with this modification.
|
||||
1. They both work on the changes until Code Quality report displays no
|
||||
degradations, only improvements.
|
||||
1. You approve the merge request and authorize its deployment to staging.
|
||||
1. Once verified, their changes are deployed to production.
|
||||
|
||||
## Example configuration
|
||||
|
||||
This example shows how to run Code Quality on your code by using GitLab CI/CD and Docker.
|
||||
|
|
|
|||
|
|
@ -4,40 +4,54 @@ group: Release
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Create a GitLab Pages website from scratch **(FREE)**
|
||||
# Tutorial: Create a GitLab Pages website from scratch **(FREE)**
|
||||
|
||||
This tutorial shows you how to create a Pages site from scratch. You start with
|
||||
a blank project and create your own CI file, which gives instruction to
|
||||
a [runner](https://docs.gitlab.com/runner/). When your CI/CD
|
||||
This tutorial shows you how to create a Pages site from scratch using
|
||||
the [Jekyll](https://jekyllrb.com/) Static Site Generator (SSG). You start with
|
||||
a blank project and create your own CI/CD configuration file, which gives
|
||||
instructions to a [runner](https://docs.gitlab.com/runner/). When your CI/CD
|
||||
[pipeline](../../../../ci/pipelines/index.md) runs, the Pages site is created.
|
||||
|
||||
This example uses the [Jekyll](https://jekyllrb.com/) Static Site Generator (SSG).
|
||||
Other SSGs follow similar steps. You do not need to be familiar with Jekyll or SSGs
|
||||
This example uses Jekyll, but other SSGs follow similar steps.
|
||||
You do not need to be familiar with Jekyll or SSGs
|
||||
to complete this tutorial.
|
||||
|
||||
To create a GitLab Pages website:
|
||||
|
||||
- [Step 1: Create the project files](#create-the-project-files)
|
||||
- [Step 2: Choose a Docker image](#choose-a-docker-image)
|
||||
- [Step 3: Install Jekyll](#install-jekyll)
|
||||
- [Step 4: Specify the `public` directory for output](#specify-the-public-directory-for-output)
|
||||
- [Step 5: Specify the `public` directory for artifacts](#specify-the-public-directory-for-artifacts)
|
||||
- [Step 6: Deploy and view your website](#deploy-and-view-your-website)
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To follow along with this example, start with a blank project in GitLab.
|
||||
Create three files in the root (top-level) directory.
|
||||
You must have a [blank project](../../working_with_projects.md#blank-projects) in GitLab.
|
||||
|
||||
- `.gitlab-ci.yml` A YAML file that contains the commands you want to run.
|
||||
For now, leave the file's contents blank.
|
||||
## Create the project files
|
||||
|
||||
- `index.html` An HTML file you can populate with whatever HTML content you'd like,
|
||||
for example:
|
||||
Create three files in the root (top-level) directory:
|
||||
|
||||
```html
|
||||
<html>
|
||||
<head>
|
||||
<title>Home</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Hello World!</h1>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
- `.gitlab-ci.yml`: A YAML file that contains the commands you want to run.
|
||||
For now, leave the file's contents blank.
|
||||
|
||||
- `index.html`: An HTML file you can populate with whatever HTML content
|
||||
you'd like, for example:
|
||||
|
||||
```html
|
||||
<html>
|
||||
<head>
|
||||
<title>Home</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Hello World!</h1>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
- [`Gemfile`](https://bundler.io/gemfile.html): A file that describes dependencies for Ruby programs.
|
||||
|
||||
- [`Gemfile`](https://bundler.io/gemfile.html) A file that describes dependencies for Ruby programs.
|
||||
Populate it with this content:
|
||||
|
||||
```ruby
|
||||
|
|
@ -53,7 +67,7 @@ to run scripts and deploy the site.
|
|||
|
||||
This specific Ruby image is maintained on [DockerHub](https://hub.docker.com/_/ruby).
|
||||
|
||||
Edit your `.gitlab-ci.yml` and add this text as the first line.
|
||||
Edit your `.gitlab-ci.yml` file and add this text as the first line:
|
||||
|
||||
```yaml
|
||||
image: ruby:2.7
|
||||
|
|
@ -65,13 +79,15 @@ image that contains NodeJS as part of its file system. For example, for a
|
|||
|
||||
## Install Jekyll
|
||||
|
||||
To run [Jekyll](https://jekyllrb.com/) locally, you would open your terminal and:
|
||||
To run [Jekyll](https://jekyllrb.com/) locally, you must install it:
|
||||
|
||||
- Install [Bundler](https://bundler.io/) by running `gem install bundler`.
|
||||
- Create `Gemfile.lock` by running `bundle install`.
|
||||
- Install Jekyll by running `bundle exec jekyll build`.
|
||||
1. Open your terminal.
|
||||
1. Install [Bundler](https://bundler.io/) by running `gem install bundler`.
|
||||
1. Create `Gemfile.lock` by running `bundle install`.
|
||||
1. Install Jekyll by running `bundle exec jekyll build`.
|
||||
|
||||
In the `.gitlab-ci.yml` file, this is written as:
|
||||
To run Jekyll in your project, edit the `.gitlab-ci.yml` file
|
||||
and add the installation commands:
|
||||
|
||||
```yaml
|
||||
script:
|
||||
|
|
@ -109,7 +125,8 @@ pages:
|
|||
Jekyll needs to know where to generate its output.
|
||||
GitLab Pages only considers files in a directory called `public`.
|
||||
|
||||
Jekyll uses destination (`-d`) to specify an output directory for the built website:
|
||||
Jekyll uses a destination flag (`-d`) to specify an output directory for the built website.
|
||||
Add the destination to your `.gitlab-ci.yml` file:
|
||||
|
||||
```yaml
|
||||
pages:
|
||||
|
|
@ -136,7 +153,7 @@ pages:
|
|||
- public
|
||||
```
|
||||
|
||||
Paste this into `.gitlab-ci.yml` file, so it now looks like this:
|
||||
Your `.gitlab-ci.yml` file should now look like this:
|
||||
|
||||
```yaml
|
||||
image: ruby:2.7
|
||||
|
|
@ -151,23 +168,29 @@ pages:
|
|||
- public
|
||||
```
|
||||
|
||||
Now save and commit the `.gitlab-ci.yml` file. You can watch the pipeline run
|
||||
by going to **CI/CD > Pipelines**.
|
||||
## Deploy and view your website
|
||||
|
||||
When it succeeds, go to **Settings > Pages** to view the URL where your site
|
||||
is now available.
|
||||
After you have completed the preceding steps,
|
||||
deploy your website:
|
||||
|
||||
1. Save and commit the `.gitlab-ci.yml` file.
|
||||
1. Go to **CI/CD > Pipelines** to watch the pipeline.
|
||||
1. When the pipeline succeeds, go to **Settings > Pages**
|
||||
to view the URL where your site is now available.
|
||||
|
||||
When this `pages` job completes successfully, a special `pages:deploy` job
|
||||
appears in the pipeline view. It prepares the content of the website for the
|
||||
GitLab Pages daemon. GitLab runs it in the background and doesn't use a runner.
|
||||
|
||||
## Other options for your CI/CD file
|
||||
|
||||
If you want to do more advanced tasks, you can update your `.gitlab-ci.yml` file
|
||||
with [any of the available settings](../../../../ci/yaml/index.md). You can validate
|
||||
your `.gitlab-ci.yml` file with the [CI Lint](../../../../ci/lint.md) tool that's included with GitLab.
|
||||
|
||||
After successful execution of this `pages` job, a special `pages:deploy` job appears in the
|
||||
pipeline view. It prepares the content of the website for GitLab Pages daemon. GitLab executes it in
|
||||
the background and doesn't use runner.
|
||||
|
||||
The following topics show other examples of other options you can add to your CI/CD file.
|
||||
|
||||
## Deploy specific branches to a Pages site
|
||||
### Deploy specific branches to a Pages site
|
||||
|
||||
You may want to deploy to a Pages site only from specific branches.
|
||||
|
||||
|
|
@ -191,7 +214,8 @@ pages:
|
|||
- public
|
||||
```
|
||||
|
||||
Then configure the pipeline to run the job for the `master` branch only.
|
||||
Then configure the pipeline to run the job for the
|
||||
[default branch](../../repository/branches/default.md) (here, `main`) only.
|
||||
|
||||
```yaml
|
||||
image: ruby:2.7
|
||||
|
|
@ -209,17 +233,17 @@ pages:
|
|||
paths:
|
||||
- public
|
||||
rules:
|
||||
- if: '$CI_COMMIT_BRANCH == "master"'
|
||||
- if: '$CI_COMMIT_BRANCH == "main"'
|
||||
```
|
||||
|
||||
## Specify a stage to deploy
|
||||
### Specify a stage to deploy
|
||||
|
||||
There are three default stages for GitLab CI/CD: build, test,
|
||||
and deploy.
|
||||
|
||||
If you want to test your script and check the built site before deploying
|
||||
to production, you can run the test exactly as it runs when you
|
||||
push to `master`.
|
||||
push to your [default branch](../../repository/branches/default.md) (here, `main`).
|
||||
|
||||
To specify a stage for your job to run in,
|
||||
add a `stage` line to your CI file:
|
||||
|
|
@ -241,11 +265,11 @@ pages:
|
|||
paths:
|
||||
- public
|
||||
rules:
|
||||
- if: '$CI_COMMIT_BRANCH == "master"'
|
||||
- if: '$CI_COMMIT_BRANCH == "main"'
|
||||
```
|
||||
|
||||
Now add another job to the CI file, telling it to
|
||||
test every push to every branch **except** the `master` branch:
|
||||
test every push to every branch **except** the `main` branch:
|
||||
|
||||
```yaml
|
||||
image: ruby:2.7
|
||||
|
|
@ -264,7 +288,7 @@ pages:
|
|||
paths:
|
||||
- public
|
||||
rules:
|
||||
- if: '$CI_COMMIT_BRANCH == "master"'
|
||||
- if: '$CI_COMMIT_BRANCH == "main"'
|
||||
|
||||
test:
|
||||
stage: test
|
||||
|
|
@ -276,19 +300,19 @@ test:
|
|||
paths:
|
||||
- test
|
||||
rules:
|
||||
- if: '$CI_COMMIT_BRANCH != "master"'
|
||||
- if: '$CI_COMMIT_BRANCH != "main"'
|
||||
```
|
||||
|
||||
When the `test` job runs in the `test` stage, Jekyll
|
||||
builds the site in a directory called `test`. The job affects
|
||||
all branches except `master`.
|
||||
all branches except `main`.
|
||||
|
||||
When you apply stages to different jobs, every job in the same
|
||||
stage builds in parallel. If your web application needs more than
|
||||
one test before being deployed, you can run all your tests at the
|
||||
same time.
|
||||
|
||||
## Remove duplicate commands
|
||||
### Remove duplicate commands
|
||||
|
||||
To avoid duplicating the same scripts in every job, you can add them
|
||||
to a `before_script` section.
|
||||
|
|
@ -317,7 +341,7 @@ pages:
|
|||
paths:
|
||||
- public
|
||||
rules:
|
||||
- if: '$CI_COMMIT_BRANCH == "master"'
|
||||
- if: '$CI_COMMIT_BRANCH == "main"'
|
||||
|
||||
test:
|
||||
stage: test
|
||||
|
|
@ -327,10 +351,10 @@ test:
|
|||
paths:
|
||||
- test
|
||||
rules:
|
||||
- if: '$CI_COMMIT_BRANCH != "master"'
|
||||
- if: '$CI_COMMIT_BRANCH != "main"'
|
||||
```
|
||||
|
||||
## Build faster with cached dependencies
|
||||
### Build faster with cached dependencies
|
||||
|
||||
To build faster, you can cache the installation files for your
|
||||
project's dependencies by using the `cache` parameter.
|
||||
|
|
@ -361,7 +385,7 @@ pages:
|
|||
paths:
|
||||
- public
|
||||
rules:
|
||||
- if: '$CI_COMMIT_BRANCH == "master"'
|
||||
- if: '$CI_COMMIT_BRANCH == "main"'
|
||||
|
||||
test:
|
||||
stage: test
|
||||
|
|
@ -371,7 +395,7 @@ test:
|
|||
paths:
|
||||
- test
|
||||
rules:
|
||||
- if: '$CI_COMMIT_BRANCH != "master"'
|
||||
- if: '$CI_COMMIT_BRANCH != "main"'
|
||||
```
|
||||
|
||||
In this case, you need to exclude the `/vendor`
|
||||
|
|
@ -386,10 +410,11 @@ exclude:
|
|||
- vendor
|
||||
```
|
||||
|
||||
Now GitLab CI/CD not only builds the website,
|
||||
but also pushes with **continuous tests** to feature-branches,
|
||||
**caches** dependencies installed with Bundler, and
|
||||
**continuously deploys** every push to the `master` branch.
|
||||
Now GitLab CI/CD not only builds the website, but also:
|
||||
|
||||
- Pushes with **continuous tests** to feature branches.
|
||||
- **Caches** dependencies installed with Bundler.
|
||||
- **Continuously deploys** every push to the `main` branch.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
|
|
|||
|
|
@ -35016,9 +35016,6 @@ msgstr ""
|
|||
msgid "UpdateProject|Project could not be updated!"
|
||||
msgstr ""
|
||||
|
||||
msgid "UpdateRepositoryStorage|Error moving repository storage for %{container_full_path} - %{message}"
|
||||
msgstr ""
|
||||
|
||||
msgid "UpdateRepositoryStorage|Failed to verify %{type} repository checksum from %{old} to %{new}"
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -71,7 +71,9 @@ module QA
|
|||
ActiveSupport::Deprecation.warn("CHROME_HEADLESS is deprecated. Use WEBDRIVER_HEADLESS instead.")
|
||||
end
|
||||
|
||||
enabled?(ENV['WEBDRIVER_HEADLESS']) || enabled?(ENV['CHROME_HEADLESS'])
|
||||
return enabled?(ENV['WEBDRIVER_HEADLESS']) unless ENV['WEBDRIVER_HEADLESS'].nil?
|
||||
|
||||
enabled?(ENV['CHROME_HEADLESS'])
|
||||
end
|
||||
|
||||
# set to 'true' to have Chrome use a fixed profile directory
|
||||
|
|
@ -336,7 +338,7 @@ module QA
|
|||
# the feature is supported in the environment under test.
|
||||
# All features are supported by default.
|
||||
def can_test?(feature)
|
||||
raise ArgumentError, %Q(Unknown feature "#{feature}") unless SUPPORTED_FEATURES.include? feature
|
||||
raise ArgumentError, %(Unknown feature "#{feature}") unless SUPPORTED_FEATURES.include? feature
|
||||
|
||||
enabled?(ENV[SUPPORTED_FEATURES[feature]], default: true)
|
||||
end
|
||||
|
|
@ -398,7 +400,9 @@ module QA
|
|||
|
||||
def remote_grid_credentials
|
||||
if remote_grid_username
|
||||
raise ArgumentError, %Q(Please provide an access key for user "#{remote_grid_username}") unless remote_grid_access_key
|
||||
unless remote_grid_access_key
|
||||
raise ArgumentError, %(Please provide an access key for user "#{remote_grid_username}")
|
||||
end
|
||||
|
||||
return "#{remote_grid_username}:#{remote_grid_access_key}@"
|
||||
end
|
||||
|
|
|
|||
|
|
@ -55,11 +55,6 @@ RSpec.describe QA::Runtime::Env do
|
|||
end
|
||||
|
||||
describe '.webdriver_headless?' do
|
||||
before do
|
||||
# We need to set this because we have a fallback for CHROME_HEADLESS
|
||||
stub_env('CHROME_HEADLESS', 'false')
|
||||
end
|
||||
|
||||
it_behaves_like 'boolean method',
|
||||
method: :webdriver_headless?,
|
||||
env_key: 'WEBDRIVER_HEADLESS',
|
||||
|
|
|
|||
|
|
@ -83,9 +83,10 @@ RSpec.describe Projects::UpdateRepositoryStorageService do
|
|||
.with(project.repository.raw)
|
||||
.and_raise(Gitlab::Git::CommandError)
|
||||
|
||||
result = subject.execute
|
||||
expect do
|
||||
subject.execute
|
||||
end.to raise_error(Gitlab::Git::CommandError)
|
||||
|
||||
expect(result).to be_error
|
||||
expect(project).not_to be_repository_read_only
|
||||
expect(project.repository_storage).to eq('default')
|
||||
expect(repository_storage_move).to be_failed
|
||||
|
|
@ -101,9 +102,10 @@ RSpec.describe Projects::UpdateRepositoryStorageService do
|
|||
expect(original_project_repository_double).to receive(:remove)
|
||||
.and_raise(Gitlab::Git::CommandError)
|
||||
|
||||
result = subject.execute
|
||||
expect do
|
||||
subject.execute
|
||||
end.to raise_error(Gitlab::Git::CommandError)
|
||||
|
||||
expect(result).to be_error
|
||||
expect(repository_storage_move).to be_cleanup_failed
|
||||
end
|
||||
end
|
||||
|
|
@ -118,9 +120,10 @@ RSpec.describe Projects::UpdateRepositoryStorageService do
|
|||
expect(project_repository_double).to receive(:checksum)
|
||||
.and_return('not matching checksum')
|
||||
|
||||
result = subject.execute
|
||||
expect do
|
||||
subject.execute
|
||||
end.to raise_error(UpdateRepositoryStorageMethods::Error, /Failed to verify project repository checksum/)
|
||||
|
||||
expect(result).to be_error
|
||||
expect(project).not_to be_repository_read_only
|
||||
expect(project.repository_storage).to eq('default')
|
||||
end
|
||||
|
|
|
|||
|
|
@ -75,9 +75,10 @@ RSpec.describe Snippets::UpdateRepositoryStorageService do
|
|||
.with(snippet.repository.raw)
|
||||
.and_raise(Gitlab::Git::CommandError)
|
||||
|
||||
result = subject.execute
|
||||
expect do
|
||||
subject.execute
|
||||
end.to raise_error(Gitlab::Git::CommandError)
|
||||
|
||||
expect(result).to be_error
|
||||
expect(snippet).not_to be_repository_read_only
|
||||
expect(snippet.repository_storage).to eq('default')
|
||||
expect(repository_storage_move).to be_failed
|
||||
|
|
@ -93,9 +94,10 @@ RSpec.describe Snippets::UpdateRepositoryStorageService do
|
|||
expect(original_snippet_repository_double).to receive(:remove)
|
||||
.and_raise(Gitlab::Git::CommandError)
|
||||
|
||||
result = subject.execute
|
||||
expect do
|
||||
subject.execute
|
||||
end.to raise_error(Gitlab::Git::CommandError)
|
||||
|
||||
expect(result).to be_error
|
||||
expect(repository_storage_move).to be_cleanup_failed
|
||||
end
|
||||
end
|
||||
|
|
@ -107,9 +109,10 @@ RSpec.describe Snippets::UpdateRepositoryStorageService do
|
|||
expect(snippet_repository_double).to receive(:checksum)
|
||||
.and_return('not matching checksum')
|
||||
|
||||
result = subject.execute
|
||||
expect do
|
||||
subject.execute
|
||||
end.to raise_error(UpdateRepositoryStorageMethods::Error, /Failed to verify snippet repository checksum from \w+ to not matching checksum/)
|
||||
|
||||
expect(result).to be_error
|
||||
expect(snippet).not_to be_repository_read_only
|
||||
expect(snippet.repository_storage).to eq('default')
|
||||
end
|
||||
|
|
|
|||
|
|
@ -123,9 +123,10 @@ RSpec.shared_examples 'moves repository to another storage' do |repository_type|
|
|||
.with(repository.raw)
|
||||
.and_raise(Gitlab::Git::CommandError)
|
||||
|
||||
result = subject.execute
|
||||
expect do
|
||||
subject.execute
|
||||
end.to raise_error(Gitlab::Git::CommandError)
|
||||
|
||||
expect(result).to be_error
|
||||
expect(project).not_to be_repository_read_only
|
||||
expect(project.repository_storage).to eq('default')
|
||||
expect(repository_storage_move).to be_failed
|
||||
|
|
@ -149,9 +150,10 @@ RSpec.shared_examples 'moves repository to another storage' do |repository_type|
|
|||
expect(original_repository_double).to receive(:remove)
|
||||
.and_raise(Gitlab::Git::CommandError)
|
||||
|
||||
result = subject.execute
|
||||
expect do
|
||||
subject.execute
|
||||
end.to raise_error(Gitlab::Git::CommandError)
|
||||
|
||||
expect(result).to be_error
|
||||
expect(repository_storage_move).to be_cleanup_failed
|
||||
end
|
||||
end
|
||||
|
|
@ -170,9 +172,10 @@ RSpec.shared_examples 'moves repository to another storage' do |repository_type|
|
|||
allow(repository_double).to receive(:checksum)
|
||||
.and_return('not matching checksum')
|
||||
|
||||
result = subject.execute
|
||||
expect do
|
||||
subject.execute
|
||||
end.to raise_error(UpdateRepositoryStorageMethods::Error, /Failed to verify \w+ repository checksum from \w+ to not matching checksum/)
|
||||
|
||||
expect(result).to be_error
|
||||
expect(project).not_to be_repository_read_only
|
||||
expect(project.repository_storage).to eq('default')
|
||||
end
|
||||
|
|
|
|||
Loading…
Reference in New Issue