root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2022-06-17 03:08:38 +00:00
parent 97349b374f
commit 80816914ff
30 changed files with 738 additions and 735 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
app/assets/javascripts/design_management/pages/index.vue
View File

@ -374,7 +374,7 @@ export default {
>
<gl-button
v-if="isLatestVersion"
variant="link"
category="tertiary"
size="small"
class="gl-mr-3"
data-testid="select-all-designs-button"

3
app/assets/stylesheets/themes/theme_helper.scss
View File

@ -97,8 +97,7 @@
.notification-dot {
will-change: border-color, background-color;
// stylelint-disable-next-line
border-color: $nav-svg-color + 33;
border-color: adjust-color($nav-svg-color, $red: 33, $green: 33, $blue: 33);
}
&.header-help-dropdown-toggle .notification-dot {

2
doc/administration/auth/index.md
View File

@ -30,7 +30,7 @@ For more information, see the links shown on this page for each external provide
| **User Provisioning** | SCIM<br>Just-In-Time (JIT) Provisioning | LDAP Sync |
| **User Detail Updating** (not group management) | Not Available | LDAP Sync |
| **Authentication** | SAML at top-level group (1 provider) | LDAP (multiple providers)<br>Generic OAuth2<br>SAML (only 1 permitted per unique provider)<br>Kerberos<br>JWT<br>Smartcard<br>OmniAuth Providers (only 1 permitted per unique provider) |
| **Provider-to-GitLab Role Sync** | SAML Group Sync | LDAP Group Sync |
| **Provider-to-GitLab Role Sync** | SAML Group Sync | LDAP Group Sync<br>SAML Group Sync ([GitLab 15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/285150) and later) |
| **User Removal** | SCIM (remove user from top-level group) | LDAP (Blocking User from Instance) |
## Change apps or configuration

2
doc/administration/auth/ldap/index.md
View File

@ -169,7 +169,7 @@ These configuration settings are available:
| `host` | IP address or domain name of your LDAP server. Ignored when `hosts` is defined. | **{check-circle}** Yes | `'ldap.mydomain.com'` |
| `port` | The port to connect with on your LDAP server. Always an integer, not a string. Ignored when `hosts` is defined. | **{check-circle}** Yes | `389` or `636` (for SSL) |
| `hosts` (GitLab 14.7 and later) | An array of host and port pairs to open connections. | **{dotted-circle}** No | `[['ldap1.mydomain.com', 636], ['ldap2.mydomain.com', 636]]` |
| `uid` | LDAP attribute for username. Should be the attribute, not the value that maps to the `uid`. | **{check-circle}** Yes | `'sAMAccountName'` or `'uid'` or `'userPrincipalName'` |
| `uid` | The LDAP attribute that maps to the username that users use to sign in. Should be the attribute, not the value that maps to the `uid`. Does not affect the GitLab username (see [attributes section](#attribute-configuration-settings)). | **{check-circle}** Yes | `'sAMAccountName'` or `'uid'` or `'userPrincipalName'` |
| `bind_dn` | The full DN of the user you bind with. | **{dotted-circle}** No | `'america\momo'` or `'CN=Gitlab,OU=Users,DC=domain,DC=com'` |
| `password` | The password of the bind user. | **{dotted-circle}** No | `'your_great_password'` |
| `encryption` | Encryption method. The `method` key is deprecated in favor of `encryption`. | **{check-circle}** Yes | `'start_tls'` or `'simple_tls'` or `'plain'` |

249
doc/ci/cloud_deployment/ecs/deploy_to_aws_ecs.md Normal file
View File

@ -0,0 +1,249 @@
---
stage: Release
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
---
# Deploy to Amazon Elastic Container Service **(FREE)**
This step-by-step guide helps you deploy a project hosted on GitLab.com to
the Amazon [Elastic Container Service (ECS)](https://aws.amazon.com/ecs/).
In this guide, you begin by creating an ECS cluster manually using the AWS console. You create and
deploy a simple application that you create from a GitLab template.
These instructions work for both SaaS and self-managed GitLab instances.
Ensure your own [runners are configured](../../runners/index.md).
## Prerequisites
- An [AWS account](https://aws.amazon.com/premiumsupport/knowledge-center/create-and-activate-aws-account/).
Sign in with an existing AWS account or create a new one.
- In this guide, you create an infrastructure in [`us-east-2` region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html).
You can use any region, but do not change it after you begin.
## Create an infrastructure and initial deployment on AWS
For deploying an application from GitLab, you must first create an infrastructure and initial
deployment on AWS.
This includes an [ECS cluster](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/clusters.html)
and related components, such as
[ECS task definitions](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html),
[ECS services](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html),
and containerized application image.
For the first step here, you create a demo application from a project template.
### Create a new project from a template
Use a GitLab project template to get started. As the name suggests, these projects provide a
bare-bones application built on some well-known frameworks.
1. In GitLab, select the plus icon (**{plus-square}**) at the top of the navigation bar, and select
**New project**.
1. Select **Create from template**, where you can choose from a Ruby on Rails, Spring, or
NodeJS Express project. For this guide, use the Ruby on Rails template.
![Select project template](img/rails-template.png)
1. Give your project a name. In this example, it's named `ecs-demo`. Make it public so that you can
take advantage of the features available in the
[GitLab Ultimate plan](https://about.gitlab.com/pricing/).
1. Select **Create project**.
Now that you created a demo project, you must containerize the application and push it to the
container registry.
### Push a containerized application image to GitLab Container Registry
[ECS](https://aws.amazon.com/ecs/) is a container orchestration service, meaning that you must
provide a containerized application image during the infrastructure build. To do so, you can use
GitLab [Auto Build](../../../topics/autodevops/stages.md#auto-build)
and [Container Registry](../../../user/packages/container_registry/index.md).
1. Go to **ecs-demo** project on GitLab.
1. Select **Setup up CI/CD**. It brings you to a `.gitlab-ci.yml`
creation form.
1. Copy and paste the following content into the empty `.gitlab-ci.yml`. This defines
a pipeline for continuous deployment to ECS.
```yaml
include:
- template: AWS/Deploy-ECS.gitlab-ci.yml
```
1. Select **Commit Changes**. It automatically triggers a new pipeline. In this pipeline, the `build`
job containerizes the application and pushes the image to [GitLab Container Registry](../../../user/packages/container_registry/index.md).
![Create project](img/initial-pipeline.png)
1. Visit **Packages & Registries > Container Registry**. Make sure the application image has been
pushed.
![Create project](img/registry.png)
Now you have a containerized application image that can be pulled from AWS. Next, you define the
spec of how this application image is used in AWS.
Note that the `production_ecs` job fails because ECS Cluster is not connected yet. You'll fix this
later.
### Create an ECS task definition
[ECS Task definitions](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)
is a specification about how the application image is started by an [ECS service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html).
1. Go to **ECS > Task Definitions** on [AWS console](https://aws.amazon.com/).
1. Select **Create new Task Definition**.
![Create project](img/ecs-task-definitions.png)
1. Choose **EC2** as the launch type. Select **Next Step**.
1. Set `ecs_demo` to **Task Definition Name**.
1. Set `512` to **Task Size > Task memory** and **Task CPU**.
1. Select **Container Definitions > Add container**. This opens a container registration form.
1. Set `web` to **Container name**.
1. Set `registry.gitlab.com/<your-namespace>/ecs-demo/master:latest` to **Image**.
Alternatively, you can copy and paste the image path from the [GitLab Container Registry page](#push-a-containerized-application-image-to-gitlab-container-registry).
![Create project](img/container-name.png)
1. Add a port mapping. Set `80` to **Host Port** and `5000` to **Container port**.
![Create project](img/container-port-mapping.png)
1. Select **Create**.
Now you have the initial task definition. Next, you create an actual infrastructure to run the
application image.
### Create an ECS cluster
An [ECS cluster](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/clusters.html)
is a virtual group of [ECS services](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html).
It's also associated with EC2 or Fargate as the computation resource.
1. Go to **ECS > Clusters** on [AWS console](https://aws.amazon.com/).
1. Select **Create Cluster**.
1. Select **EC2 Linux + Networking** as the cluster template. Select **Next Step**.
1. Set `ecs-demo` to **Cluster Name**.
1. Choose the default [VPC](https://aws.amazon.com/vpc/?vpc-blogs.sort-by=item.additionalFields.createdDate&vpc-blogs.sort-order=desc)
in **Networking**. If there are no existing VPCs, you can leave it as-is to create a new one.
1. Set all available subnets of the VPC to **Subnets**.
1. Select **Create**.
1. Make sure that the ECS cluster has been successfully created.
![Create project](img/ecs-launch-status.png)
Now you can register an ECS service to the ECS cluster in the next step.
Note the following:
- Optionally, you can set a SSH key pair in the creation form. This allows you to SSH to the EC2
instance for debugging.
- If you don't choose an existing VPC, it creates a new VPC by default. This could cause an error if
it reaches the maximum allowed number of internet gateways on your account.
- The cluster requires an EC2 instance, meaning it costs you [according to the instance-type](https://aws.amazon.com/ec2/pricing/on-demand/).
### Create an ECS Service
[ECS service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html)
is a daemon to create an application container based on the [ECS task definition](#create-an-ecs-task-definition).
1. Go to **ECS > Clusters > ecs-demo > Services** on the [AWS console](https://aws.amazon.com/)
1. Select **Deploy**. This opens a service creation form.
1. Select `EC2` in **Launch Type**.
1. Set `ecs_demo` to **Task definition**. This corresponds to [the task definition you created above](#create-an-ecs-task-definition).
1. Set `ecs_demo` to **Service name**.
1. Set `1` to **Desired tasks**.
![Create project](img/service-parameter.png)
1. Select **Deploy**.
1. Make sure that the created service is active.
![Create project](img/service-running.png)
Note that AWS's console UI changes from time to time. If you can't find a relevant component in the
instructions, select the closest one.
### View the demo application
Now, the demo application is accessible from the internet.
1. Go to **EC2 > Instances** on the [AWS console](https://aws.amazon.com/)
1. Search by `ECS Instance` to find the corresponding EC2 instance that [the ECS cluster created](#create-an-ecs-cluster).
1. Select the ID of the EC2 instance. This brings you to the instance detail page.
1. Copy **Public IPv4 address** and paste it in the browser. Now you can see the demo application
running.
![Create project](img/view-running-app.png)
In this guide, HTTPS/SSL is **not** configured. You can access to the application through HTTP only
(for example, `http://<ec2-ipv4-address>`).
## Setup Continuous Deployment from GitLab
Now that you have an application running on ECS, you can set up continuous deployment from GitLab.
### Create a new IAM user as a deployer
For GitLab to access the ECS cluster, service, and task definition that you created above, You must
create a deployer user on AWS:
1. Go to **IAM > Users** on [AWS console](https://aws.amazon.com/).
1. Select **Add user**.
1. Set `ecs_demo` to **User name**.
1. Enable **Programmatic access** checkbox. Select **Next: Permissions**.
1. Select `Attach existing policies directly` in **Set permissions**.
1. Select `AmazonECS_FullAccess` from the policy list. Select **Next: Tags** and **Next: Review**.
![Create project](img/ecs-policy.png)
1. Select **Create user**.
1. Take note of the **Access key ID** and **Secret access key** of the created user.
NOTE:
Do not share the secret access key in a public place. You must save it in a secure place.
### Setup credentials in GitLab to let pipeline jobs access to ECS
You can register the access information in [GitLab Environment Variables](../../variables/index.md#custom-cicd-variables).
These variables are injected into the pipeline jobs and can access the ECS API.
1. Go to **ecs-demo** project on GitLab.
1. Go to **Settings > CI/CD > Variables**.
1. Select **Add Variable** and set the following key-value pairs.
|Key|Value|Note|
|---|---|---|
|`AWS_ACCESS_KEY_ID`|`<Access key ID of the deployer>`| For authenticating `aws` CLI. |
|`AWS_SECRET_ACCESS_KEY`|`<Secret access key of the deployer>`| For authenticating `aws` CLI. |
|`AWS_DEFAULT_REGION`|`us-east-2`| For authenticating `aws` CLI. |
|`CI_AWS_ECS_CLUSTER`|`ecs-demo`| The ECS cluster is accessed by `production_ecs` job. |
|`CI_AWS_ECS_SERVICE`|`ecs_demo`| The ECS service of the cluster is updated by `production_ecs` job. |
|`CI_AWS_ECS_TASK_DEFINITION`|`ecs_demo`| The ECS task definition is updated by `production_ecs` job. |
### Make a change to the demo application
Change a file in the project and see if it's reflected in the demo application on ECS:
1. Go to **ecs-demo** project on GitLab.
1. Open the file at **app > views > welcome > `index.html.erb`**.
1. Select **Edit**.
1. Change the text to `You're on ECS!`.
1. Select **Commit Changes**. This automatically triggers a new pipeline. Wait until it finishes.
1. [Access the running application on the ECS cluster](#view-the-demo-application). You should see
this:
![Create project](img/view-running-app-2.png)
Congratulations! You successfully set up continuous deployment to ECS.
## Further reading
- If you're interested in more of the continuous deployments to clouds, see [cloud deployments](../index.md).
- If you want to quickly set up DevSecOps in your project, see [Auto DevOps](../../../topics/autodevops/index.md).
- If you want to quickly set up the production-grade environment, see [the 5 Minute Production App](https://gitlab.com/gitlab-org/5-minute-production-app/deploy-template/-/blob/master/README.md).

252
doc/ci/cloud_deployment/ecs/quick_start_guide.md
View File

@ -1,249 +1,11 @@
---
stage: Release
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
redirect_to: 'deploy_to_aws_ecs.md'
remove_date: '2022-09-18'
---
# Deploy to Amazon Elastic Container Service **(FREE)**
This document was moved to [another location](deploy_to_aws_ecs.md).
This step-by-step guide helps you deploy a project hosted on GitLab.com to
the Amazon [Elastic Container Service (ECS)](https://aws.amazon.com/ecs/).
In this guide, you begin by creating an ECS cluster manually using the AWS console. You create and
deploy a simple application that you create from a GitLab template.
These instructions work for both SaaS and self-managed GitLab instances.
Ensure your own [runners are configured](../../runners/index.md).
## Prerequisites
- An [AWS account](https://aws.amazon.com/premiumsupport/knowledge-center/create-and-activate-aws-account/).
Sign in with an existing AWS account or create a new one.
- In this guide, you create an infrastructure in [`us-east-2` region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html).
You can use any region, but do not change it after you begin.
## Create an infrastructure and initial deployment on AWS
For deploying an application from GitLab, you must first create an infrastructure and initial
deployment on AWS.
This includes an [ECS cluster](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/clusters.html)
and related components, such as
[ECS task definitions](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html),
[ECS services](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html),
and containerized application image.
For the first step here, you create a demo application from a project template.
### Create a new project from a template
Use a GitLab project template to get started. As the name suggests, these projects provide a
bare-bones application built on some well-known frameworks.
1. In GitLab, select the plus icon (**{plus-square}**) at the top of the navigation bar, and select
**New project**.
1. Select **Create from template**, where you can choose from a Ruby on Rails, Spring, or
NodeJS Express project. For this guide, use the Ruby on Rails template.
![Select project template](img/rails-template.png)
1. Give your project a name. In this example, it's named `ecs-demo`. Make it public so that you can
take advantage of the features available in the
[GitLab Ultimate plan](https://about.gitlab.com/pricing/).
1. Select **Create project**.
Now that you created a demo project, you must containerize the application and push it to the
container registry.
### Push a containerized application image to GitLab Container Registry
[ECS](https://aws.amazon.com/ecs/) is a container orchestration service, meaning that you must
provide a containerized application image during the infrastructure build. To do so, you can use
GitLab [Auto Build](../../../topics/autodevops/stages.md#auto-build)
and [Container Registry](../../../user/packages/container_registry/index.md).
1. Go to **ecs-demo** project on GitLab.
1. Select **Setup up CI/CD**. It brings you to a `.gitlab-ci.yml`
creation form.
1. Copy and paste the following content into the empty `.gitlab-ci.yml`. This defines
a pipeline for continuous deployment to ECS.
```yaml
include:
- template: AWS/Deploy-ECS.gitlab-ci.yml
```
1. Select **Commit Changes**. It automatically triggers a new pipeline. In this pipeline, the `build`
job containerizes the application and pushes the image to [GitLab Container Registry](../../../user/packages/container_registry/index.md).
![Create project](img/initial-pipeline.png)
1. Visit **Packages & Registries > Container Registry**. Make sure the application image has been
pushed.
![Create project](img/registry.png)
Now you have a containerized application image that can be pulled from AWS. Next, you define the
spec of how this application image is used in AWS.
Note that the `production_ecs` job fails because ECS Cluster is not connected yet. You'll fix this
later.
### Create an ECS task definition
[ECS Task definitions](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)
is a specification about how the application image is started by an [ECS service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html).
1. Go to **ECS > Task Definitions** on [AWS console](https://aws.amazon.com/).
1. Select **Create new Task Definition**.
![Create project](img/ecs-task-definitions.png)
1. Choose **EC2** as the launch type. Select **Next Step**.
1. Set `ecs_demo` to **Task Definition Name**.
1. Set `512` to **Task Size > Task memory** and **Task CPU**.
1. Select **Container Definitions > Add container**. This opens a container registration form.
1. Set `web` to **Container name**.
1. Set `registry.gitlab.com/<your-namespace>/ecs-demo/master:latest` to **Image**.
Alternatively, you can copy and paste the image path from the [GitLab Container Registry page](#push-a-containerized-application-image-to-gitlab-container-registry).
![Create project](img/container-name.png)
1. Add a port mapping. Set `80` to **Host Port** and `5000` to **Container port**.
![Create project](img/container-port-mapping.png)
1. Select **Create**.
Now you have the initial task definition. Next, you create an actual infrastructure to run the
application image.
### Create an ECS cluster
An [ECS cluster](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/clusters.html)
is a virtual group of [ECS services](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html).
It's also associated with EC2 or Fargate as the computation resource.
1. Go to **ECS > Clusters** on [AWS console](https://aws.amazon.com/).
1. Select **Create Cluster**.
1. Select **EC2 Linux + Networking** as the cluster template. Select **Next Step**.
1. Set `ecs-demo` to **Cluster Name**.
1. Choose the default [VPC](https://aws.amazon.com/vpc/?vpc-blogs.sort-by=item.additionalFields.createdDate&vpc-blogs.sort-order=desc)
in **Networking**. If there are no existing VPCs, you can leave it as-is to create a new one.
1. Set all available subnets of the VPC to **Subnets**.
1. Select **Create**.
1. Make sure that the ECS cluster has been successfully created.
![Create project](img/ecs-launch-status.png)
Now you can register an ECS service to the ECS cluster in the next step.
Note the following:
- Optionally, you can set a SSH key pair in the creation form. This allows you to SSH to the EC2
instance for debugging.
- If you don't choose an existing VPC, it creates a new VPC by default. This could cause an error if
it reaches the maximum allowed number of internet gateways on your account.
- The cluster requires an EC2 instance, meaning it costs you [according to the instance-type](https://aws.amazon.com/ec2/pricing/on-demand/).
### Create an ECS Service
[ECS service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html)
is a daemon to create an application container based on the [ECS task definition](#create-an-ecs-task-definition).
1. Go to **ECS > Clusters > ecs-demo > Services** on the [AWS console](https://aws.amazon.com/)
1. Select **Deploy**. This opens a service creation form.
1. Select `EC2` in **Launch Type**.
1. Set `ecs_demo` to **Task definition**. This corresponds to [the task definition you created above](#create-an-ecs-task-definition).
1. Set `ecs_demo` to **Service name**.
1. Set `1` to **Desired tasks**.
![Create project](img/service-parameter.png)
1. Select **Deploy**.
1. Make sure that the created service is active.
![Create project](img/service-running.png)
Note that AWS's console UI changes from time to time. If you can't find a relevant component in the
instructions, select the closest one.
### View the demo application
Now, the demo application is accessible from the internet.
1. Go to **EC2 > Instances** on the [AWS console](https://aws.amazon.com/)
1. Search by `ECS Instance` to find the corresponding EC2 instance that [the ECS cluster created](#create-an-ecs-cluster).
1. Select the ID of the EC2 instance. This brings you to the instance detail page.
1. Copy **Public IPv4 address** and paste it in the browser. Now you can see the demo application
running.
![Create project](img/view-running-app.png)
In this guide, HTTPS/SSL is **not** configured. You can access to the application through HTTP only
(for example, `http://<ec2-ipv4-address>`).
## Setup Continuous Deployment from GitLab
Now that you have an application running on ECS, you can set up continuous deployment from GitLab.
### Create a new IAM user as a deployer
For GitLab to access the ECS cluster, service, and task definition that you created above, You must
create a deployer user on AWS:
1. Go to **IAM > Users** on [AWS console](https://aws.amazon.com/).
1. Select **Add user**.
1. Set `ecs_demo` to **User name**.
1. Enable **Programmatic access** checkbox. Select **Next: Permissions**.
1. Select `Attach existing policies directly` in **Set permissions**.
1. Select `AmazonECS_FullAccess` from the policy list. Select **Next: Tags** and **Next: Review**.
![Create project](img/ecs-policy.png)
1. Select **Create user**.
1. Take note of the **Access key ID** and **Secret access key** of the created user.
NOTE:
Do not share the secret access key in a public place. You must save it in a secure place.
### Setup credentials in GitLab to let pipeline jobs access to ECS
You can register the access information in [GitLab Environment Variables](../../variables/index.md#custom-cicd-variables).
These variables are injected into the pipeline jobs and can access the ECS API.
1. Go to **ecs-demo** project on GitLab.
1. Go to **Settings > CI/CD > Variables**.
1. Select **Add Variable** and set the following key-value pairs.
|Key|Value|Note|
|---|---|---|
|`AWS_ACCESS_KEY_ID`|`<Access key ID of the deployer>`| For authenticating `aws` CLI. |
|`AWS_SECRET_ACCESS_KEY`|`<Secret access key of the deployer>`| For authenticating `aws` CLI. |
|`AWS_DEFAULT_REGION`|`us-east-2`| For authenticating `aws` CLI. |
|`CI_AWS_ECS_CLUSTER`|`ecs-demo`| The ECS cluster is accessed by `production_ecs` job. |
|`CI_AWS_ECS_SERVICE`|`ecs_demo`| The ECS service of the cluster is updated by `production_ecs` job. |
|`CI_AWS_ECS_TASK_DEFINITION`|`ecs_demo`| The ECS task definition is updated by `production_ecs` job. |
### Make a change to the demo application
Change a file in the project and see if it's reflected in the demo application on ECS:
1. Go to **ecs-demo** project on GitLab.
1. Open the file at **app > views > welcome > `index.html.erb`**.
1. Select **Edit**.
1. Change the text to `You're on ECS!`.
1. Select **Commit Changes**. This automatically triggers a new pipeline. Wait until it finishes.
1. [Access the running application on the ECS cluster](#view-the-demo-application). You should see
this:
![Create project](img/view-running-app-2.png)
Congratulations! You successfully set up continuous deployment to ECS.
## Further reading
- If you're interested in more of the continuous deployments to clouds, see [cloud deployments](../index.md).
- If you want to quickly set up DevSecOps in your project, see [Auto DevOps](../../../topics/autodevops/index.md).
- If you want to quickly set up the production-grade environment, see [the 5 Minute Production App](https://gitlab.com/gitlab-org/5-minute-production-app/deploy-template/-/blob/master/README.md).
<!-- This redirect file can be deleted after <2022-09-18>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

35
doc/ci/cloud_deployment/index.md
View File

@ -211,38 +211,3 @@ To deploy to EC2, complete the following steps.
- Your built application is pushed to your S3 bucket then and deployed to your EC2 instance, based
on the related JSON object's content. The deployment job finishes when the deployment to EC2
is done or has failed.
## Use Auto DevOps to deploy to EC2
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216008) in GitLab 13.6.
To use [Auto DevOps](../../topics/autodevops/index.md) to deploy to EC2:
1. Define [your AWS credentials as CI/CD variables](#authenticate-gitlab-with-aws).
1. In your `.gitlab-ci.yml` file, reference the `Auto-Devops.gitlab-ci.yml` template.
1. Define a job for the `build` stage named `build_artifact`. For example:
```yaml
# .gitlab-ci.yml
include:
- template: Auto-DevOps.gitlab-ci.yml
variables:
AUTO_DEVOPS_PLATFORM_TARGET: EC2
build_artifact:
stage: build
script:
- <your build script goes here>
artifacts:
paths:
- <built artifact>
```
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
For a video walkthrough of this process, view [Auto Deploy to EC2](https://www.youtube.com/watch?v=4B-qSwKnacA).
## Use Auto DevOps to deploy to EKS
- [Deploy your application to a GitLab-managed Amazon EKS cluster with Auto DevOps](https://about.gitlab.com/blog/2020/05/05/deploying-application-eks/)

36
doc/topics/autodevops/cloud_deployments/auto_devops_with_ec2.md Normal file
View File

@ -0,0 +1,36 @@
---
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
---
# Use Auto DevOps to deploy to EC2
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216008) in GitLab 13.6.
To use [Auto DevOps](../index.md) to deploy to EC2:
1. Define [your AWS credentials as CI/CD variables](../../../ci/cloud_deployment/index.md#authenticate-gitlab-with-aws).
1. In your `.gitlab-ci.yml` file, reference the `Auto-Devops.gitlab-ci.yml` template.
1. Define a job for the `build` stage named `build_artifact`. For example:
```yaml
# .gitlab-ci.yml
include:
- template: Auto-DevOps.gitlab-ci.yml
variables:
AUTO_DEVOPS_PLATFORM_TARGET: EC2
build_artifact:
stage: build
script:
- <your build script goes here>
artifacts:
paths:
- <built artifact>
```
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
For a video walkthrough of this process, view [Auto Deploy to EC2](https://www.youtube.com/watch?v=4B-qSwKnacA).

38
doc/topics/autodevops/cloud_deployments/auto_devops_with_ecs.md Normal file
View File

@ -0,0 +1,38 @@
---
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
---
# Use Auto DevOps to deploy to Amazon ECS
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208132) in GitLab 13.0.
You can choose to target AWS ECS as a deployment platform instead of using Kubernetes.
To get started on Auto DevOps to AWS ECS, you must add a specific CI/CD variable.
To do so, follow these steps:
1. In GitLab, on the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Settings > CI/CD**.
1. Expand **Auto DevOps**.
1. Specify which AWS platform to target during the Auto DevOps deployment
by adding the `AUTO_DEVOPS_PLATFORM_TARGET` variable with one of the following values:
- `FARGATE` if the service you're targeting must be of launch type FARGATE.
- `ECS` if you're not enforcing any launch type check when deploying to ECS.
When you trigger a pipeline, if you have Auto DevOps enabled and if you have correctly
[entered AWS credentials as variables](../../../ci/cloud_deployment/index.md#authenticate-gitlab-with-aws),
your application is deployed to AWS ECS.
If you have both a valid `AUTO_DEVOPS_PLATFORM_TARGET` variable and a Kubernetes cluster tied to your project,
only the deployment to Kubernetes runs.
WARNING:
Setting the `AUTO_DEVOPS_PLATFORM_TARGET` variable to `ECS` triggers jobs
defined in the [`Jobs/Deploy/ECS.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy/ECS.gitlab-ci.yml).
However, it's not recommended to [include](../../../ci/yaml/index.md#includetemplate)
it on its own. This template is designed to be used with Auto DevOps only. It may change
unexpectedly causing your pipeline to fail if included on its own. Also, the job
names within this template may also change. Do not override these jobs' names in your
own pipeline, as the override stops working when the name changes.

331
doc/topics/autodevops/cloud_deployments/auto_devops_with_gke.md Normal file
View File

@ -0,0 +1,331 @@
---
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
---
# Use Auto DevOps to deploy an application to Google Kubernetes Engine **(FREE)**
In this tutorial, we'll help you to get started with [Auto DevOps](../index.md)
through an example of how to deploy an application to Google Kubernetes Engine (GKE).
You are using the GitLab native Kubernetes integration, so you don't need
to create a Kubernetes cluster manually using the Google Cloud Platform console.
You are creating and deploying an application that you create from a GitLab template.
These instructions also work for self-managed GitLab instances.
Ensure your own [runners are configured](../../../ci/runners/index.md) and
[Google OAuth is enabled](../../../integration/google.md).
To deploy a project to Google Kubernetes Engine, follow the steps below:
1. [Configure your Google account](#configure-your-google-account)
1. [Create a new project from a template](#create-a-new-project-from-a-template)
1. [Create a Kubernetes cluster from GitLab](#create-a-kubernetes-cluster-from-gitlab)
1. [Install Ingress](#install-ingress)
1. [Configure your base domain](#configure-your-base-domain)
1. [Enable Auto DevOps](#enable-auto-devops-optional)
1. [Deploy the application](#deploy-the-application)
## Configure your Google account
Before creating and connecting your Kubernetes cluster to your GitLab project,
you need a [Google Cloud Platform account](https://console.cloud.google.com).
Sign in with an existing Google account, such as the one you use to access Gmail
or Google Drive, or create a new one.
1. Follow the steps described in the ["Before you begin" section](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin)
of the Kubernetes Engine documentation to enable the required APIs and related services.
1. Ensure you've created a [billing account](https://cloud.google.com/billing/docs/how-to/manage-billing-account)
with Google Cloud Platform.
NOTE:
Every new Google Cloud Platform (GCP) account receives [$300 in credit](https://console.cloud.google.com/freetrial),
and in partnership with Google, GitLab is able to offer an additional $200 for new
GCP accounts to get started with the GitLab integration with Google Kubernetes Engine.
[Follow this link](https://cloud.google.com/partners/partnercredit/?pcn_code=0014M00001h35gDQAQ#contact-form)
and apply for credit.
## Create a new project from a template
Use a GitLab project template to get started. As the name suggests,
those projects provide a bare-bones application built on some well-known frameworks.
1. On the top bar in GitLab, select the plus icon (**{plus-square}**), and select
**New project/repository**.
1. Go to the **Create from template** tab, where you can choose a Ruby on
Rails, Spring, or NodeJS Express project.
For this tutorial, use the Ruby on Rails template.
![Select project template](img/guide_project_template_v12_3.png)
1. Give your project a name, optionally a description, and make it public so that
you can take advantage of the features available in the
[GitLab Ultimate plan](https://about.gitlab.com/pricing/).
![Create project](img/guide_create_project_v12_3.png)
1. Select **Create project**.
Now that you've created a project, create the Kubernetes cluster
to deploy this project to.
## Create a Kubernetes cluster from GitLab
1. On your project's landing page, select the button **Add Kubernetes cluster**.
![Project landing page](img/guide_project_landing_page_v12_10.png)
1. On the **Kubernetes clusters** page, select the **Create a new cluster** option from the **Actions** dropdown menu.
1. On the **Connect a Kubernetes cluster** page, select **Google GKE**.
1. Connect with your Google account, and select **Allow** to allow access to your
Google account. (This authorization request is only displayed the first time
you connect GitLab with your Google account.)
After authorizing access, the **Connect a Kubernetes cluster** page
is displayed.
1. In the **Enter your Kubernetes cluster certificate details** section, provide
details about your cluster:
- **Kubernetes cluster name**
- **Environment scope** - Leave this field unchanged.
- **Google Cloud Platform project** - Select a project. When you
[configured your Google account](#configure-your-google-account), a project
should have already been created for you.
- **Zone** - The [region/zone](https://cloud.google.com/compute/docs/regions-zones/) to
create the cluster in.
- **Number of nodes**
- **Machine type** - For more information about
[machine types](https://cloud.google.com/compute/docs/machine-types), see Google's documentation.
- **Enable Cloud Run for Anthos** - Select this checkbox to use the
[Cloud Run](../../../user/project/clusters/add_gke_clusters.md#cloud-run-for-anthos),
Istio, and HTTP Load Balancing add-ons for this cluster.
- **GitLab-managed cluster** - Select this checkbox to
[allow GitLab to manage namespace and service accounts](../../../user/project/clusters/gitlab_managed_clusters.md) for this cluster.
1. Select **Create Kubernetes cluster**.
After a couple of minutes, the cluster is created. You can also see its
status on your [GCP dashboard](https://console.cloud.google.com/kubernetes).
## Install Ingress
After your cluster is running, you must install NGINX Ingress Controller as a
load balancer, to route traffic from the internet to your application.
Install the NGINX Ingress Controller
through the GitLab [Cluster management project template](../../../user/clusters/management_project_template.md),
or manually with Google Cloud Shell:
1. Go to your cluster's details page, and select the **Advanced Settings** tab.
1. Select the link to Google Kubernetes Engine to visit the cluster on Google Cloud Console.
1. On the GKE cluster page, select **Connect**, then select **Run in Cloud Shell**.
1. After the Cloud Shell starts, run these commands to install NGINX Ingress Controller:
```shell
kubectl create ns gitlab-managed-apps
helm repo add stable https://charts.helm.sh/stable
helm repo update
helm install ingress stable/nginx-ingress -n gitlab-managed-apps
# Check that the ingress controller is installed successfully
kubectl get service ingress-nginx-ingress-controller -n gitlab-managed-apps
```
## Configure your base domain
Follow these steps to configure the base domain where you access your apps.
1. A few minutes after you install NGINX, the load balancer obtains an IP address, and you can
get the external IP address with the following command:
```shell
kubectl get service ingress-nginx-ingress-controller -n gitlab-managed-apps -ojson | jq -r '.status.loadBalancer.ingress[].ip'
```
Replace `gitlab-managed-apps` if you have overwritten your namespace.
Copy this IP address, as you need it in the next step.
1. Go back to the cluster page on GitLab, and go to the **Details** tab.
- Add your **Base domain**. For this example, use the domain `<IP address>.nip.io`.
- Select **Save changes**.
![Cluster Base Domain](img/guide_base_domain_v12_3.png)
## Enable Auto DevOps (optional)
While Auto DevOps is enabled by default, Auto DevOps can be disabled at both
the instance level (for self-managed instances) and the group level. Complete
these steps to enable Auto DevOps if it's disabled:
1. Go to **Settings > CI/CD > Auto DevOps**, and select **Expand**.
1. Select **Default to Auto DevOps pipeline** to display more options.
1. In **Deployment strategy**, select your desired [continuous deployment strategy](../requirements.md#auto-devops-deployment-strategy)
to deploy the application to production after the pipeline successfully runs on the default branch.
1. Select **Save changes**.
![Auto DevOps settings](img/guide_enable_autodevops_v12_3.png)
After you save your changes, GitLab creates a new pipeline. To view it, go to
**{rocket}** **CI/CD > Pipelines**.
In the next section, we explain what each job does in the pipeline.
## Deploy the application
When your pipeline runs, what is it doing?
To view the jobs in the pipeline, select the pipeline's status badge. The
**{status_running}** icon displays when pipeline jobs are running, and updates
without refreshing the page to **{status_success}** (for success) or
**{status_failed}** (for failure) when the jobs complete.
The jobs are separated into stages:
![Pipeline stages](img/guide_pipeline_stages_v13_0.png)
- **Build** - The application builds a Docker image and uploads it to your project's
[Container Registry](../../../user/packages/container_registry/index.md) ([Auto Build](../stages.md#auto-build)).
- **Test** - GitLab runs various checks on the application, but all jobs except `test`
are allowed to fail in the test stage:
- The `test` job runs unit and integration tests by detecting the language and
framework ([Auto Test](../stages.md#auto-test))
- The `code_quality` job checks the code quality and is allowed to fail
([Auto Code Quality](../stages.md#auto-code-quality))
- The `container_scanning` job checks the Docker container if it has any
vulnerabilities and is allowed to fail ([Auto Container Scanning](../stages.md#auto-container-scanning))
- The `dependency_scanning` job checks if the application has any dependencies
susceptible to vulnerabilities and is allowed to fail
([Auto Dependency Scanning](../stages.md#auto-dependency-scanning))
- Jobs suffixed with `-sast` run static analysis on the current code to check for potential
security issues, and are allowed to fail ([Auto SAST](../stages.md#auto-sast))
- The `secret-detection` job checks for leaked secrets and is allowed to fail ([Auto Secret Detection](../stages.md#auto-secret-detection))
- The `license_scanning` job searches the application's dependencies to determine each of their
licenses and is allowed to fail
([Auto License Compliance](../stages.md#auto-license-compliance))
- **Review** - Pipelines on the default branch include this stage with a `dast_environment_deploy` job.
To learn more, see [Dynamic Application Security Testing (DAST)](../../../user/application_security/dast/index.md).
- **Production** - After the tests and checks finish, the application deploys in
Kubernetes ([Auto Deploy](../stages.md#auto-deploy)).
- **Performance** - Performance tests are run on the deployed application
([Auto Browser Performance Testing](../stages.md#auto-browser-performance-testing)).
- **Cleanup** - Pipelines on the default branch include this stage with a `stop_dast_environment` job.
After running a pipeline, you should view your deployed website and learn how
to monitor it.
### Monitor your project
After successfully deploying your application, you can view its website and check
on its health on the **Environments** page by navigating to
**Deployments > Environments**. This page displays details about
the deployed applications, and the right-hand column displays icons that link
you to common environment tasks:
![Environments](img/guide_environments_v12_3.png)
- **Open live environment** (**{external-link}**) - Opens the URL of the application deployed in production
- **Monitoring** (**{chart}**) - Opens the metrics page where Prometheus collects data
about the Kubernetes cluster and how the application
affects it in terms of memory usage, CPU usage, and latency
- **Deploy to** (**{play}** **{chevron-lg-down}**) - Displays a list of environments you can deploy to
- **Terminal** (**{terminal}**) - Opens a [web terminal](../../../ci/environments/index.md#web-terminals-deprecated)
session inside the container where the application is running
- **Re-deploy to environment** (**{repeat}**) - For more information, see
[Retrying and rolling back](../../../ci/environments/index.md#retry-or-roll-back-a-deployment)
- **Stop environment** (**{stop}**) - For more information, see
[Stopping an environment](../../../ci/environments/index.md#stop-an-environment)
GitLab displays the [deploy board](../../../user/project/deploy_boards.md) below the
environment's information, with squares representing pods in your
Kubernetes cluster, color-coded to show their status. Hovering over a square on
the deploy board displays the state of the deployment, and selecting the square
takes you to the pod's logs page.
NOTE:
The example shows only one pod hosting the application at the moment, but you can add
more pods by defining the [`REPLICAS` CI/CD variable](../customize.md#cicd-variables)
in **Settings > CI/CD > Variables**.
### Work with branches
Following the [GitLab flow](../../gitlab_flow.md#working-with-feature-branches),
you should next create a feature branch to add content to your application:
1. In your project's repository, go to the following file: `app/views/welcome/index.html.erb`.
This file should only contain a paragraph: `<p>You're on Rails!</p>`.
1. Open the GitLab [Web IDE](../../../user/project/web_ide/index.md) to make the change.
1. Edit the file so it contains:
```html
<p>You're on Rails! Powered by GitLab Auto DevOps.</p>
```
1. Stage the file. Add a commit message, then create a new branch and a merge request
by selecting **Commit**.
![Web IDE commit](img/guide_ide_commit_v12_3.png)
After submitting the merge request, GitLab runs your pipeline, and all the jobs
in it, as [described previously](#deploy-the-application), in addition to
a few more that run only on branches other than the default branch.
![Merge request](img/guide_merge_request_v12_3.png)
After a few minutes a test fails, which means a test was
'broken' by your change. Select the failed `test` job to see more information
about it:
```plaintext
Failure:
WelcomeControllerTest#test_should_get_index [/app/test/controllers/welcome_controller_test.rb:7]:
<You're on Rails!> expected but was
<You're on Rails! Powered by GitLab Auto DevOps.>..
Expected 0 to be >= 1.
bin/rails test test/controllers/welcome_controller_test.rb:4
```
To fix the broken test:
1. Return to your merge request.
1. In the upper right corner, select **Code**, then select **Open in Gitpod**.
1. In the left-hand directory of files, find the `test/controllers/welcome_controller_test.rb`
file, and select it to open it.
1. Change line 7 to say `You're on Rails! Powered by GitLab Auto DevOps.`
1. Select **Commit**.
1. In the left-hand column, under **Unstaged changes**, select the checkmark icon
(**{stage-all}**) to stage the changes.
1. Write a commit message, and select **Commit**.
Return to the **Overview** page of your merge request, and you should not only
see the test passing, but also the application deployed as a
[review application](../stages.md#auto-review-apps). You can visit it by selecting
the **View app** **{external-link}** button to see your changes deployed.
![Review app](img/guide_merge_request_review_app_v12_3.png)
After merging the merge request, GitLab runs the pipeline on the default branch,
and then deploys the application to production.
## Conclusion
After implementing this project, you should have a solid understanding of the basics of Auto DevOps.
You started from building and testing, to deploying and monitoring an application
all in GitLab. Despite its automatic nature, Auto DevOps can also be configured
and customized to fit your workflow. Here are some helpful resources for further reading:
1. [Auto DevOps](../index.md)
1. [Multiple Kubernetes clusters](../multiple_clusters_auto_devops.md)
1. [Incremental rollout to production](../customize.md#incremental-rollout-to-production)
1. [Disable jobs you don't need with CI/CD variables](../customize.md#cicd-variables)
1. [Use your own buildpacks to build your application](../customize.md#custom-buildpacks)
1. [Prometheus monitoring](../../../user/project/integrations/prometheus.md)

0
doc/topics/autodevops/img/guide_base_domain_v12_3.png → doc/topics/autodevops/cloud_deployments/img/guide_base_domain_v12_3.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 42 KiB

After

Width:  |  Height:  |  Size: 42 KiB

0
doc/topics/autodevops/img/guide_create_project_v12_3.png → doc/topics/autodevops/cloud_deployments/img/guide_create_project_v12_3.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 46 KiB

After

Width:  |  Height:  |  Size: 46 KiB

0
doc/topics/autodevops/img/guide_enable_autodevops_v12_3.png → doc/topics/autodevops/cloud_deployments/img/guide_enable_autodevops_v12_3.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 48 KiB

After

Width:  |  Height:  |  Size: 48 KiB

0
doc/topics/autodevops/img/guide_environments_v12_3.png → doc/topics/autodevops/cloud_deployments/img/guide_environments_v12_3.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 26 KiB

After

Width:  |  Height:  |  Size: 26 KiB

0
doc/topics/autodevops/img/guide_ide_commit_v12_3.png → doc/topics/autodevops/cloud_deployments/img/guide_ide_commit_v12_3.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 57 KiB

After

Width:  |  Height:  |  Size: 57 KiB

0
doc/topics/autodevops/img/guide_merge_request_review_app_v12_3.png → doc/topics/autodevops/cloud_deployments/img/guide_merge_request_review_app_v12_3.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 73 KiB

After

Width:  |  Height:  |  Size: 73 KiB

0
doc/topics/autodevops/img/guide_merge_request_v12_3.png → doc/topics/autodevops/cloud_deployments/img/guide_merge_request_v12_3.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 80 KiB

After

Width:  |  Height:  |  Size: 80 KiB

0
doc/topics/autodevops/img/guide_pipeline_stages_v13_0.png → doc/topics/autodevops/cloud_deployments/img/guide_pipeline_stages_v13_0.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 64 KiB

After

Width:  |  Height:  |  Size: 64 KiB

0
doc/topics/autodevops/img/guide_project_landing_page_v12_10.png → doc/topics/autodevops/cloud_deployments/img/guide_project_landing_page_v12_10.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 21 KiB

After

Width:  |  Height:  |  Size: 21 KiB

0
doc/topics/autodevops/img/guide_project_template_v12_3.png → doc/topics/autodevops/cloud_deployments/img/guide_project_template_v12_3.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 45 KiB

After

Width:  |  Height:  |  Size: 45 KiB

13
doc/topics/autodevops/index.md
View File

@ -234,16 +234,9 @@ and clear the **Default to Auto DevOps pipeline** checkbox.
### Quick start
To guide you through the process of setting up Auto DevOps to deploy to a Kubernetes cluster on
Google Kubernetes Engine (GKE), see the [quick start guide](quick_start_guide.md).
You can also follow the quick start for the general steps, but deploy to
[AWS ECS](requirements.md#auto-devops-requirements-for-amazon-ecs) instead.
If you're a self-managed user, before deploying to GKE, a GitLab administrator needs to:
1. Configure the [Google OAuth 2.0 OmniAuth Provider](../../integration/google.md).
1. Configure a cluster on GKE.
- [Use Auto DevOps to deploy to a Kubernetes cluster on Google Kubernetes Engine (GKE)](cloud_deployments/auto_devops_with_gke.md)
- [Use Auto DevOps to deploy to EC2](cloud_deployments/auto_devops_with_ec2.md)
- [Use Auto DevOps to deploy to ECS](cloud_deployments/auto_devops_with_ecs.md)
## Upgrade Auto DevOps dependencies when updating GitLab

3
doc/topics/autodevops/multiple_clusters_auto_devops.md
View File

@ -35,7 +35,8 @@ To add a different cluster for each environment:
1. Navigate to your project's **Infrastructure > Kubernetes clusters**.
1. Create the Kubernetes clusters with their respective environment scope, as
described from the table above.
1. After creating the clusters, navigate to each cluster and [install Ingress](quick_start_guide.md#install-ingress).
1. After creating the clusters, navigate to each cluster and
[install Ingress](cloud_deployments/auto_devops_with_gke.md#install-ingress).
Wait for the Ingress IP address to be assigned.
1. Make sure you've [configured your DNS](requirements.md#auto-devops-base-domain) with the
specified Auto DevOps domains.

334
doc/topics/autodevops/quick_start_guide.md
View File

@ -1,331 +1,11 @@
---
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
redirect_to: '../autodevops/cloud_deployments/auto_devops_with_gke.md'
remove_date: '2022-09-18'
---
# Tutorial: Use Auto DevOps to deploy an application to Google Kubernetes Engine **(FREE)**
This document was moved to [another location](../autodevops/cloud_deployments/auto_devops_with_gke.md).
In this tutorial, we'll help you to get started with [Auto DevOps](index.md)
through an example of how to deploy an application to Google Kubernetes Engine (GKE).
You are using the GitLab native Kubernetes integration, so you don't need
to create a Kubernetes cluster manually using the Google Cloud Platform console.
You are creating and deploying an application that you create from a GitLab template.
These instructions also work for self-managed GitLab instances.
Ensure your own [runners are configured](../../ci/runners/index.md) and
[Google OAuth is enabled](../../integration/google.md).
To deploy a project to Google Kubernetes Engine, follow the steps below:
1. [Configure your Google account](#configure-your-google-account)
1. [Create a new project from a template](#create-a-new-project-from-a-template)
1. [Create a Kubernetes cluster from GitLab](#create-a-kubernetes-cluster-from-gitlab)
1. [Install Ingress](#install-ingress)
1. [Configure your base domain](#configure-your-base-domain)
1. [Enable Auto DevOps](#enable-auto-devops-optional)
1. [Deploy the application](#deploy-the-application)
## Configure your Google account
Before creating and connecting your Kubernetes cluster to your GitLab project,
you need a [Google Cloud Platform account](https://console.cloud.google.com).
Sign in with an existing Google account, such as the one you use to access Gmail
or Google Drive, or create a new one.
1. Follow the steps described in the ["Before you begin" section](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin)
of the Kubernetes Engine documentation to enable the required APIs and related services.
1. Ensure you've created a [billing account](https://cloud.google.com/billing/docs/how-to/manage-billing-account)
with Google Cloud Platform.
NOTE:
Every new Google Cloud Platform (GCP) account receives [$300 in credit](https://console.cloud.google.com/freetrial),
and in partnership with Google, GitLab is able to offer an additional $200 for new
GCP accounts to get started with the GitLab integration with Google Kubernetes Engine.
[Follow this link](https://cloud.google.com/partners/partnercredit/?pcn_code=0014M00001h35gDQAQ#contact-form)
and apply for credit.
## Create a new project from a template
Use a GitLab project template to get started. As the name suggests,
those projects provide a bare-bones application built on some well-known frameworks.
1. On the top bar in GitLab, select the plus icon (**{plus-square}**), and select
**New project/repository**.
1. Go to the **Create from template** tab, where you can choose a Ruby on
Rails, Spring, or NodeJS Express project.
For this tutorial, use the Ruby on Rails template.
![Select project template](img/guide_project_template_v12_3.png)
1. Give your project a name, optionally a description, and make it public so that
you can take advantage of the features available in the
[GitLab Ultimate plan](https://about.gitlab.com/pricing/).
![Create project](img/guide_create_project_v12_3.png)
1. Select **Create project**.
Now that you've created a project, create the Kubernetes cluster
to deploy this project to.
## Create a Kubernetes cluster from GitLab
1. On your project's landing page, select the button **Add Kubernetes cluster**.
![Project landing page](img/guide_project_landing_page_v12_10.png)
1. On the **Kubernetes clusters** page, select the **Create a new cluster** option from the **Actions** dropdown menu.
1. On the **Connect a Kubernetes cluster** page, select **Google GKE**.
1. Connect with your Google account, and select **Allow** to allow access to your
Google account. (This authorization request is only displayed the first time
you connect GitLab with your Google account.)
After authorizing access, the **Connect a Kubernetes cluster** page
is displayed.
1. In the **Enter your Kubernetes cluster certificate details** section, provide
details about your cluster:
- **Kubernetes cluster name**
- **Environment scope** - Leave this field unchanged.
- **Google Cloud Platform project** - Select a project. When you
[configured your Google account](#configure-your-google-account), a project
should have already been created for you.
- **Zone** - The [region/zone](https://cloud.google.com/compute/docs/regions-zones/) to
create the cluster in.
- **Number of nodes**
- **Machine type** - For more information about
[machine types](https://cloud.google.com/compute/docs/machine-types), see Google's documentation.
- **Enable Cloud Run for Anthos** - Select this checkbox to use the
[Cloud Run](../../user/project/clusters/add_gke_clusters.md#cloud-run-for-anthos),
Istio, and HTTP Load Balancing add-ons for this cluster.
- **GitLab-managed cluster** - Select this checkbox to
[allow GitLab to manage namespace and service accounts](../../user/project/clusters/gitlab_managed_clusters.md) for this cluster.
1. Select **Create Kubernetes cluster**.
After a couple of minutes, the cluster is created. You can also see its
status on your [GCP dashboard](https://console.cloud.google.com/kubernetes).
## Install Ingress
After your cluster is running, you must install NGINX Ingress Controller as a
load balancer, to route traffic from the internet to your application.
Install the NGINX Ingress Controller
through the GitLab [Cluster management project template](../../user/clusters/management_project_template.md),
or manually with Google Cloud Shell:
1. Go to your cluster's details page, and select the **Advanced Settings** tab.
1. Select the link to Google Kubernetes Engine to visit the cluster on Google Cloud Console.
1. On the GKE cluster page, select **Connect**, then select **Run in Cloud Shell**.
1. After the Cloud Shell starts, run these commands to install NGINX Ingress Controller:
```shell
kubectl create ns gitlab-managed-apps
helm repo add stable https://charts.helm.sh/stable
helm repo update
helm install ingress stable/nginx-ingress -n gitlab-managed-apps
# Check that the ingress controller is installed successfully
kubectl get service ingress-nginx-ingress-controller -n gitlab-managed-apps
```
## Configure your base domain
Follow these steps to configure the base domain where you access your apps.
1. A few minutes after you install NGINX, the load balancer obtains an IP address, and you can
get the external IP address with the following command:
```shell
kubectl get service ingress-nginx-ingress-controller -n gitlab-managed-apps -ojson | jq -r '.status.loadBalancer.ingress[].ip'
```
Replace `gitlab-managed-apps` if you have overwritten your namespace.
Copy this IP address, as you need it in the next step.
1. Go back to the cluster page on GitLab, and go to the **Details** tab.
- Add your **Base domain**. For this example, use the domain `<IP address>.nip.io`.
- Select **Save changes**.
![Cluster Base Domain](img/guide_base_domain_v12_3.png)
## Enable Auto DevOps (optional)
While Auto DevOps is enabled by default, Auto DevOps can be disabled at both
the instance level (for self-managed instances) and the group level. Complete
these steps to enable Auto DevOps if it's disabled:
1. Go to **Settings > CI/CD > Auto DevOps**, and select **Expand**.
1. Select **Default to Auto DevOps pipeline** to display more options.
1. In **Deployment strategy**, select your desired [continuous deployment strategy](requirements.md#auto-devops-deployment-strategy)
to deploy the application to production after the pipeline successfully runs on the default branch.
1. Select **Save changes**.
![Auto DevOps settings](img/guide_enable_autodevops_v12_3.png)
After you save your changes, GitLab creates a new pipeline. To view it, go to
**{rocket}** **CI/CD > Pipelines**.
In the next section, we explain what each job does in the pipeline.
## Deploy the application
When your pipeline runs, what is it doing?
To view the jobs in the pipeline, select the pipeline's status badge. The
**{status_running}** icon displays when pipeline jobs are running, and updates
without refreshing the page to **{status_success}** (for success) or
**{status_failed}** (for failure) when the jobs complete.
The jobs are separated into stages:
![Pipeline stages](img/guide_pipeline_stages_v13_0.png)
- **Build** - The application builds a Docker image and uploads it to your project's
[Container Registry](../../user/packages/container_registry/index.md) ([Auto Build](stages.md#auto-build)).
- **Test** - GitLab runs various checks on the application, but all jobs except `test`
are allowed to fail in the test stage:
- The `test` job runs unit and integration tests by detecting the language and
framework ([Auto Test](stages.md#auto-test))
- The `code_quality` job checks the code quality and is allowed to fail
([Auto Code Quality](stages.md#auto-code-quality))
- The `container_scanning` job checks the Docker container if it has any
vulnerabilities and is allowed to fail ([Auto Container Scanning](stages.md#auto-container-scanning))
- The `dependency_scanning` job checks if the application has any dependencies
susceptible to vulnerabilities and is allowed to fail
([Auto Dependency Scanning](stages.md#auto-dependency-scanning))
- Jobs suffixed with `-sast` run static analysis on the current code to check for potential
security issues, and are allowed to fail ([Auto SAST](stages.md#auto-sast))
- The `secret-detection` job checks for leaked secrets and is allowed to fail ([Auto Secret Detection](stages.md#auto-secret-detection))
- The `license_scanning` job searches the application's dependencies to determine each of their
licenses and is allowed to fail
([Auto License Compliance](stages.md#auto-license-compliance))
- **Review** - Pipelines on the default branch include this stage with a `dast_environment_deploy` job.
To learn more, see [Dynamic Application Security Testing (DAST)](../../user/application_security/dast/index.md).
- **Production** - After the tests and checks finish, the application deploys in
Kubernetes ([Auto Deploy](stages.md#auto-deploy)).
- **Performance** - Performance tests are run on the deployed application
([Auto Browser Performance Testing](stages.md#auto-browser-performance-testing)).
- **Cleanup** - Pipelines on the default branch include this stage with a `stop_dast_environment` job.
After running a pipeline, you should view your deployed website and learn how
to monitor it.
### Monitor your project
After successfully deploying your application, you can view its website and check
on its health on the **Environments** page by navigating to
**Deployments > Environments**. This page displays details about
the deployed applications, and the right-hand column displays icons that link
you to common environment tasks:
![Environments](img/guide_environments_v12_3.png)
- **Open live environment** (**{external-link}**) - Opens the URL of the application deployed in production
- **Monitoring** (**{chart}**) - Opens the metrics page where Prometheus collects data
about the Kubernetes cluster and how the application
affects it in terms of memory usage, CPU usage, and latency
- **Deploy to** (**{play}** **{chevron-lg-down}**) - Displays a list of environments you can deploy to
- **Terminal** (**{terminal}**) - Opens a [web terminal](../../ci/environments/index.md#web-terminals-deprecated)
session inside the container where the application is running
- **Re-deploy to environment** (**{repeat}**) - For more information, see
[Retrying and rolling back](../../ci/environments/index.md#retry-or-roll-back-a-deployment)
- **Stop environment** (**{stop}**) - For more information, see
[Stopping an environment](../../ci/environments/index.md#stop-an-environment)
GitLab displays the [deploy board](../../user/project/deploy_boards.md) below the
environment's information, with squares representing pods in your
Kubernetes cluster, color-coded to show their status. Hovering over a square on
the deploy board displays the state of the deployment, and selecting the square
takes you to the pod's logs page.
NOTE:
The example shows only one pod hosting the application at the moment, but you can add
more pods by defining the [`REPLICAS` CI/CD variable](customize.md#cicd-variables)
in **Settings > CI/CD > Variables**.
### Work with branches
Following the [GitLab flow](../gitlab_flow.md#working-with-feature-branches),
you should next create a feature branch to add content to your application:
1. In your project's repository, go to the following file: `app/views/welcome/index.html.erb`.
This file should only contain a paragraph: `<p>You're on Rails!</p>`.
1. Open the GitLab [Web IDE](../../user/project/web_ide/index.md) to make the change.
1. Edit the file so it contains:
```html
<p>You're on Rails! Powered by GitLab Auto DevOps.</p>
```
1. Stage the file. Add a commit message, then create a new branch and a merge request
by selecting **Commit**.
![Web IDE commit](img/guide_ide_commit_v12_3.png)
After submitting the merge request, GitLab runs your pipeline, and all the jobs
in it, as [described previously](#deploy-the-application), in addition to
a few more that run only on branches other than the default branch.
![Merge request](img/guide_merge_request_v12_3.png)
After a few minutes a test fails, which means a test was
'broken' by your change. Select the failed `test` job to see more information
about it:
```plaintext
Failure:
WelcomeControllerTest#test_should_get_index [/app/test/controllers/welcome_controller_test.rb:7]:
<You're on Rails!> expected but was
<You're on Rails! Powered by GitLab Auto DevOps.>..
Expected 0 to be >= 1.
bin/rails test test/controllers/welcome_controller_test.rb:4
```
To fix the broken test:
1. Return to your merge request.
1. In the upper right corner, select **Code**, then select **Open in Gitpod**.
1. In the left-hand directory of files, find the `test/controllers/welcome_controller_test.rb`
file, and select it to open it.
1. Change line 7 to say `You're on Rails! Powered by GitLab Auto DevOps.`
1. Select **Commit**.
1. In the left-hand column, under **Unstaged changes**, select the checkmark icon
(**{stage-all}**) to stage the changes.
1. Write a commit message, and select **Commit**.
Return to the **Overview** page of your merge request, and you should not only
see the test passing, but also the application deployed as a
[review application](stages.md#auto-review-apps). You can visit it by selecting
the **View app** **{external-link}** button to see your changes deployed.
![Review app](img/guide_merge_request_review_app_v12_3.png)
After merging the merge request, GitLab runs the pipeline on the default branch,
and then deploys the application to production.
## Conclusion
After implementing this project, you should have a solid understanding of the basics of Auto DevOps.
You started from building and testing, to deploying and monitoring an application
all in GitLab. Despite its automatic nature, Auto DevOps can also be configured
and customized to fit your workflow. Here are some helpful resources for further reading:
1. [Auto DevOps](index.md)
1. [Multiple Kubernetes clusters](multiple_clusters_auto_devops.md)
1. [Incremental rollout to production](customize.md#incremental-rollout-to-production)
1. [Disable jobs you don't need with CI/CD variables](customize.md#cicd-variables)
1. [Use your own buildpacks to build your application](customize.md#custom-buildpacks)
1. [Prometheus monitoring](../../user/project/integrations/prometheus.md)
<!-- This redirect file can be deleted after <2022-09-18>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

55
doc/topics/autodevops/requirements.md
View File

@ -14,17 +14,16 @@ To prepare the deployment:
1. Define the [deployment strategy](#auto-devops-deployment-strategy).
1. Prepare the [base domain](#auto-devops-base-domain).
1. Define where you want to deploy it to:
1. Define where you want to deploy it:
1. [Kubernetes](#auto-devops-requirements-for-kubernetes).
1. [Amazon Elastic Container Service (ECS)](#auto-devops-requirements-for-amazon-ecs).
1. [Amazon EC2](#auto-devops-requirements-for-amazon-ec2).
1. [Amazon Elastic Container Service (ECS)](cloud_deployments/auto_devops_with_ecs.md).
1. [Amazon Elastic Kubernetes Service (EKS)](https://about.gitlab.com/blog/2020/05/05/deploying-application-eks/).
1. [Amazon EC2](cloud_deployments/auto_devops_with_ec2.md).
1. [Google Kubernetes Engine](cloud_deployments/auto_devops_with_gke.md).
1. [Bare metal](#auto-devops-requirements-for-bare-metal).
When done:
1. [Enable Auto DevOps](index.md#enable-or-disable-auto-devops).
1. See the [quick start](quick_start_guide.md) process.
## Auto DevOps deployment strategy
@ -173,50 +172,6 @@ are skipped.
After all requirements are met, you can [enable Auto DevOps](index.md#enable-or-disable-auto-devops).
## Auto DevOps requirements for Amazon ECS
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208132) in GitLab 13.0.
You can choose to target [AWS ECS](../../ci/cloud_deployment/index.md) as a deployment platform instead of using Kubernetes.
To get started on Auto DevOps to AWS ECS, you must add a specific CI/CD variable.
To do so, follow these steps:
1. In GitLab, on the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Settings > CI/CD**.
1. Expand **Auto DevOps**.
1. Specify which AWS platform to target during the Auto DevOps deployment
by adding the `AUTO_DEVOPS_PLATFORM_TARGET` variable with one of the following values:
- `FARGATE` if the service you're targeting must be of launch type FARGATE.
- `ECS` if you're not enforcing any launch type check when deploying to ECS.
When you trigger a pipeline, if you have Auto DevOps enabled and if you have correctly
[entered AWS credentials as variables](../../ci/cloud_deployment/index.md#authenticate-gitlab-with-aws),
your application is deployed to AWS ECS.
If you have both a valid `AUTO_DEVOPS_PLATFORM_TARGET` variable and a Kubernetes cluster tied to your project,
only the deployment to Kubernetes runs.
WARNING:
Setting the `AUTO_DEVOPS_PLATFORM_TARGET` variable to `ECS` triggers jobs
defined in the [`Jobs/Deploy/ECS.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy/ECS.gitlab-ci.yml).
However, it's not recommended to [include](../../ci/yaml/index.md#includetemplate)
it on its own. This template is designed to be used with Auto DevOps only. It may change
unexpectedly causing your pipeline to fail if included on its own. Also, the job
names within this template may also change. Do not override these jobs' names in your
own pipeline, as the override stops working when the name changes.
## Auto DevOps requirements for Amazon EC2
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216008) in GitLab 13.6.
You can target [AWS EC2](../../ci/cloud_deployment/index.md)
as a deployment platform instead of Kubernetes. To use Auto DevOps with AWS EC2, you must add a
specific CI/CD variable.
For more details, see [Custom build job for Auto DevOps](../../ci/cloud_deployment/index.md#use-auto-devops-to-deploy-to-ec2)
for deployments to AWS EC2.
## Auto DevOps requirements for bare metal
According to the [Kubernetes Ingress-NGINX docs](https://kubernetes.github.io/ingress-nginx/deploy/baremetal/):

18
doc/user/application_security/dast/index.md
View File

@ -1400,17 +1400,19 @@ and DAST site profiles are included in the [audit log](../../../administration/a
## Reports
The DAST tool outputs a report file in JSON format by default. However, this tool can also generate reports in
Markdown, HTML, and XML. For more information, see the [schema for DAST reports](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/dast-report-format.json).
The DAST tool outputs a `gl-dast-report.json` report file containing details of the scan and its results.
This file is included in the job's artifacts. JSON is the default format, but
you can output the report in Markdown, HTML, and XML formats. To specify an alternative
format, use a [CI/CD variable](#available-cicd-variables). You can also use a CI/CD variable
to configure the job to output the `gl-dast-debug-auth-report.html` file which helps when debugging
authentication issues.
### JSON
For details of the report's schema, see the [schema for DAST reports](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/dast-report-format.json). Example reports can be found in the
[DAST repository](https://gitlab.com/gitlab-org/security-products/dast/-/tree/main/test/end-to-end/expect).
WARNING:
The JSON report artifacts are not a public API of DAST and their format is expected to change in the future.
The DAST tool always emits a JSON report file called `gl-dast-report.json` and
sample reports can be found in the
[DAST repository](https://gitlab.com/gitlab-org/security-products/dast/-/tree/main/test/end-to-end/expect).
The JSON report artifacts are not a public API of DAST and their format is expected to change in the
future.
## Optimizing DAST

26
qa/qa/mobile/page/profile/menu.rb
View File

@ -1,26 +0,0 @@
# frozen_string_literal: true
module QA
module Mobile
module Page
module Profile
module Menu
extend QA::Page::PageConcern
def self.prepended(base)
super
base.class_eval do
prepend QA::Mobile::Page::Main::Menu
end
end
def within_sidebar
open_mobile_nav_sidebar
super
end
end
end
end
end
end

4
qa/qa/mobile/page/sub_menus/common.rb
View File

@ -6,10 +6,10 @@ module QA
module SubMenus
module Common
def open_mobile_nav_sidebar
if has_element?(:project_sidebar, visible: false)
unless has_css?('.sidebar-expanded-mobile')
Support::Retrier.retry_until do
click_element(:toggle_mobile_nav_button)
has_element?(:project_sidebar, visible: true)
has_css?('.sidebar-expanded-mobile')
end
end
end

2
qa/qa/page/profile/menu.rb
View File

@ -6,7 +6,7 @@ module QA
class Menu < Page::Base
# We need to check remote_mobile_device_name instead of mobile_layout? here
# since tablets have the regular top navigation bar but still close the left nav
prepend QA::Mobile::Page::Profile::Menu if QA::Runtime::Env.remote_mobile_device_name
prepend QA::Mobile::Page::SubMenus::Common if QA::Runtime::Env.remote_mobile_device_name
view 'app/views/layouts/nav/sidebar/_profile.html.haml' do
element :access_token_link, 'link_to profile_personal_access_tokens_path' # rubocop:disable QA/ElementWithPattern

66
qa/qa/specs/features/browser_ui/5_package/package_registry/nuget/nuget_project_level_spec.rb
View File

@ -1,10 +1,7 @@
# frozen_string_literal: true
module QA
RSpec.describe 'Package', :orchestrated, :packages, :object_storage, :reliable, quarantine: {
type: :flaky,
issue: "https://gitlab.com/gitlab-org/gitlab/-/issues/361704"
} do
RSpec.describe 'Package', :orchestrated, :packages, :object_storage do
describe 'NuGet project level endpoint' do
include Support::Helpers::MaskToken
@ -16,13 +13,7 @@ module QA
end
end
let(:personal_access_token) do
unless Page::Main::Menu.perform(&:signed_in?)
Flow::Login.sign_in
end
Resource::PersonalAccessToken.fabricate!
end
let(:personal_access_token) { Resource::PersonalAccessToken.fabricate! }
let(:project_deploy_token) do
Resource::ProjectDeployToken.fabricate_via_api! do |deploy_token|
@ -113,19 +104,34 @@ module QA
{
file_path: '.gitlab-ci.yml',
content: <<~YAML
deploy-and-install:
image: mcr.microsoft.com/dotnet/sdk:5.0
script:
- dotnet restore -p:Configuration=Release
- dotnet build -c Release
- dotnet pack -c Release -p:PackageID=#{package.name}
- dotnet nuget add source "$CI_SERVER_URL/api/v4/projects/$CI_PROJECT_ID/packages/nuget/index.json" --name gitlab --username #{auth_token_username} --password #{auth_token_password} --store-password-in-clear-text
- dotnet nuget push "bin/Release/*.nupkg" --source gitlab
- "dotnet add dotnetcore.csproj package #{package.name} --version 1.0.0"
rules:
- if: '$CI_COMMIT_BRANCH == "#{project.default_branch}"'
tags:
- "runner-for-#{project.name}"
stages:
- deploy
- install
deploy:
stage: deploy
image: mcr.microsoft.com/dotnet/sdk:5.0
script:
- dotnet restore -p:Configuration=Release
- dotnet build -c Release
- dotnet pack -c Release -p:PackageID=#{package.name}
- dotnet nuget add source "$CI_SERVER_URL/api/v4/projects/$CI_PROJECT_ID/packages/nuget/index.json" --name gitlab --username #{auth_token_username} --password #{auth_token_password} --store-password-in-clear-text
- dotnet nuget push "bin/Release/*.nupkg" --source gitlab
rules:
- if: '$CI_COMMIT_BRANCH == "#{project.default_branch}"'
tags:
- "runner-for-#{project.name}"
install:
stage: install
image: mcr.microsoft.com/dotnet/sdk:5.0
script:
- dotnet nuget add source "$CI_SERVER_URL/api/v4/projects/$CI_PROJECT_ID/packages/nuget/index.json" --name gitlab --username #{auth_token_username} --password #{auth_token_password} --store-password-in-clear-text
- "dotnet add dotnetcore.csproj package #{package.name} --version 1.0.0"
rules:
- if: '$CI_COMMIT_BRANCH == "#{project.default_branch}"'
tags:
- "runner-for-#{project.name}"
YAML
},
{
@ -150,7 +156,17 @@ module QA
Flow::Pipeline.visit_latest_pipeline
Page::Project::Pipeline::Show.perform do |pipeline|
pipeline.click_job('deploy-and-install')
pipeline.click_job('deploy')
end
Page::Project::Job::Show.perform do |job|
expect(job).to be_successful(timeout: 800)
end
page.go_back
Page::Project::Pipeline::Show.perform do |pipeline|
pipeline.click_job('install')
end
Page::Project::Job::Show.perform do |job|

2
qa/qa/specs/spec_helper.rb
View File

@ -38,6 +38,8 @@ RSpec.configure do |config|
QA::Runtime::Logger.info("Starting test: #{Rainbow(example.full_description).bright}")
QA::Runtime::Example.current = example
visit(QA::Runtime::Scenario.gitlab_address) if QA::Runtime::Env.remote_mobile_device_name
# Reset fabrication counters tracked in resource base
Thread.current[:api_fabrication] = 0
Thread.current[:browser_ui_fabrication] = 0