diff options
Diffstat (limited to 'doc/ci/examples')
12 files changed, 42 insertions, 93 deletions
diff --git a/doc/ci/examples/README.md b/doc/ci/examples/README.md index 37ccef10567..34e3b276d3e 100644 --- a/doc/ci/examples/README.md +++ b/doc/ci/examples/README.md @@ -64,6 +64,7 @@ choose one of these templates: - [Clojure (`Clojure.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Clojure.gitlab-ci.yml) - [Composer `Composer.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Composer.gitlab-ci.yml) - [Crystal (`Crystal.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Crystal.gitlab-ci.yml) +- [Dart (`Dart.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Dart.gitlab-ci.yml) - [Django (`Django.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Django.gitlab-ci.yml) - [Docker (`Docker.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Docker.gitlab-ci.yml) - [dotNET (`dotNET.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/dotNET.gitlab-ci.yml) diff --git a/doc/ci/examples/artifactory_and_gitlab/index.md b/doc/ci/examples/artifactory_and_gitlab/index.md index c1b3ddec1b9..2abb2cc1b0d 100644 --- a/doc/ci/examples/artifactory_and_gitlab/index.md +++ b/doc/ci/examples/artifactory_and_gitlab/index.md @@ -3,12 +3,7 @@ stage: Verify group: Continuous Integration info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers disqus_identifier: 'https://docs.gitlab.com/ee/articles/artifactory_and_gitlab/index.html' -author: Fabio Busatto -author_gitlab: bikebilly -level: intermediate -article_type: tutorial type: tutorial -date: 2017-08-15 --- # How to deploy Maven projects to Artifactory with GitLab CI/CD @@ -82,7 +77,7 @@ is to configure the authentication data. It is a simple task, but Maven requires it to stay in a file called `settings.xml` that has to be in the `.m2` subdirectory in the user's homedir. -Since you want to use GitLab Runner to automatically deploy the application, you +Since you want to use a runner to automatically deploy the application, you should create the file in the project's home directory and set a command line parameter in `.gitlab-ci.yml` to use the custom location instead of the default one: @@ -110,7 +105,7 @@ parameter in `.gitlab-ci.yml` to use the custom location instead of the default Now it's time we set up [GitLab CI/CD](https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/) to automatically build, test and deploy the dependency! GitLab CI/CD uses a file in the root of the repository, named `.gitlab-ci.yml`, to read the definitions for jobs -that will be executed by the configured GitLab Runners. You can read more about this file in the [GitLab Documentation](../../yaml/README.md). +that will be executed by the configured runners. You can read more about this file in the [GitLab Documentation](../../yaml/README.md). First of all, remember to set up variables for your deployment. Navigate to your project's **Settings > CI/CD > Environment variables** page and add the following ones (replace them with your current values, of course): @@ -151,7 +146,7 @@ deploy: - master ``` -GitLab Runner will use the latest [Maven Docker image](https://hub.docker.com/_/maven/), which already contains all the tools and the dependencies you need to manage the project, +The runner will use the latest [Maven Docker image](https://hub.docker.com/_/maven/), which already contains all the tools and the dependencies you need to manage the project, in order to run the jobs. Environment variables are set to instruct Maven to use the `homedir` of the repository instead of the user's home when searching for configuration and dependencies. diff --git a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md index 9a87786ec70..73896547675 100644 --- a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md +++ b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md @@ -9,6 +9,12 @@ type: tutorial This tutorial demonstrates how to authenticate, configure, and read secrets with HashiCorp's Vault from GitLab CI/CD. +NOTE: **Note:** +[GitLab Premium](https://about.gitlab.com/pricing/) supports read access to a +Hashicorp Vault, and enables you to +[use Vault secrets in a CI job](../../secrets/index.md#use-vault-secrets-in-a-ci-job). +To learn more, read [Using external secrets in CI](../../secrets/index.md). + ## Requirements This tutorial assumes you are familiar with GitLab CI/CD and Vault. @@ -41,7 +47,7 @@ The JWT's payload looks like this: "project_path": "mygroup/myproject", "user_id": "42", "user_login": "myuser", - "user_email": "myuser@example.com" + "user_email": "myuser@example.com", "pipeline_id": "1212", "job_id": "1212", "ref": "auto-deploy-2020-04-01", # Git ref for this job diff --git a/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md b/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md index e0d4f3f2402..b113b10f2e3 100644 --- a/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md +++ b/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md @@ -2,14 +2,7 @@ stage: Release group: Progressive Delivery info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers -author: Dylan Griffith -author_gitlab: DylanGriffith -level: intermediate -article_type: tutorial type: tutorial -date: 2018-06-07 -last_updated: 2019-04-08 -description: "Continuous Deployment of a Spring Boot application to Cloud Foundry with GitLab CI/CD" --- # Deploy a Spring Boot application to Cloud Foundry with GitLab CI/CD diff --git a/doc/ci/examples/deployment/README.md b/doc/ci/examples/deployment/README.md index 3192b365c83..f29770b8f57 100644 --- a/doc/ci/examples/deployment/README.md +++ b/doc/ci/examples/deployment/README.md @@ -117,7 +117,7 @@ We also use two secure variables: Secure Variables can added by going to your project's **Settings ➔ CI / CD ➔ Variables**. The variables that are defined -in the project settings are sent along with the build script to the Runner. +in the project settings are sent along with the build script to the runner. The secure variables are stored out of the repository. Never store secrets in your project's `.gitlab-ci.yml`. It is also important that the secret's value is hidden in the job log. diff --git a/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md b/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md index 35a35d97a4b..836141af91e 100644 --- a/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md +++ b/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md @@ -2,13 +2,7 @@ stage: Verify group: Continuous Integration info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers -author: Ryan Hall -author_gitlab: blitzgren -level: intermediate -article_type: tutorial type: tutorial -date: 2018-03-07 -last_updated: 2019-03-11 --- # DevOps and Game Dev with GitLab CI/CD @@ -435,7 +429,7 @@ fully understand [IAM Best Practices in AWS](https://docs.aws.amazon.com/IAM/lat ### Deploy your game with GitLab CI/CD To deploy our build artifacts, we need to install the [AWS CLI](https://aws.amazon.com/cli/) on -the Shared Runner. The Shared Runner also needs to be able to authenticate with your AWS +the shared runner. The shared runner also needs to be able to authenticate with your AWS account to deploy the artifacts. By convention, AWS CLI will look for `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`. GitLab's CI gives us a way to pass the variables we set up in the prior section using the `variables` portion of the `deploy` job. At the end, diff --git a/doc/ci/examples/end_to_end_testing_webdriverio/index.md b/doc/ci/examples/end_to_end_testing_webdriverio/index.md index 05b3cc257e3..1f6c81a68aa 100644 --- a/doc/ci/examples/end_to_end_testing_webdriverio/index.md +++ b/doc/ci/examples/end_to_end_testing_webdriverio/index.md @@ -2,13 +2,7 @@ stage: Verify group: Testing info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers -author: Vincent Tunru -author_gitlab: Vinnl -level: advanced -article_type: user guide type: tutorial -date: 2019-02-18 -description: 'Confidence checking your entire app every time a new feature is added can quickly become repetitive. Learn how to automate it with GitLab CI/CD.' --- # End-to-end testing with GitLab CI/CD and WebdriverIO @@ -228,6 +222,7 @@ deploy_terraform: stage: deploy script: # Your Review App deployment scripts - for a working example please check https://gitlab.com/Flockademic/Flockademic/blob/5a45f1c2412e93810fab50e2dab8949e2d0633c7/.gitlab-ci.yml#L315 + - echo e2e:firefox: stage: confidence-check services: diff --git a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md index c27566d38cf..8927c5c3480 100644 --- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md +++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md @@ -2,14 +2,7 @@ stage: Verify group: Continuous Integration info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers -disqus_identifier: 'https://docs.gitlab.com/ee/articles/laravel_with_gitlab_and_envoy/index.html' -author: Mehran Rasulian -author_gitlab: mehranrasulian -level: intermediate -article_type: tutorial type: tutorial -date: 2017-08-31 -last_updated: 2019-03-06 --- # Test and deploy Laravel applications with GitLab CI/CD and Envoy @@ -36,7 +29,7 @@ We assume [you have installed a new Laravel project](https://laravel.com/docs/ma ### Unit Test -Every new installation of Laravel (currently 5.4) comes with two type of tests, 'Feature' and 'Unit', placed in the tests directory. +Every new installation of Laravel (currently 8.0) comes with two type of tests, 'Feature' and 'Unit', placed in the tests directory. Here's a unit test from `test/Unit/ExampleTest.php`: ```php @@ -412,7 +405,7 @@ Let's create a [Dockerfile](https://gitlab.com/mehranrasulian/laravel-sample/blo ```shell # Set the base image for subsequent instructions -FROM php:7.1 +FROM php:7.4 # Update packages RUN apt-get update @@ -434,7 +427,7 @@ RUN curl --silent --show-error https://getcomposer.org/installer | php -- --inst RUN composer global require "laravel/envoy=~1.0" ``` -We added the [official PHP 7.1 Docker image](https://hub.docker.com/_/php), which consist of a minimum installation of Debian Jessie with PHP pre-installed, and works perfectly for our use case. +We added the [official PHP 7.4 Docker image](https://hub.docker.com/_/php), which consist of a minimum installation of Debian buster with PHP pre-installed, and works perfectly for our use case. We used `docker-php-ext-install` (provided by the official PHP Docker image) to install the PHP extensions we need. @@ -537,8 +530,8 @@ That's a lot to take in, isn't it? Let's run through it step by step. #### Image and Services -[GitLab Runners](../../runners/README.md) run the script defined by `.gitlab-ci.yml`. -The `image` keyword tells the Runners which image to use. +[Runners](../../runners/README.md) run the script defined by `.gitlab-ci.yml`. +The `image` keyword tells the runners which image to use. The `services` keyword defines additional images [that are linked to the main image](../../docker/using_docker_images.md#what-is-a-service). Here we use the container image we created before as our main image and also use MySQL 5.7 as a service. @@ -566,15 +559,11 @@ Also set the variables `DB_HOST` to `mysql` and `DB_USERNAME` to `root`, which a We define `DB_HOST` as `mysql` instead of `127.0.0.1`, as we use MySQL Docker image as a service which [is linked to the main Docker image](../../docker/using_docker_images.md#how-services-are-linked-to-the-job). ```yaml -... - variables: MYSQL_DATABASE: homestead MYSQL_ROOT_PASSWORD: secret DB_HOST: mysql DB_USERNAME: root - -... ``` #### Unit Test as the first job @@ -584,8 +573,6 @@ We defined the required shell scripts as an array of the [script](../../yaml/REA These scripts are some Artisan commands to prepare the Laravel, and, at the end of the script, we'll run the tests by `PHPUnit`. ```yaml -... - unit_test: script: # Install app dependencies @@ -598,8 +585,6 @@ unit_test: - php artisan migrate # Run tests - vendor/bin/phpunit - -... ``` #### Deploy to production @@ -615,8 +600,6 @@ The `only` keyword tells GitLab CI/CD that the job should be executed only when Lastly, `when: manual` is used to turn the job from running automatically to a manual action. ```yaml -... - deploy_production: script: # Add the private SSH key to the build environment @@ -648,7 +631,7 @@ To do that, commit and push `.gitlab-ci.yml` to the `master` branch. It will tri Here we see our **Test** and **Deploy** stages. The **Test** stage has the `unit_test` build running. -click on it to see the Runner's output. +click on it to see the runner's output.  diff --git a/doc/ci/examples/php.md b/doc/ci/examples/php.md index cc62e9316f2..ab6ff1dc177 100644 --- a/doc/ci/examples/php.md +++ b/doc/ci/examples/php.md @@ -26,7 +26,7 @@ As with every job, you need to create a valid `.gitlab-ci.yml` describing the build environment. Let's first specify the PHP image that will be used for the job process -(you can read more about what an image means in the Runner's lingo reading +(you can read more about what an image means in the runner's lingo reading about [Using Docker images](../docker/using_docker_images.md#what-is-an-image)). Start by adding the image to your `.gitlab-ci.yml`: @@ -73,24 +73,16 @@ Now that we created the script that contains all prerequisites for our build environment, let's add it in `.gitlab-ci.yml`: ```yaml -... - before_script: - bash ci/docker_install.sh > /dev/null - -... ``` Last step, run the actual tests using `phpunit`: ```yaml -... - test:app: script: - phpunit --configuration phpunit_myapp.xml - -... ``` Finally, commit your files and push them to GitLab to see your build succeeding @@ -103,7 +95,7 @@ The final `.gitlab-ci.yml` should look similar to this: image: php:5.6 before_script: -# Install dependencies + # Install dependencies - bash ci/docker_install.sh > /dev/null test:app: @@ -118,7 +110,7 @@ with a different Docker image version and the runner will do the rest: ```yaml before_script: -# Install dependencies + # Install dependencies - bash ci/docker_install.sh > /dev/null # We test PHP5.6 @@ -231,8 +223,6 @@ In order to execute Composer before running your tests, simply add the following in your `.gitlab-ci.yml`: ```yaml -... - # Composer stores all downloaded packages in the vendor/ directory. # Do not use the following if the vendor/ directory is committed to # your git repository. @@ -241,15 +231,13 @@ cache: - vendor/ before_script: -# Install composer dependencies + # Install composer dependencies - wget https://composer.github.io/installer.sig -O - -q | tr -d '\n' > installer.sig - php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" - php -r "if (hash_file('SHA384', 'composer-setup.php') === file_get_contents('installer.sig')) { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;" - php composer-setup.php - php -r "unlink('composer-setup.php'); unlink('installer.sig');" - php composer.phar install - -... ``` ## Access private packages or dependencies diff --git a/doc/ci/examples/test-and-deploy-python-application-to-heroku.md b/doc/ci/examples/test-and-deploy-python-application-to-heroku.md index d01e9663795..6c4d99bd2dc 100644 --- a/doc/ci/examples/test-and-deploy-python-application-to-heroku.md +++ b/doc/ci/examples/test-and-deploy-python-application-to-heroku.md @@ -71,7 +71,7 @@ Find your Heroku API key in [Manage Account](https://dashboard.heroku.com/accoun For each of your environments, you'll need to create a new Heroku application. You can do this through the [Dashboard](https://dashboard.heroku.com/). -## Create Runner +## Create a runner First install [Docker Engine](https://docs.docker.com/installation/). diff --git a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md index bf589c5991d..066c0cf214f 100644 --- a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md +++ b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md @@ -19,27 +19,27 @@ This is what the `.gitlab-ci.yml` file looks like for this project: test: stage: test script: - - apt-get update -qy - - apt-get install -y nodejs - - bundle install --path /cache - - bundle exec rake db:create RAILS_ENV=test - - bundle exec rake test + - apt-get update -qy + - apt-get install -y nodejs + - bundle install --path /cache + - bundle exec rake db:create RAILS_ENV=test + - bundle exec rake test staging: stage: deploy script: - - gem install dpl - - dpl --provider=heroku --app=gitlab-ci-ruby-test-staging --api-key=$HEROKU_STAGING_API_KEY + - gem install dpl + - dpl --provider=heroku --app=gitlab-ci-ruby-test-staging --api-key=$HEROKU_STAGING_API_KEY only: - - master + - master production: stage: deploy script: - - gem install dpl - - dpl --provider=heroku --app=gitlab-ci-ruby-test-prod --api-key=$HEROKU_PRODUCTION_API_KEY + - gem install dpl + - dpl --provider=heroku --app=gitlab-ci-ruby-test-prod --api-key=$HEROKU_PRODUCTION_API_KEY only: - - tags + - tags ``` This project has three jobs: @@ -62,7 +62,7 @@ Find your Heroku API key in [Manage Account](https://dashboard.heroku.com/accoun For each of your environments, you'll need to create a new Heroku application. You can do this through the [Heroku Dashboard](https://dashboard.heroku.com/). -## Create Runner +## Create a runner First install [Docker Engine](https://docs.docker.com/installation/). @@ -92,6 +92,6 @@ gitlab-runner register \ --docker-image ruby:2.6 ``` -With the command above, you create a Runner that uses the [`ruby:2.6`](https://hub.docker.com/_/ruby) image and uses a [PostgreSQL](https://hub.docker.com/_/postgres) database. +With the command above, you create a runner that uses the [`ruby:2.6`](https://hub.docker.com/_/ruby) image and uses a [PostgreSQL](https://hub.docker.com/_/postgres) database. To access the PostgreSQL database, connect to `host: postgres` as user `postgres` with no password. diff --git a/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md b/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md index f2620461c09..ab6a4d3f507 100644 --- a/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md +++ b/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md @@ -2,13 +2,7 @@ stage: Verify group: Continuous Integration info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers -author: Alexandre S Hostert -author_gitlab: Hostert -level: beginner -article_type: tutorial type: tutorial -date: 2018-02-20 -last_updated: 2019-03-06 --- # Testing a Phoenix application with GitLab CI/CD @@ -182,10 +176,10 @@ environment it can run. Since we will work with a single environment, we'll edit configuration file (`test.exs`). But, why do we need to adjust our configuration? Well, GitLab CI/CD builds and tests our code in one -isolated virtual machine, called [Runner](../../runners/README.md), using Docker technology. In this Runner, +isolated virtual machine, called a [runner](../../runners/README.md), using Docker technology. In this runner, GitLab CI/CD has access to everything our Phoenix application need to run, exactly as we have in our `localhost`, but we have to tell GitLab CI/CD where to create and find this database using system -variables. This way, GitLab CI/CD will create our test database inside the Runner, just like we do +variables. This way, GitLab CI/CD will create our test database inside the runner, just like we do when running our Phoenix in our `localhost`. - Open `hello_gitlab_ci/config/test.exs` on your favorite code editor @@ -262,7 +256,7 @@ project. - The first line tells GitLab what Docker image will be used. - Remember when we learn about Runners, the isolated virtual machine where GitLab CI/CD build and test + Remember when we learned about runners, the isolated virtual machine where GitLab CI/CD builds and tests our application? This virtual machine must have all dependencies to run our application. This is where a Docker image is needed. The correct image will provide the entire system for us. @@ -401,5 +395,5 @@ using GitLab CI/CD. The benefits to our teams will be huge! - [GitLab CI/CD introductory guide](https://about.gitlab.com/blog/2015/12/14/getting-started-with-gitlab-and-gitlab-ci/) - [GitLab CI/CD full Documentation](../../README.md) -- [GitLab Runners documentation](../../runners/README.md) +- [GitLab Runner documentation](../../runners/README.md) - [Using Docker images documentation](../../docker/using_docker_images.md) |