diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-01-30 18:09:15 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-01-30 18:09:15 +0300 |
commit | 536aa3a1f4b96abc4ca34489bf2cbe503afcded7 (patch) | |
tree | 88d08f7dfa29a32d6526773c4fe0fefd9f2bc7d1 /doc/ci | |
parent | 50ae4065530c4eafbeb7c5ff2c462c48c02947ca (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/ci')
19 files changed, 82 insertions, 81 deletions
diff --git a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md index dd474b09a9c..e013078fa2e 100644 --- a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md +++ b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md @@ -65,7 +65,7 @@ To use GitLab CI/CD with a Bitbucket Cloud repository: Create a file `build_status` and insert the script below and run `chmod +x build_status` in your terminal to make the script executable. - ```bash + ```shell #!/usr/bin/env bash # Push GitLab CI/CD build status to Bitbucket Cloud diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index b7d708b152e..2750e61ff96 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -16,7 +16,7 @@ One of the new trends in Continuous Integration/Deployment is to: It's also useful when your application already has the `Dockerfile` that can be used to create and test an image: -```bash +```shell docker build -t my-image dockerfiles/ docker run my-image /script/to/run/tests docker tag my-image my-registry:5000/my-image @@ -48,7 +48,7 @@ GitLab Runner then executes job scripts as the `gitlab-runner` user. 1. During GitLab Runner installation select `shell` as method of executing job scripts or use command: - ```bash + ```shell sudo gitlab-runner register -n \ --url https://gitlab.com/ \ --registration-token REGISTRATION_TOKEN \ @@ -63,13 +63,13 @@ GitLab Runner then executes job scripts as the `gitlab-runner` user. 1. Add `gitlab-runner` user to `docker` group: - ```bash + ```shell sudo usermod -aG docker gitlab-runner ``` 1. Verify that `gitlab-runner` has access to Docker: - ```bash + ```shell sudo -u gitlab-runner -H docker info ``` @@ -160,7 +160,7 @@ support this. 1. Register GitLab Runner from the command line to use `docker` and `privileged` mode: - ```bash + ```shell sudo gitlab-runner register -n \ --url https://gitlab.com/ \ --registration-token REGISTRATION_TOKEN \ @@ -320,7 +320,7 @@ In order to do that, follow the steps: 1. Register GitLab Runner from the command line to use `docker` and share `/var/run/docker.sock`: - ```bash + ```shell sudo gitlab-runner register -n \ --url https://gitlab.com/ \ --registration-token REGISTRATION_TOKEN \ @@ -384,7 +384,7 @@ aware of the following implications: work as expected since volume mounting is done in the context of the host machine, not the build container. For example: - ```sh + ```shell docker run --rm -t -i -v $(pwd)/src:/home/app/src test-image:latest run_app_tests ``` @@ -458,13 +458,13 @@ which can be avoided if a different driver is used, for example `overlay2`. 1. Make sure a recent kernel is used, preferably `>= 4.2`. 1. Check whether the `overlay` module is loaded: - ```sh + ```shell sudo lsmod | grep overlay ``` If you see no result, then it isn't loaded. To load it use: - ```sh + ```shell sudo modprobe overlay ``` @@ -542,7 +542,7 @@ For all projects, mostly suitable for public ones: your Docker images and has read/write access to the Registry. This is ephemeral, so it's only valid for one job. You can use the following example as-is: - ```sh + ```shell docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY ``` @@ -557,7 +557,7 @@ For private and internal projects: Replace the `<username>` and `<access_token>` in the following example: - ```sh + ```shell docker login -u <username> -p <access_token> $CI_REGISTRY ``` @@ -567,7 +567,7 @@ For private and internal projects: Once created, you can use the special environment variables, and GitLab CI/CD will fill them in for you. You can use the following example as-is: - ```sh + ```shell docker login -u $CI_DEPLOY_USER -p $CI_DEPLOY_PASSWORD $CI_REGISTRY ``` @@ -602,7 +602,7 @@ assuming you have it configured with [TLS enabled](#tls-enabled): If you forget to set the service alias, the `docker:19.03.1` image won't find the `dind` service, and an error like the following is thrown: -```sh +```shell $ docker info error during connect: Get http://docker:2376/v1.39/info: dial tcp: lookup docker on 192.168.0.1:53: no such host ``` diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md index 8c6069bd939..630beec453c 100644 --- a/doc/ci/docker/using_docker_images.md +++ b/doc/ci/docker/using_docker_images.md @@ -28,7 +28,7 @@ to use the `docker` executor. A one-line example can be seen below: -```bash +```shell sudo gitlab-runner register \ --url "https://gitlab.example.com/" \ --registration-token "PROJECT_REGISTRATION_TOKEN" \ @@ -559,7 +559,7 @@ There are two ways to determine the value of `DOCKER_AUTH_CONFIG`: - **First way -** Do a `docker login` on your local machine: - ```bash + ```shell docker login registry.example.com:5000 --username my_username --password my_password ``` @@ -568,7 +568,7 @@ There are two ways to determine the value of `DOCKER_AUTH_CONFIG`: If you don't need access to the registry from your computer, you can do a `docker logout`: - ```bash + ```shell docker logout registry.example.com:5000 ``` @@ -579,7 +579,7 @@ There are two ways to determine the value of `DOCKER_AUTH_CONFIG`: `${username}:${password}` and create the Docker configuration JSON manually. Open a terminal and execute the following command: - ```bash + ```shell echo -n "my_username:my_password" | base64 # Example output to copy @@ -790,7 +790,7 @@ able to run Docker with your regular user account. First start with creating a file named `build_script`: -```bash +```shell cat <<EOF > build_script git clone https://gitlab.com/gitlab-org/gitlab-runner.git /builds/gitlab-org/gitlab-runner cd /builds/gitlab-org/gitlab-runner @@ -805,7 +805,7 @@ is specific to your project. Then create some service containers: -```sh +```shell docker run -d --name service-mysql mysql:latest docker run -d --name service-postgres postgres:latest ``` @@ -817,7 +817,7 @@ respectively. They will both run in the background (`-d`). Finally, create a build container by executing the `build_script` file we created earlier: -```sh +```shell docker run --name build -i --link=service-mysql:mysql --link=service-postgres:postgres ruby:2.6 /bin/bash < build_script ``` @@ -829,7 +829,7 @@ piped using STDIN to the bash interpreter which in turn executes the When you finish testing and no longer need the containers, you can remove them with: -```sh +```shell docker rm -f -v build service-mysql service-postgres ``` diff --git a/doc/ci/docker/using_kaniko.md b/doc/ci/docker/using_kaniko.md index 45afd9c6223..dce5cd5b40d 100644 --- a/doc/ci/docker/using_kaniko.md +++ b/doc/ci/docker/using_kaniko.md @@ -72,7 +72,7 @@ build: When trying to push to a Docker registry that uses a certificate that is signed by a custom CA, you might get the following error: -```sh +```shell $ /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --no-push INFO[0000] Downloading base image registry.gitlab.example.com/group/docker-image error building image: getting stage builder for stage 0: Get https://registry.gitlab.example.com/v2/: x509: certificate signed by unknown authority diff --git a/doc/ci/enable_or_disable_ci.md b/doc/ci/enable_or_disable_ci.md index 7c7640e23c3..732b4676c56 100644 --- a/doc/ci/enable_or_disable_ci.md +++ b/doc/ci/enable_or_disable_ci.md @@ -75,7 +75,7 @@ default_projects_features: Save the file and restart GitLab: -```sh +```shell sudo service gitlab restart ``` @@ -87,7 +87,7 @@ gitlab_rails['gitlab_default_projects_features_builds'] = false Save the file and reconfigure GitLab: -```sh +```shell sudo gitlab-ctl reconfigure ``` 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 788d57b81f8..946deb6a5ff 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 @@ -54,7 +54,7 @@ CI/CD from every new push to master. The `master` branch for this game's [reposi contains a completed version with all configurations. If you would like to follow along with this article, you can clone and work from the `devops-article` branch: -```sh +```shell git clone git@gitlab.com:blitzgren/gitlab-game-demo.git git checkout devops-article ``` @@ -363,7 +363,7 @@ our repository. If all goes well you'll end up with a green check mark on each j You can confirm that the tests passed by clicking on the `test` job to enter the full build logs. Scroll to the bottom and observe, in all its passing glory: -```sh +```shell $ gulp run-test [18:37:24] Using gulpfile /builds/blitzgren/gitlab-game-demo/gulpfile.js [18:37:24] Starting 'run-test'... 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 5acdd273548..b8f191570bc 100644 --- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md +++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md @@ -57,7 +57,7 @@ This test is as simple as asserting that the given value is true. Laravel uses `PHPUnit` for tests by default. If we run `vendor/bin/phpunit` we should see the green output: -```bash +```shell vendor/bin/phpunit OK (1 test, 1 assertions) ``` @@ -70,7 +70,7 @@ Since we have our app up and running locally, it's time to push the codebase to Let's create [a new project](../../../gitlab-basics/create-project.md) in GitLab named `laravel-sample`. After that, follow the command line instructions displayed on the project's homepage to initiate the repository on our machine and push the first commit. -```bash +```shell cd laravel-sample git init git remote add origin git@gitlab.example.com:<USERNAME>/laravel-sample.git @@ -89,7 +89,7 @@ We have installed LEMP stack which stands for Linux, NGINX, MySQL and PHP on our Let's now create a new user that will be used to deploy our website and give it the needed permissions using [Linux ACL](https://serversforhackers.com/c/linux-acls): -```bash +```shell # Create user deployer sudo adduser deployer # Give the read-write-execute permissions to deployer user for directory /var/www @@ -98,7 +98,7 @@ sudo setfacl -R -m u:deployer:rwx /var/www If you don't have ACL installed on your Ubuntu server, use this command to install it: -```bash +```shell sudo apt install acl ``` @@ -108,7 +108,7 @@ Let's suppose we want to deploy our app to the production server from a private After that, we need to copy the private key, which will be used to connect to our server as the deployer user with SSH, to be able to automate our deployment process: -```bash +```shell # As the deployer user on server # # Copy the content of public key to authorized_keys @@ -128,7 +128,7 @@ We'll use this variable in the `.gitlab-ci.yml` later, to easily connect to our We also need to add the public key to **Project** > **Settings** > **Repository** as a [Deploy Key](../../../ssh/README.md#deploy-keys), which gives us the ability to access our repository from the server through [SSH protocol](../../../gitlab-basics/command-line-commands.md#start-working-on-your-project). -```bash +```shell # As the deployer user on the server # # Copy the public key @@ -141,7 +141,7 @@ To the field **Title**, add any name you want, and paste the public key into the Now, let's clone our repository on the server just to make sure the `deployer` user has access to the repository. -```bash +```shell # As the deployer user on server # git clone git@gitlab.example.com:<USERNAME>/laravel-sample.git @@ -157,7 +157,7 @@ Now, let's make sure our web server configuration points to the `current/public` Open the default NGINX server block configuration file by typing: -```bash +```shell sudo nano /etc/nginx/sites-available/default ``` @@ -199,7 +199,7 @@ Then within our `@task` directive we define the bash commands that should be run On the local machine use the `run` command to run Envoy tasks. -```bash +```shell envoy run list ``` @@ -382,7 +382,7 @@ Now it's time to commit [Envoy.blade.php](https://gitlab.com/mehranrasulian/lara To keep things simple, we commit directly to `master`, without using [feature-branches](../../../topics/gitlab_flow.md#github-flow-as-a-simpler-alternative) since collaboration is beyond the scope of this tutorial. In a real world project, teams may use [Issue Tracker](../../../user/project/issues/index.md) and [Merge Requests](../../../user/project/merge_requests/index.md) to move their code across branches: -```bash +```shell git add Envoy.blade.php git commit -m 'Add Envoy' git push origin master @@ -407,7 +407,7 @@ With Docker images our builds run incredibly faster! Let's create a [Dockerfile](https://gitlab.com/mehranrasulian/laravel-sample/blob/master/Dockerfile) in the root directory of our app with the following content: -```bash +```shell # Set the base image for subsequent instructions FROM php:7.1 @@ -449,13 +449,13 @@ You may need to [enable Container Registry](../../../user/packages/container_reg To start using Container Registry on our machine, we first need to login to the GitLab registry using our GitLab username and password: -```bash +```shell docker login registry.gitlab.com ``` Then we can build and push our image to GitLab: -```bash +```shell docker build -t registry.gitlab.com/<USERNAME>/laravel-sample . docker push registry.gitlab.com/<USERNAME>/laravel-sample @@ -475,7 +475,7 @@ We'll use this image further down in the `.gitlab-ci.yml` configuration file to Let's commit the `Dockerfile` file. -```bash +```shell git add Dockerfile git commit -m 'Add Dockerfile' git push origin master diff --git a/doc/ci/examples/php.md b/doc/ci/examples/php.md index 1dd3049d53d..db039b746e3 100644 --- a/doc/ci/examples/php.md +++ b/doc/ci/examples/php.md @@ -40,7 +40,7 @@ done. Let's create a `ci/docker_install.sh` file in the root directory of our repository with the following content: -```bash +```shell #!/bin/bash # We need to install dependencies only for Docker @@ -153,7 +153,7 @@ dependencies are installed. For example, in a VM running Debian 8 we first update the cache, then we install `phpunit` and `php5-mysql`: -```bash +```shell sudo apt-get update -y sudo apt-get install -y phpunit php5-mysql ``` @@ -198,7 +198,7 @@ some extensions that are not currently present on the build machine. To install additional extensions simply execute: -```bash +```shell pecl install <extension> ``` @@ -269,7 +269,7 @@ documentation. With GitLab Runner 1.0 you can also test any changes locally. From your terminal execute: -```bash +```shell # Check using docker executor gitlab-runner exec docker test:app 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 03381dc16ff..6d05c37390a 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 @@ -75,7 +75,7 @@ First install [Docker Engine](https://docs.docker.com/installation/). To build this project you also need to have [GitLab Runner](https://docs.gitlab.com/runner/index.html). You can use public runners available on `gitlab.com` or you can register your own: -```sh +```shell gitlab-runner register \ --non-interactive \ --url "https://gitlab.com/" \ 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 66246a0fda2..3de8f3c675c 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 @@ -66,7 +66,7 @@ First install [Docker Engine](https://docs.docker.com/installation/). To build this project you also need to have [GitLab Runner](https://docs.gitlab.com/runner/). You can use public runners available on `gitlab.com` or register your own: -```sh +```shell gitlab-runner register \ --non-interactive \ --url "https://gitlab.com/" \ 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 f91e89d3c4c..557ebad72ba 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 @@ -79,7 +79,7 @@ When we call `mix` command, we'll pass two arguments: - And the parameter `phoenix.new` requires, which is the name of the new project. In this case, we're calling it `hello_gitlab_ci`, but you're free to set your own name: -```bash +```shell mix phoenix.new hello_gitlab_ci ``` @@ -108,14 +108,14 @@ changes. Run the commands below to create our empty database: -```bash +```shell cd hello_gitlab_ci mix ecto.create ``` We expect to see this output at the end of the command: -```bash +```shell Generated hello_gitlab_ci app The database for HelloGitlabCi.Repo has been created ``` @@ -130,13 +130,13 @@ permissions and a password of `postgres`. If it's not your case, check Now, it's time to see if everything we did until now went well. We'll call `mix` again, this time with `phoenix.server` parameter, which will start Phoenix's HTTP Server. -```bash +```shell mix phoenix.server ``` This will be the output to this command: -```bash +```shell [info] Running HelloGitlabCi.Endpoint with Cowboy using http://localhost:4000 23 May 11:44:35 - info: compiling 23 May 11:44:37 - info: compiled 6 files into 2 files, copied 3 in 9.8 sec @@ -223,13 +223,13 @@ Let's run a new task with `mix` to run those tests for us. This time, the parame In your terminal, navigate to the directory `hello_gitlab_ci` and run: -```bash +```shell mix test ``` Our expected result is this: -```bash +```shell .... Finished in 0.7 seconds diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md index fca6916bee4..744713b0678 100644 --- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md +++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md @@ -30,6 +30,7 @@ Pipelines invalidated through failures are immediately canceled and requeued. Merge trains have the following requirements and limitations: +- GitLab 12.0 and later requires [Redis](https://redis.io/) 3.2 or higher to run Merge Trains. - This feature requires that [pipelines for merged results](../index.md#pipelines-for-merged-results-premium) are **configured properly**. diff --git a/doc/ci/quick_start/README.md b/doc/ci/quick_start/README.md index 43cc7eeab8c..90efae30925 100644 --- a/doc/ci/quick_start/README.md +++ b/doc/ci/quick_start/README.md @@ -128,7 +128,7 @@ For more information and a complete `.gitlab-ci.yml` syntax, please read Once you've created `.gitlab-ci.yml`, you should add it to your Git repository and push it to GitLab. -```bash +```shell git add .gitlab-ci.yml git commit -m "Add .gitlab-ci.yml" git push origin master diff --git a/doc/ci/services/mysql.md b/doc/ci/services/mysql.md index ce69a7df885..e21b62e93cf 100644 --- a/doc/ci/services/mysql.md +++ b/doc/ci/services/mysql.md @@ -56,7 +56,7 @@ GitLab Runner with the Shell executor. First install the MySQL server: -```bash +```shell sudo apt-get install -y mysql-server mysql-client libmysqlclient-dev ``` @@ -68,7 +68,7 @@ the root user.* The next step is to create a user, so login to MySQL as root: -```bash +```shell mysql -u root -p ``` @@ -77,38 +77,38 @@ application. Change `$password` in the command below to a real strong password. *Note: Do not type `mysql>`, this is part of the MySQL prompt.* -```bash +```shell mysql> CREATE USER 'runner'@'localhost' IDENTIFIED BY '$password'; ``` Create the database: -```bash +```shell mysql> CREATE DATABASE IF NOT EXISTS `<your_mysql_database>` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`; ``` Grant the necessary permissions on the database: -```bash +```shell mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, CREATE TEMPORARY TABLES, DROP, INDEX, ALTER, LOCK TABLES ON `<your_mysql_database>`.* TO 'runner'@'localhost'; ``` If all went well you can now quit the database session: -```bash +```shell mysql> \q ``` Now, try to connect to the newly created database to check that everything is in place: -```bash +```shell mysql -u runner -p -D <your_mysql_database> ``` As a final step, configure your application to use the database, for example: -```bash +```shell Host: localhost User: runner Password: $password diff --git a/doc/ci/services/postgres.md b/doc/ci/services/postgres.md index 142f4f262e5..a137f10949f 100644 --- a/doc/ci/services/postgres.md +++ b/doc/ci/services/postgres.md @@ -57,13 +57,13 @@ GitLab Runner with the Shell executor. First install the PostgreSQL server: -```bash +```shell sudo apt-get install -y postgresql postgresql-client libpq-dev ``` The next step is to create a user, so login to PostgreSQL: -```bash +```shell sudo -u postgres psql -d template1 ``` @@ -72,7 +72,7 @@ application. Change `$password` in the command below to a real strong password. *__Note:__ Do not type `template1=#`, this is part of the PostgreSQL prompt.* -```bash +```shell template1=# CREATE USER runner WITH PASSWORD '$password' CREATEDB; ``` @@ -83,20 +83,20 @@ testing framework you have tools that drop and create databases.* Create the database and grant all privileges on it for the user `runner`: -```bash +```shell template1=# CREATE DATABASE nice_marmot OWNER runner; ``` If all went well you can now quit the database session: -```bash +```shell template1=# \q ``` Now, try to connect to the newly created database with the user `runner` to check that everything is in place. -```bash +```shell psql -U runner -h localhost -d nice_marmot -W ``` diff --git a/doc/ci/services/redis.md b/doc/ci/services/redis.md index ccb92fa94d7..b04b36f7a04 100644 --- a/doc/ci/services/redis.md +++ b/doc/ci/services/redis.md @@ -40,13 +40,13 @@ Runner with the Shell executor. In your build machine install the Redis server: -```bash +```shell sudo apt-get install redis-server ``` Verify that you can connect to the server with the `gitlab-runner` user: -```bash +```shell # Try connecting the Redis server sudo -u gitlab-runner -H redis-cli diff --git a/doc/ci/ssh_keys/README.md b/doc/ci/ssh_keys/README.md index bee1501aed8..62a8bb23e08 100644 --- a/doc/ci/ssh_keys/README.md +++ b/doc/ci/ssh_keys/README.md @@ -134,7 +134,7 @@ on, and use that key for all projects that are run on this machine. Once done, try to login to the remote server in order to accept the fingerprint: -```bash +```shell ssh example.com ``` @@ -150,7 +150,7 @@ connection would fail if the public keys would not match). To find out the host keys of your server, run the `ssh-keyscan` command from a trusted network (ideally, from the private server itself): -```sh +```shell ## Use the domain name ssh-keyscan example.com diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md index 1a58e3eb7a2..08b2171f23b 100644 --- a/doc/ci/triggers/README.md +++ b/doc/ci/triggers/README.md @@ -137,7 +137,7 @@ below. By using cURL you can trigger a pipeline rerun with minimal effort, for example: -```bash +```shell curl --request POST \ --form token=TOKEN \ --form ref=master \ @@ -148,7 +148,7 @@ In this case, the project with ID `9` will get rebuilt on `master` branch. Alternatively, you can pass the `token` and `ref` arguments in the query string: -```bash +```shell curl --request POST \ "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline?token=TOKEN&ref=master" ``` @@ -241,7 +241,7 @@ upload_package: You can then trigger a rebuild while you pass the `UPLOAD_TO_S3` variable and the script of the `upload_package` job will run: -```bash +```shell curl --request POST \ --form token=TOKEN \ --form ref=master \ @@ -259,7 +259,7 @@ Whether you craft a script or just run cURL directly, you can trigger jobs in conjunction with cron. The example below triggers a job on the `master` branch of project with ID `9` every night at `00:30`: -```bash +```shell 30 0 * * * curl --request POST --form token=TOKEN --form ref=master https://gitlab.example.com/api/v4/projects/9/trigger/pipeline ``` diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md index ff602de6754..1fdf8009fcd 100644 --- a/doc/ci/variables/README.md +++ b/doc/ci/variables/README.md @@ -74,7 +74,7 @@ file path as a command line argument or an environment variable. In the past, th common pattern was to read the value of a CI variable, save it in a file, and then use the newly created file in your script: -```bash +```shell # Read certificate stored in $KUBE_CA_PEM variable and save it in a new file echo "$KUBE_CA_PEM" > "$(pwd)/kube.ca.pem" # Pass the newly created file to kubectl @@ -90,7 +90,7 @@ it directly. For example, let's say we have the following variables: We can then call them from `.gitlab-ci.yml` like this: -```bash +```shell kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$KUBE_CA_PEM" ``` @@ -259,7 +259,7 @@ job_name: Example values: -```bash +```shell export CI_JOB_ID="50" export CI_COMMIT_SHA="1ecfd275763eff1d6b4844ea3168962458c9f27a" export CI_COMMIT_SHORT_SHA="1ecfd275" @@ -623,7 +623,7 @@ job_name: Example truncated output with `CI_DEBUG_TRACE` set to `true`: -```bash +```shell ... export CI_SERVER_TLS_CA_FILE="/builds/gitlab-examples/ci-debug-trace.tmp/CI_SERVER_TLS_CA_FILE" |