Commit 9abe0fa6 authored by Marcel Amirault's avatar Marcel Amirault Committed by Evan Read

Add codeblock language tags to ci docs

Add language tags to codeblocks that were missing
them, in /ci files and pages files.
parent 0130f678
......@@ -83,7 +83,7 @@ GitLab Pages expect to run on their own virtual host. In your DNS server/provide
you need to add a [wildcard DNS A record][wiki-wildcard-dns] pointing to the
host that GitLab runs. For example, an entry would look like this:
```
```plaintext
*.example.io. 1800 IN A 192.0.2.1
*.example.io. 1800 IN AAAA 2001::1
```
......
......@@ -64,7 +64,7 @@ GitLab Pages expect to run on their own virtual host. In your DNS server/provide
you need to add a [wildcard DNS A record][wiki-wildcard-dns] pointing to the
host that GitLab runs. For example, an entry would look like this:
```
```plaintext
*.example.io. 1800 IN A 192.0.2.1
```
......@@ -131,7 +131,7 @@ The Pages daemon doesn't listen to the outside world.
order to enable the pages daemon. In `gitlab_pages_options` the
`-pages-domain` must match the `host` setting that you set above.
```
```ini
gitlab_pages_enabled=true
gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090"
```
......@@ -170,7 +170,7 @@ outside world.
1. In `gitlab.yml`, set the port to `443` and https to `true`:
```shell
```yaml
## GitLab Pages
pages:
enabled: true
......@@ -188,9 +188,9 @@ outside world.
The `-root-cert` and `-root-key` settings are the wildcard TLS certificates
of the `example.io` domain:
```
```ini
gitlab_pages_enabled=true
gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key
gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key"
```
1. Copy the `gitlab-pages-ssl` NGINX configuration file:
......@@ -256,7 +256,7 @@ world. Custom domains are supported, but no TLS.
`-pages-domain` and `-listen-http` must match the `host` and `external_http`
settings that you set above respectively:
```
```ini
gitlab_pages_enabled=true
gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 192.0.2.2:80"
```
......@@ -325,9 +325,9 @@ world. Custom domains and TLS are supported.
The `-root-cert` and `-root-key` settings are the wildcard TLS certificates
of the `example.io` domain:
```
```ini
gitlab_pages_enabled=true
gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 192.0.2.2:80 -listen-https 192.0.2.2:443 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key
gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 192.0.2.2:80 -listen-https 192.0.2.2:443 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key"
```
1. Copy the `gitlab-pages-ssl` NGINX configuration file:
......
......@@ -85,9 +85,9 @@ To manually enable GitLab CI/CD for your repository:
The web hook URL should be set to the GitLab API to
[trigger pull mirroring](../../api/projects.md#start-the-pull-mirroring-process-for-a-project-starter),
using the GitLab personal access token we just created.
using the GitLab personal access token we just created:
```
```plaintext
https://gitlab.com/api/v4/projects/<NAMESPACE>%2F<PROJECT>/mirror/pull?private_token=<PERSONAL_ACCESS_TOKEN>
```
......
......@@ -23,7 +23,7 @@ requiring a single keyword to enable the feature for any job.
Consider a monorepo as follows:
```
```plaintext
./service_a
./service_b
./service_c
......
......@@ -39,7 +39,7 @@ project:
1. Create a new project by selecting **Import project from ➔ Repo by URL**
1. Add the following URL:
```
```plaintext
https://gitlab.com/gitlab-examples/maven/simple-maven-dep.git
```
......@@ -164,7 +164,7 @@ The deployment occurs only if we're pushing or merging to `master` branch, so th
Done! Now you have all the changes in the GitLab repo, and a pipeline has already been started for this commit. In the **Pipelines** tab you can see what's happening.
If the deployment has been successful, the deploy job log will output:
```
```plaintext
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
......@@ -188,7 +188,7 @@ We'll use again a Maven app that can be cloned from our example project:
1. Create a new project by selecting **Import project from ➔ Repo by URL**
1. Add the following URL:
```
```plaintext
https://gitlab.com/gitlab-examples/maven/simple-maven-app.git
```
......
......@@ -18,7 +18,7 @@ To use Dpl you need at least Ruby 1.9.3 with ability to install gems.
Dpl can be installed on any machine with:
```
```shell
gem install dpl
```
......@@ -27,7 +27,7 @@ having to test it on a CI server.
If you don't have Ruby installed you can do it on Debian-compatible Linux with:
```
```shell
apt-get update
apt-get install ruby-dev
```
......
......@@ -163,7 +163,7 @@ sudo nano /etc/nginx/sites-available/default
The configuration should be like this.
```
```nginx
server {
root /var/www/app/current/public;
server_name example.com;
......
......@@ -179,7 +179,7 @@ user following [the upstream installation guide][phpenv-installation].
Using phpenv also allows to easily configure the PHP environment with:
```
```shell
phpenv config-add my_config.ini
```
......
......@@ -115,7 +115,7 @@ mix ecto.create
We expect to see this output at the end of the command:
```shell
```plaintext
Generated hello_gitlab_ci app
The database for HelloGitlabCi.Repo has been created
```
......@@ -136,7 +136,7 @@ mix phoenix.server
This will be the output to this command:
```shell
```plaintext
[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
......@@ -229,7 +229,7 @@ mix test
Our expected result is this:
```shell
```plaintext
....
Finished in 0.7 seconds
......@@ -265,20 +265,20 @@ project.
As we are focusing on testing (not deploying), you can use the [elixir:latest](https://hub.docker.com/_/elixir) docker image, which already has the
dependencies for running Phoenix tests installed, such as Elixir and Erlang:
```yml
```yaml
image: elixir:latest
```
- We'll only use `postgres`, so we can delete the `mysql` and `redis` lines from the `services` section:
```yml
```yaml
services:
- postgres:latest
```
- Now, we'll create a new section called `variables`, before the `before_script` section:
```yml
```yaml
variables:
POSTGRES_DB: hello_gitlab_ci_test
POSTGRES_HOST: postgres
......@@ -293,7 +293,7 @@ project.
- In the `before_script` section, we'll add some commands to prepare everything for the test:
```yml
```yaml
before_script:
- mix local.rebar --force
- mix local.hex --force
......@@ -310,7 +310,7 @@ project.
Let's take a look at the updated file after the changes:
```yml
```yaml
image: elixir:latest
services:
......@@ -353,7 +353,7 @@ actual running build job.
Click on build's ID to watch the entire process. If everything went as expected, we can wait for the
**Build succeeded** at the end of the process! :)
```
```shell
$ mix test
....
......
......@@ -114,11 +114,11 @@ SSH key.
You can generate the SSH key from the machine that GitLab Runner is installed
on, and use that key for all projects that are run on this machine.
1. First, you need to login to the server that runs your jobs.
1. First, log in to the server that runs your jobs.
1. Then from the terminal login as the `gitlab-runner` user:
1. Then, from the terminal, log in as the `gitlab-runner` user:
```
```shell
sudo su - gitlab-runner
```
......@@ -132,7 +132,7 @@ on, and use that key for all projects that are run on this machine.
If you are accessing a private GitLab repository you need to add it as a
[deploy key](../../ssh/README.md#deploy-keys).
Once done, try to login to the remote server in order to accept the fingerprint:
Once done, try to log in to the remote server in order to accept the fingerprint:
```shell
ssh example.com
......
......@@ -110,7 +110,7 @@ The action is irreversible.
To trigger a job you need to send a `POST` request to GitLab's API endpoint:
```
```plaintext
POST /projects/:id/trigger/pipeline
```
......@@ -185,7 +185,7 @@ Now, whenever a new tag is pushed on project A, the job will run and the
To trigger a job from a webhook of another project you need to add the following
webhook URL for Push and Tag events (change the project ID, ref and token):
```
```plaintext
https://gitlab.example.com/api/v4/projects/9/ref/master/trigger/pipeline?token=TOKEN
```
......@@ -195,7 +195,7 @@ You can pass any number of arbitrary variables in the trigger API call and they
will be available in GitLab CI so that they can be used in your `.gitlab-ci.yml`
file. The parameter is of the form:
```
```plaintext
variables[key]=value
```
......
......@@ -51,7 +51,7 @@ Otherwise it's pretty likely that you will encounter problems described in the [
Make sure that the backup script on both servers can connect to the database.
```
```shell
# On your CI server:
# Omnibus
sudo chown gitlab-ci:gitlab-ci /var/opt/gitlab/gitlab-ci/builds
......@@ -64,7 +64,7 @@ sudo -u gitlab_ci -H bundle exec rake backup:create RAILS_ENV=production
Also check on your GitLab server.
```
```shell
# On your GitLab server:
# Omnibus
sudo gitlab-backup create SKIP=repositories,uploads
......@@ -89,7 +89,7 @@ MySQL and your GitLab server uses PostgreSQL you need to pass a special option
during the 'Moving data' part. **If your CI server uses PostgreSQL and your
GitLab server uses MySQL you cannot migrate your CI data to GitLab 8.0.**
```
```shell
# On your CI server:
# Omnibus
sudo gitlab-ci-rake env:info
......@@ -99,7 +99,7 @@ cd /home/gitlab_ci/gitlab-ci
sudo -u gitlab_ci -H bundle exec rake env:info RAILS_ENV=production
```
```
```shell
# On your GitLab server:
# Omnibus
sudo gitlab-rake gitlab:env:info
......@@ -149,7 +149,7 @@ Now upgrade GitLab CI to version 8.0. If you are using Omnibus packages,
Disable GitLab CI after upgrading to 8.0.
```
```shell
# On your CI server:
# Omnibus
sudo gitlab-ctl stop ci-unicorn
......@@ -171,7 +171,7 @@ GitLab server. On Omnibus GitLab servers you will have to add a line to
`/etc/gitlab/gitlab.rb`. On GitLab servers installed from source you will have
to replace the contents of `/home/git/gitlab/config/secrets.yml`.
```
```shell
# On your CI server:
# Omnibus
sudo gitlab-ci-rake backup:show_secrets
......@@ -188,7 +188,7 @@ PostgreSQL, add `MYSQL_TO_POSTGRESQL=1` to the end of the rake command. When
the command finishes it will print the path to your data export archive; you
will need this file later.
```
```shell
# On your CI server:
# Omnibus
sudo chown gitlab-ci:gitlab-ci /var/opt/gitlab/gitlab-ci/builds
......@@ -209,7 +209,7 @@ this, below we use SSH agent forwarding and 'scp', which will be easy and fast
for most setups. You can also copy the data archive first from the CI server to
your laptop and then from your laptop to the GitLab server.
```
```shell
# Start from your laptop
ssh -A ci_admin@ci_server.example
# Now on the CI server
......@@ -221,7 +221,7 @@ scp /path/to/12345_gitlab_ci_backup.tar gitlab_admin@gitlab_server.example:~
Make the CI data archive discoverable for GitLab. We assume below that you
store backups in the default path, adjust the command if necessary.
```
```shell
# On your GitLab server:
# Omnibus
sudo mv /path/to/12345_gitlab_ci_backup.tar /var/opt/gitlab/backups/
......@@ -235,7 +235,7 @@ sudo mv /path/to/12345_gitlab_ci_backup.tar /home/git/gitlab/tmp/backups/
This step will delete any existing CI data on your GitLab server. There should
be no CI data yet because you turned CI on the GitLab server off earlier.
```
```shell
# On your GitLab server:
# Omnibus
sudo chown git:git /var/opt/gitlab/gitlab-ci/builds
......@@ -248,7 +248,7 @@ sudo -u git -H bundle exec rake ci:migrate RAILS_ENV=production
### 6. Restart GitLab
```
```shell
# On your GitLab server:
# Omnibus
sudo gitlab-ctl hup unicorn
......@@ -347,7 +347,7 @@ restoration](../raketasks/backup_restore.md) guide.
If you see errors like this:
```
```plaintext
Missing `secret_key_base` or `db_key_base` for 'production' environment. The secrets will be generated and stored in `config/secrets.yml`
rake aborted!
Errno::EACCES: Permission denied @ rb_sysopen - config/secrets.yml
......@@ -360,13 +360,13 @@ The fix for this is to update to Omnibus 7.14 first and then update it to 8.0.
To fix that issue you have to change builds/ folder permission before doing final backup:
```
```shell
sudo chown -R gitlab-ci:gitlab-ci /var/opt/gitlab/gitlab-ci/builds
```
Then before executing `ci:migrate` you need to fix builds folder permission:
```
```shell
sudo chown git:git /var/opt/gitlab/gitlab-ci/builds
```
......@@ -450,7 +450,7 @@ EOF
Source installations:
```
```shell
cd /home/gitlab_ci/gitlab-ci
sudo -u gitlab_ci -H bundle exec rails dbconsole production <<EOF
... COPY SQL STATEMENTS FROM ABOVE ...
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment