From 03e5873ae52f3c8c0efb7baa7d1a358a7c3e7974 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Tue, 19 Apr 2016 19:04:58 +0300 Subject: Fix broken links [ci skip] --- doc/ci/deployment/README.md | 98 ------------------------------------ doc/ci/examples/deployment/README.md | 98 ++++++++++++++++++++++++++++++++++++ doc/ci/triggers/README.md | 2 +- doc/markdown/markdown.md | 3 +- 4 files changed, 101 insertions(+), 100 deletions(-) delete mode 100644 doc/ci/deployment/README.md create mode 100644 doc/ci/examples/deployment/README.md diff --git a/doc/ci/deployment/README.md b/doc/ci/deployment/README.md deleted file mode 100644 index 7d91ce6710f..00000000000 --- a/doc/ci/deployment/README.md +++ /dev/null @@ -1,98 +0,0 @@ -## Using Dpl as deployment tool -Dpl (dee-pee-ell) is a deploy tool made for continuous deployment that's developed and used by Travis CI, but can also be used with GitLab CI. - -**We recommend to use Dpl, if you're deploying to any of these of these services: https://github.com/travis-ci/dpl#supported-providers**. - -### Requirements -To use Dpl you need at least Ruby 1.8.7 with ability to install gems. - -### Basic usage -The Dpl can be installed on any machine with: -``` -gem install dpl -``` - -This allows you to test all commands from your shell, rather than having to test it on a CI server. - -If you don't have Ruby installed you can do it on Debian-compatible Linux with: -``` -apt-get update -apt-get install ruby-dev -``` - -The Dpl provides support for vast number of services, including: Heroku, Cloud Foundry, AWS/S3, and more. -To use it simply define provider and any additional parameters required by the provider. - -For example if you want to use it to deploy your application to heroku, you need to specify `heroku` as provider, specify `api-key` and `app`. -There's more and all possible parameters can be found here: https://github.com/travis-ci/dpl#heroku - -``` -staging: - type: deploy - - gem install dpl - - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY -``` - -In the above example we use Dpl to deploy `my-app-staging` to Heroku server with api-key stored in `HEROKU_STAGING_API_KEY` secure variable. - -To use different provider take a look at long list of [Supported Providers](https://github.com/travis-ci/dpl#supported-providers). - -### Using Dpl with Docker -When you use GitLab Runner you most likely configured it to use your server's shell commands. -This means that all commands are run in context of local user (ie. gitlab_runner or gitlab_ci_multi_runner). -It also means that most probably in your Docker container you don't have the Ruby runtime installed. -You will have to install it: -``` -staging: - type: deploy - - apt-get update -yq - - apt-get install -y ruby-dev - - gem install dpl - - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY - only: - - master -``` - -The first line `apt-get update -yq` updates the list of available packages, where second `apt-get install -y ruby-dev` install `Ruby` runtime on system. -The above example is valid for all Debian-compatible systems. - -### Usage in staging and production -It's pretty common in developer workflow to have staging (development) and production environment. -If we consider above example: we would like to deploy `master` branch to `staging` and `all tags` to `production` environment. -The final `.gitlab-ci.yml` for that setup would look like this: - -``` -staging: - type: deploy - - gem install dpl - - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY - only: - - master - -production: - type: deploy - - gem install dpl - - dpl --provider=heroku --app=my-app-production --api-key=$HEROKU_PRODUCTION_API_KEY - only: - - tags -``` - -We created two deploy jobs that are executed on different events: -1. `staging` is executed for all commits that were pushed to `master` branch, -2. `production` is executed for all pushed tags. - -We also use two secure variables: -1. `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app, -2. `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app. - -### Storing API keys -In GitLab CI 7.12 a new feature was introduced: Secure Variables. -Secure Variables can added by going to `Project > Variables > Add Variable`. -**This feature requires `gitlab-runner` with version equal or greater than 0.4.0.** -The variables that are defined 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 projects' .gitlab-ci.yml. -It is also important that secret's value is hidden in the build log. - -You access added variable by prefixing it's name with `$` (on non-Windows runners) or `%` (for Windows Batch runners): -1. `$SECRET_VARIABLE` - use it for non-Windows runners -2. `%SECRET_VARIABLE%` - use it for Windows Batch runners diff --git a/doc/ci/examples/deployment/README.md b/doc/ci/examples/deployment/README.md new file mode 100644 index 00000000000..7d91ce6710f --- /dev/null +++ b/doc/ci/examples/deployment/README.md @@ -0,0 +1,98 @@ +## Using Dpl as deployment tool +Dpl (dee-pee-ell) is a deploy tool made for continuous deployment that's developed and used by Travis CI, but can also be used with GitLab CI. + +**We recommend to use Dpl, if you're deploying to any of these of these services: https://github.com/travis-ci/dpl#supported-providers**. + +### Requirements +To use Dpl you need at least Ruby 1.8.7 with ability to install gems. + +### Basic usage +The Dpl can be installed on any machine with: +``` +gem install dpl +``` + +This allows you to test all commands from your shell, rather than having to test it on a CI server. + +If you don't have Ruby installed you can do it on Debian-compatible Linux with: +``` +apt-get update +apt-get install ruby-dev +``` + +The Dpl provides support for vast number of services, including: Heroku, Cloud Foundry, AWS/S3, and more. +To use it simply define provider and any additional parameters required by the provider. + +For example if you want to use it to deploy your application to heroku, you need to specify `heroku` as provider, specify `api-key` and `app`. +There's more and all possible parameters can be found here: https://github.com/travis-ci/dpl#heroku + +``` +staging: + type: deploy + - gem install dpl + - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY +``` + +In the above example we use Dpl to deploy `my-app-staging` to Heroku server with api-key stored in `HEROKU_STAGING_API_KEY` secure variable. + +To use different provider take a look at long list of [Supported Providers](https://github.com/travis-ci/dpl#supported-providers). + +### Using Dpl with Docker +When you use GitLab Runner you most likely configured it to use your server's shell commands. +This means that all commands are run in context of local user (ie. gitlab_runner or gitlab_ci_multi_runner). +It also means that most probably in your Docker container you don't have the Ruby runtime installed. +You will have to install it: +``` +staging: + type: deploy + - apt-get update -yq + - apt-get install -y ruby-dev + - gem install dpl + - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY + only: + - master +``` + +The first line `apt-get update -yq` updates the list of available packages, where second `apt-get install -y ruby-dev` install `Ruby` runtime on system. +The above example is valid for all Debian-compatible systems. + +### Usage in staging and production +It's pretty common in developer workflow to have staging (development) and production environment. +If we consider above example: we would like to deploy `master` branch to `staging` and `all tags` to `production` environment. +The final `.gitlab-ci.yml` for that setup would look like this: + +``` +staging: + type: deploy + - gem install dpl + - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY + only: + - master + +production: + type: deploy + - gem install dpl + - dpl --provider=heroku --app=my-app-production --api-key=$HEROKU_PRODUCTION_API_KEY + only: + - tags +``` + +We created two deploy jobs that are executed on different events: +1. `staging` is executed for all commits that were pushed to `master` branch, +2. `production` is executed for all pushed tags. + +We also use two secure variables: +1. `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app, +2. `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app. + +### Storing API keys +In GitLab CI 7.12 a new feature was introduced: Secure Variables. +Secure Variables can added by going to `Project > Variables > Add Variable`. +**This feature requires `gitlab-runner` with version equal or greater than 0.4.0.** +The variables that are defined 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 projects' .gitlab-ci.yml. +It is also important that secret's value is hidden in the build log. + +You access added variable by prefixing it's name with `$` (on non-Windows runners) or `%` (for Windows Batch runners): +1. `$SECRET_VARIABLE` - use it for non-Windows runners +2. `%SECRET_VARIABLE%` - use it for Windows Batch runners diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md index 9f7c1bfe6a0..1848f6319d8 100644 --- a/doc/ci/triggers/README.md +++ b/doc/ci/triggers/README.md @@ -33,7 +33,7 @@ POST /projects/:id/trigger/builds The required parameters are the trigger's `token` and the Git `ref` on which the trigger will be performed. Valid refs are the branch, the tag or the commit -SHA. The `:id` of a project can be found by [querying the API](../api/projects.md) +SHA. The `:id` of a project can be found by [querying the API](../../api/projects.md) or by visiting the **Triggers** page which provides self-explanatory examples. When a rebuild is triggered, the information is exposed in GitLab's UI under diff --git a/doc/markdown/markdown.md b/doc/markdown/markdown.md index 4f199b6af6f..3f44a1b4c6c 100644 --- a/doc/markdown/markdown.md +++ b/doc/markdown/markdown.md @@ -402,7 +402,7 @@ There are two ways to create links, inline-style and reference-style. [I'm a reference-style link][Arbitrary case-insensitive reference text] -[I'm a relative reference to a repository file](LICENSE) +[I'm a relative reference to a repository file](LICENSE)[^1] [You can use numbers for reference-style link definitions][1] @@ -594,3 +594,4 @@ By including colons in the header row, you can align the text within that column [rouge]: http://rouge.jneen.net/ "Rouge website" [redcarpet]: https://github.com/vmg/redcarpet "Redcarpet website" +[^1]: This link will be broken if you see this document from the Help page or docs.gitlab.com -- cgit v1.2.1