From 0ba1efbb05fb3ed2cbbaf646b7fae5b9098c3021 Mon Sep 17 00:00:00 2001 From: Sytse Sijbrandij Date: Sat, 5 Dec 2015 14:24:56 -0800 Subject: Link to the gitlab-ci.yml file of GitLab itself. --- doc/ci/README.md | 1 + 1 file changed, 1 insertion(+) (limited to 'doc') diff --git a/doc/ci/README.md b/doc/ci/README.md index 97325069ceb..1746ea6dd4f 100644 --- a/doc/ci/README.md +++ b/doc/ci/README.md @@ -12,6 +12,7 @@ ### Examples ++ [The .gitlab-ci.yml file for GitLab itself](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab-ci.yml) + [Test and deploy Ruby applications to Heroku](examples/test-and-deploy-ruby-application-to-heroku.md) + [Test and deploy Python applications to Heroku](examples/test-and-deploy-python-application-to-heroku.md) + [Test Clojure applications](examples/test-clojure-application.md) -- cgit v1.2.1 From 3efae53bd79db118463bfaeceb209bc91f63bd0b Mon Sep 17 00:00:00 2001 From: Stan Hu Date: Fri, 11 Dec 2015 23:17:36 -0800 Subject: Add open_issues_count to project API This is needed to support Huboard and a generally useful value. --- doc/api/projects.md | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc') diff --git a/doc/api/projects.md b/doc/api/projects.md index 43a50a9a810..15956fe6df2 100644 --- a/doc/api/projects.md +++ b/doc/api/projects.md @@ -59,6 +59,7 @@ Parameters: "path": "diaspora-client", "path_with_namespace": "diaspora/diaspora-client", "issues_enabled": true, + "open_issues_count": 1, "merge_requests_enabled": true, "builds_enabled": true, "wiki_enabled": true, @@ -101,6 +102,7 @@ Parameters: "path": "puppet", "path_with_namespace": "brightbox/puppet", "issues_enabled": true, + "open_issues_count": 1, "merge_requests_enabled": true, "builds_enabled": true, "wiki_enabled": true, @@ -192,6 +194,7 @@ Parameters: "path": "diaspora-project-site", "path_with_namespace": "diaspora/diaspora-project-site", "issues_enabled": true, + "open_issues_count": 1, "merge_requests_enabled": true, "builds_enabled": true, "wiki_enabled": true, -- cgit v1.2.1 From 8e3f1fa629a61741282214b293c1bc9438aada59 Mon Sep 17 00:00:00 2001 From: tduehr Date: Wed, 11 Nov 2015 22:25:31 -0600 Subject: add CAS authentication support --- doc/integration/cas.md | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 doc/integration/cas.md (limited to 'doc') diff --git a/doc/integration/cas.md b/doc/integration/cas.md new file mode 100644 index 00000000000..3490f6a38e0 --- /dev/null +++ b/doc/integration/cas.md @@ -0,0 +1,62 @@ +# CAS OmniAuth Provider + +To enable the CAS OmniAuth provider you must register your application with your CAS instance. This requires the service URL gitlab will supply to CAS. It should be something like: `https://gitlab.example.com:443/users/auth/cas3/callback?url`. By default handling for SLO is enabled, you only need to configure CAS for backchannel logout. + +1. On your GitLab server, open the configuration file. + + For omnibus package: + + ```sh + sudo editor /etc/gitlab/gitlab.rb + ``` + + For instalations from source: + + ```sh + cd /home/git/gitlab + + sudo -u git -H editor config/gitlab.yml + ``` + +1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings. + +1. Add the provider configuration: + + For omnibus package: + + ```ruby + gitlab_rails['omniauth_providers'] = [ + { + name: "cas3", + label: "cas", + args: { + url: 'CAS_SERVER', + login_url: '/CAS_PATH/login', + service_validate_url: '/CAS_PATH/p3/serviceValidate', + logout_url: '/CAS_PATH/logout'} } + } + } + ] + ``` + + For installations from source: + + ``` + - { name: 'cas3', + label: 'cas', + args: { + url: 'CAS_SERVER', + login_url: '/CAS_PATH/login', + service_validate_url: '/CAS_PATH/p3/serviceValidate', + logout_url: '/CAS_PATH/logout'} } + ``` + +1. Change 'CAS_PATH' to the root of your CAS instance (ie. `cas`). + +1. If your CAS instance does not use default TGC lifetimes, update the `cas3.session_duration` to at least the current TGC maximum lifetime. To explicitly disable SLO, regardless of CAS settings, set this to 0. + +1. Save the configuration file. + +1. Restart GitLab for the changes to take effect. + +On the sign in page there should now be a CAS tab in the sign in form. \ No newline at end of file -- cgit v1.2.1 From 2c130aa087cb837332b2e4b27eb279ac0512a4c1 Mon Sep 17 00:00:00 2001 From: Jacob Vosmaer Date: Tue, 15 Dec 2015 16:38:11 +0100 Subject: Gitlab-workhorse related 8.3 update changes --- doc/update/8.2-to-8.3.md | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/update/8.2-to-8.3.md b/doc/update/8.2-to-8.3.md index e69c4f7ed3c..8ea2b674a1c 100644 --- a/doc/update/8.2-to-8.3.md +++ b/doc/update/8.2-to-8.3.md @@ -78,7 +78,7 @@ which should already be on your system from GitLab 8.1. ```bash cd /home/git/gitlab-workhorse sudo -u git -H git fetch --all -sudo -u git -H git checkout 0.4.2 +sudo -u git -H git checkout 0.5.0 sudo -u git -H make ``` @@ -115,6 +115,12 @@ git diff origin/8-2-stable:config/gitlab.yml.example origin/8-3-stable:config/gi #### Nginx configuration +GitLab 8.3 introduces major changes in the NGINX configuration. +Because all HTTP requests pass through gitlab-workhorse now a lot of +directives need to be removed from NGINX. During future upgrades there +should be much less changes in the NGINX configuration because of +this. + View changes between the previous recommended Nginx configuration and the current one: @@ -134,6 +140,18 @@ via [/etc/default/gitlab]. [Apache templates]: https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache [/etc/default/gitlab]: https://gitlab.com/gitlab-org/gitlab-ce/blob/8-3-stable/lib/support/init.d/gitlab.default.example#L34 +#### Init script + +We updated the init script for GitLab in order to pass new +configuration options to gitlab-workhorse. We let gitlab-workhorse +connect to the Rails application via a Unix domain socket and we tell +it where the 'public' directory of GitLab is. + +``` +cd /home/git/gitlab +sudo cp lib/support/init.d/gitlab /etc/init.d/gitlab +``` + ### 8. Use Redis v2.8.0+ Previous versions of GitLab allowed Redis versions >= 2.0 to be used, but -- cgit v1.2.1 From f2db1410f58357ae1033d90aae73acb3d5051644 Mon Sep 17 00:00:00 2001 From: Robert Speicher Date: Tue, 15 Dec 2015 12:21:53 -0500 Subject: Update workhorse version in doc/install/installation.md --- doc/install/installation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/install/installation.md b/doc/install/installation.md index f8116a8a31c..d4b5c01f72d 100644 --- a/doc/install/installation.md +++ b/doc/install/installation.md @@ -348,7 +348,7 @@ GitLab Shell is an SSH access and repository management software developed speci cd /home/git sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-workhorse.git cd gitlab-workhorse - sudo -u git -H git checkout 0.4.2 + sudo -u git -H git checkout 0.5.0 sudo -u git -H make ### Initialize Database and Activate Advanced Features -- cgit v1.2.1 From f98f353436d5f6305ec92de19d22a727b97dd4a0 Mon Sep 17 00:00:00 2001 From: Drew Blessing Date: Tue, 8 Dec 2015 16:25:47 -0600 Subject: [ci skip] Add SVN to Git migration documentation --- doc/README.md | 1 + doc/workflow/README.md | 1 + doc/workflow/importing/README.md | 20 ++++--- doc/workflow/importing/migrating_from_svn.md | 79 ++++++++++++++++++++++++---- 4 files changed, 84 insertions(+), 17 deletions(-) (limited to 'doc') diff --git a/doc/README.md b/doc/README.md index a3098094210..8bac00f2f23 100644 --- a/doc/README.md +++ b/doc/README.md @@ -7,6 +7,7 @@ - [GitLab Basics](gitlab-basics/README.md) Find step by step how to start working on your commandline and on GitLab. - [Importing to GitLab](workflow/importing/README.md). - [Markdown](markdown/markdown.md) GitLab's advanced formatting system. +- [Migrating from SVN](migration/README.md) Convert a SVN repository to Git and GitLab - [Permissions](permissions/permissions.md) Learn what each role in a project (guest/reporter/developer/master/owner) can do. - [Profile Settings](profile/README.md) - [Project Services](project_services/project_services.md) Integrate a project with external services, such as CI and chat. diff --git a/doc/workflow/README.md b/doc/workflow/README.md index d2642495c9a..3651b55f438 100644 --- a/doc/workflow/README.md +++ b/doc/workflow/README.md @@ -19,3 +19,4 @@ - ["Work In Progress" Merge Requests](wip_merge_requests.md) - [Merge When Build Succeeds](merge_when_build_succeeds.md) - [Manage large binaries with Git LFS](lfs/manage_large_binaries_with_git_lfs.md) +- [Importing from SVN, GitHub, BitBucket, etc](importing/README.md) diff --git a/doc/workflow/importing/README.md b/doc/workflow/importing/README.md index 7ccf06fbd60..18e5d950866 100644 --- a/doc/workflow/importing/README.md +++ b/doc/workflow/importing/README.md @@ -1,13 +1,17 @@ # Migrating projects to a GitLab instance 1. [Bitbucket](import_projects_from_bitbucket.md) -2. [GitHub](import_projects_from_github.md) -3. [GitLab.com](import_projects_from_gitlab_com.md) -4. [FogBugz](import_projects_from_fogbugz.md) -4. [SVN](migrating_from_svn.md) +1. [GitHub](import_projects_from_github.md) +1. [GitLab.com](import_projects_from_gitlab_com.md) +1. [FogBugz](import_projects_from_fogbugz.md) +1. [SVN](migrating_from_svn.md) -### Note -* If you'd like to migrate from a self-hosted GitLab instance to GitLab.com, you can copy your repos by changing the remote and pushing to the new server; but issues and merge requests can't be imported. +In addition to the specific migration documentation above, you can import any +Git repository via HTTP from the New Project page. Be aware that if the +repository is too large the import can timeout. + +### Migrating from self-hosted GitLab to GitLab.com + +You can copy your repos by changing the remote and pushing to the new server; +but issues and merge requests can't be imported. -* You can import any Git repository via HTTP from the New Project page. -If the repository is too large, it can timeout. diff --git a/doc/workflow/importing/migrating_from_svn.md b/doc/workflow/importing/migrating_from_svn.md index 1938ccd0c26..b355a91b5a6 100644 --- a/doc/workflow/importing/migrating_from_svn.md +++ b/doc/workflow/importing/migrating_from_svn.md @@ -1,17 +1,78 @@ # Migrating from SVN to GitLab -SVN stands for Subversion and is a version control system (VCS). -Git is a distributed version control system. +Subversion (SVN) is a central version control system (VCS) while +Git is a distributed version control system. There are some major differences +between the two, for more information consult your favorite search engine. -There are some major differences between the two, for more information consult your favorite search engine. +If you are currently using an SVN repository, you can migrate the repository +to Git and GitLab. We recommend a hard cut over - run the migration command once +and then have all developers start using the new GitLab repository immediately. +Otherwise, it's hard to keep changing in sync in both directions. The conversion +process should be run on a local workstation. -Git has tools for migrating SVN repositories to git, namely `git svn`. You can read more about this at -[git documentation pages](https://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion). +Install `svn2git`. On all systems you can install as a Ruby gem if you already +have Ruby and Git installed. -Apart from the [official git documentation](https://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git) there is also -user created step by step guide for migrating from SVN to GitLab. +```bash +sudo gem install svn2git +``` -[Benjamin New](https://github.com/leftclickben) wrote [a guide that shows how to do a migration](https://gist.github.com/leftclickben/322b7a3042cbe97ed2af). Mirrors can be found [here](https://gitlab.com/snippets/2168) and [here](https://gist.github.com/maxlazio/f1b593b0d00aa966e9ca). +On Debian-based Linux distributions you can install the native packages: + +```bash +sudo apt-get install git-core git-svn ruby +``` + +Optionally, prepare an authors file so `svn2git` can map SVN authors to Git authors. +If you choose not to create the authors file then commits will not be attributed +to the correct GitLab user. Some users may not consider this a big issue while +others will want to ensure they complete this step. If you choose to map authors +you will be required to map every author that is present on changes in the SVN +repository. If you don't, the conversion will fail and you will have to update +the author file accordingly. The following command will search through the +repository and output a list of authors. + +```bash +svn log --quiet | grep -E "r[0-9]+ \| .+ \|" | cut -d'|' -f2 | sed 's/ //g' | sort | uniq +``` + +Use the output from the last command to construct the authors file. +Create a file called `authors.txt` and add one mapping per line. + +``` +janedoe = Jane Doe +johndoe = John Doe +``` + +If your SVN repository is in the standard format (trunk, branches, tags, +not nested) the conversion is simple. For a non-standard repository see +[svn2git documentation](https://github.com/nirvdrum/svn2git). The following +command will checkout the repository and do the conversion in the current +working directory. Be sure to create a new directory for each repository before +running the `svn2git` command. The conversion process will take some time. + +```bash +svn2git https://svn.example.com/path/to/repo --authors /path/to/authors.txt +``` + +If your SVN repository requires a username and password add the +`--username ` and `--password /.git +git push --all origin +``` ## Contribute to this guide -We welcome all contributions that would expand this guide with instructions on how to migrate from SVN and other version control systems. +We welcome all contributions that would expand this guide with instructions on +how to migrate from SVN and other version control systems. + + -- cgit v1.2.1 From fc9fbdce44570042c79ff9a66289890bcb479524 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Thu, 10 Dec 2015 15:56:20 +0200 Subject: Clean up ci yaml doc [ci skip] * Fix headings so that they are picked up by doc.gitlab.com * Stick to 80 characters * Clean up some examples --- doc/ci/yaml/README.md | 345 +++++++++++++++++++++++++++++++------------------- 1 file changed, 212 insertions(+), 133 deletions(-) (limited to 'doc') diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 7e2edb945da..c5bdce2f778 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -1,9 +1,12 @@ # Configuration of your builds with .gitlab-ci.yml -From version 7.12, GitLab CI uses a [YAML](https://en.wikipedia.org/wiki/YAML) file (**.gitlab-ci.yml**) for the project configuration. -It is placed in the root of your repository and contains definitions of how your project should be built. -The YAML file defines a set of jobs with constraints stating when they should be run. -The jobs are defined as top-level elements with a name and always have to contain the `script` clause: +From version 7.12, GitLab CI uses a [YAML](https://en.wikipedia.org/wiki/YAML) +file (`.gitlab-ci.yml`) for the project configuration. It is placed in the root +of your repository and contains definitions of how your project should be built. + +The YAML file defines a set of jobs with constraints stating when they should +be run. The jobs are defined as top-level elements with a name and always have +to contain the `script` clause: ```yaml job1: @@ -13,15 +16,21 @@ job2: script: "execute-script-for-job2" ``` -The above example is the simplest possible CI configuration with two separate jobs, -where each of the jobs executes a different command. -Of course a command can execute code directly (`./configure;make;make install`) or run a script (`test.sh`) in the repository. +The above example is the simplest possible CI configuration with two separate +jobs, where each of the jobs executes a different command. + +Of course a command can execute code directly (`./configure;make;make install`) +or run a script (`test.sh`) in the repository. -Jobs are used to create builds, which are then picked up by [runners](../runners/README.md) and executed within the environment of the runner. -What is important, is that each job is run independently from each other. +Jobs are used to create builds, which are then picked up by +[runners](../runners/README.md) and executed within the environment of the +runner. What is important, is that each job is run independently from each +other. ## .gitlab-ci.yml -The YAML syntax allows for using more complex job specifications than in the above example: + +The YAML syntax allows for using more complex job specifications than in the +above example: ```yaml image: ruby:2.1 @@ -46,26 +55,31 @@ job1: - docker ``` -There are a few `keywords` that can't be used as job names: +There are a few reserved `keywords` that **cannot** be used as job names: -| keyword | required | description | +| Keyword | Required | Description | |---------------|----------|-------------| -| image | optional | Use docker image, covered in [Use Docker](../docker/README.md) | -| services | optional | Use docker services, covered in [Use Docker](../docker/README.md) | -| stages | optional | Define build stages | -| types | optional | Alias for `stages` | -| before_script | optional | Define commands prepended for each job's script | -| variables | optional | Define build variables | -| cache | optional | Define list of files that should be cached between subsequent runs | +| image | no | Use docker image, covered in [Use Docker](../docker/README.md) | +| services | no | Use docker services, covered in [Use Docker](../docker/README.md) | +| stages | no | Define build stages | +| types | no | Alias for `stages` | +| before_script | no | Define commands that run before each job's script | +| variables | no | Define build variables | +| cache | no | Define list of files that should be cached between subsequent runs | ### image and services -This allows to specify a custom Docker image and a list of services that can be used for time of the build. -The configuration of this feature is covered in separate document: [Use Docker](../docker/README.md). + +This allows to specify a custom Docker image and a list of services that can be +used for time of the build. The configuration of this feature is covered in +separate document: [Use Docker](../docker/README.md). ### before_script -`before_script` is used to define the command that should be run before all builds, including deploy builds. This can be an array or a multiline string. + +`before_script` is used to define the command that should be run before all +builds, including deploy builds. This can be an array or a multi-line string. ### stages + `stages` is used to define build stages that can be used by jobs. The specification of `stages` allows for having flexible multi stage pipelines. @@ -75,7 +89,8 @@ The ordering of elements in `stages` defines the ordering of builds' execution: 1. Builds of next stage are run after success. Let's consider the following example, which defines 3 stages: -``` + +```yaml stages: - build - test @@ -86,21 +101,26 @@ stages: 1. If all jobs of `build` succeeds, the `test` jobs are executed in parallel. 1. If all jobs of `test` succeeds, the `deploy` jobs are executed in parallel. 1. If all jobs of `deploy` succeeds, the commit is marked as `success`. -1. If any of the previous jobs fails, the commit is marked as `failed` and no jobs of further stage are executed. +1. If any of the previous jobs fails, the commit is marked as `failed` and no + jobs of further stage are executed. There are also two edge cases worth mentioning: -1. If no `stages` is defined in `.gitlab-ci.yml`, then by default the `build`, `test` and `deploy` are allowed to be used as job's stage by default. +1. If no `stages` is defined in `.gitlab-ci.yml`, then by default the `build`, + `test` and `deploy` are allowed to be used as job's stage by default. 2. If a job doesn't specify `stage`, the job is assigned the `test` stage. ### types + Alias for [stages](#stages). ### variables -**This feature requires `gitlab-runner` with version equal or greater than 0.5.0.** -GitLab CI allows you to add to `.gitlab-ci.yml` variables that are set in build environment. -The variables are stored in repository and are meant to store non-sensitive project configuration, ie. RAILS_ENV or DATABASE_URL. +_**Note:** Introduced in GitLab Runner v0.5.0._ + +GitLab CI allows you to add to `.gitlab-ci.yml` variables that are set in build +environment. The variables are stored in the git repository and are meant to +store non-sensitive project configuration, for example: ```yaml variables: @@ -109,18 +129,23 @@ variables: These variables can be later used in all executed commands and scripts. -The YAML-defined variables are also set to all created service containers, thus allowing to fine tune them. +The YAML-defined variables are also set to all created service containers, +thus allowing to fine tune them. ### cache -`cache` is used to specify list of files and directories which should be cached between builds. -Caches are stored according to the branch/ref and the job name. Caches are not -currently shared between different job names or between branches/refs. This means -caching will benefit you if you push subsequent commits to an existing feature branch. -**The global setting allows to specify default cached files for all jobs.** +`cache` is used to specify a list of files and directories which should be +cached between builds. Caches are stored according to the branch/ref and the +job name. They are not currently shared between different job names or between +branches/refs, which means that caching will benefit you if you push subsequent +commits to an existing feature branch. + +If `cache` is defined outside the scope of the jobs, it means it is set +globally and all jobs will use its definition. To cache all git untracked files and files in `binaries`: -``` + +```yaml cache: untracked: true paths: @@ -128,9 +153,10 @@ cache: ``` ## Jobs -`.gitlab-ci.yml` allows you to specify an unlimited number of jobs. -Each job has to have a unique `job_name`, which is not one of the keywords mentioned above. -A job is defined by a list of parameters that define the build behaviour. + +`.gitlab-ci.yml` allows you to specify an unlimited number of jobs. Each job +must have a unique name, which is not one of the Keywords mentioned above. +A job is defined by a list of parameters that define the build behavior. ```yaml job_name: @@ -148,21 +174,22 @@ job_name: allow_failure: true ``` -| keyword | required | description | +| Keyword | Required | Description | |---------------|----------|-------------| -| script | required | Defines a shell script which is executed by runner | -| stage | optional (default: test) | Defines a build stage | -| type | optional | Alias for `stage` | -| only | optional | Defines a list of git refs for which build is created | -| except | optional | Defines a list of git refs for which build is not created | -| tags | optional | Defines a list of tags which are used to select runner | -| allow_failure | optional | Allow build to fail. Failed build doesn't contribute to commit status | -| when | optional | Define when to run build. Can be `on_success`, `on_failure` or `always` | -| artifacts | optional | Define list build artifacts | -| cache | optional | Define list of files that should be cached between subsequent runs | +| script | yes | Defines a shell script which is executed by runner | +| stage | no (default: `test`) | Defines a build stage | +| type | no | Alias for `stage` | +| only | no | Defines a list of git refs for which build is created | +| except | no | Defines a list of git refs for which build is not created | +| tags | no | Defines a list of tags which are used to select runner | +| allow_failure | no | Allow build to fail. Failed build doesn't contribute to commit status | +| when | no | Define when to run build. Can be `on_success`, `on_failure` or `always` | +| artifacts | no | Define list build artifacts | +| cache | no | Define list of files that should be cached between subsequent runs | ### script -`script` is a shell script which is executed by runner. The shell script is prepended with `before_script`. + +`script` is a shell script which is executed by the runner. For example: ```yaml job: @@ -170,6 +197,7 @@ job: ``` This parameter can also contain several commands using an array: + ```yaml job: script: @@ -178,31 +206,45 @@ job: ``` ### stage -`stage` allows to group build into different stages. Builds of the same `stage` are executed in `parallel`. -For more info about the use of `stage` please check the [stages](#stages). + +`stage` allows to group build into different stages. Builds of the same `stage` +are executed in `parallel`. For more info about the use of `stage` please check +[stages](#stages). ### only and except -This are two parameters that allow for setting a refs policy to limit when jobs are built: -1. `only` defines the names of branches and tags for which job will be built. -2. `except` defines the names of branches and tags for which the job wil **not** be built. -There are a few rules that apply to usage of refs policy: +`only` and `except` are two parameters that set a refs policy to limit when +jobs are built: -1. `only` and `except` are inclusive. If both `only` and `except` are defined in job specification the ref is filtered by `only` and `except`. -1. `only` and `except` allow for using the regexp expressions. -1. `only` and `except` allow for using special keywords: `branches` and `tags`. -These names can be used for example to exclude all tags and all branches. +1. `only` defines the names of branches and tags for which the job will be + built. +2. `except` defines the names of branches and tags for which the job will + **not** be built. + +There are a few rules that apply to the usage of refs policy: + +* `only` and `except` are inclusive. If both `only` and `except` are defined + in a job specification, the ref is filtered by `only` and `except`. +* `only` and `except` allow the use of regular expressions. +* `only` and `except` allow the use of special keywords: `branches` and `tags`. +* `only` and `except` allow to specify a repository path to filter jobs for + forks. + +In the example below, `job` will run only for refs that start with `issue-`, +whereas all branches will be skipped. ```yaml job: + # use regexp only: - - /^issue-.*$/ # use regexp + - /^issue-.*$/ + # use special keyword except: - - branches # use special keyword + - branches ``` -1. `only` and `except` allow for specify repository path to filter jobs for forks. -The repository path can be used to have jobs executed only for parent repository. +The repository path can be used to have jobs executed only for the parent +repository and not forks: ```yaml job: @@ -211,33 +253,47 @@ job: except: - master@gitlab-org/gitlab-ce ``` -The above will run `job` for all branches on `gitlab-org/gitlab-ce`, except master . + +The above example will run `job` for all branches on `gitlab-org/gitlab-ce`, +except master. ### tags -`tags` is used to select specific runners from the list of all runners that are allowed to run this project. -During registration of a runner, you can specify the runner's tags, ie.: `ruby`, `postgres`, `development`. -`tags` allow you to run builds with runners that have the specified tags assigned: +`tags` is used to select specific runners from the list of all runners that are +allowed to run this project. -``` +During the registration of a runner, you can specify the runner's tags, for +example `ruby`, `postgres`, `development`. + +`tags` allow you to run builds with runners that have the specified tags +assigned to them: + +```yaml job: tags: - ruby - postgres ``` -The above specification will make sure that `job` is built by a runner that have `ruby` AND `postgres` tags defined. +The specification above, will make sure that `job` is built by a runner that +has both `ruby` AND `postgres` tags defined. ### when -`when` is used to implement jobs that are run in case of failure or despite the failure. + +`when` is used to implement jobs that are run in case of failure or despite the +failure. `when` can be set to one of the following values: -1. `on_success` - execute build only when all builds from prior stages succeeded. This is the default. -1. `on_failure` - execute build only when at least one build from prior stages failed. +1. `on_success` - execute build only when all builds from prior stages + succeeded. This is the default. +1. `on_failure` - execute build only when at least one build from prior stages + failed. 1. `always` - execute build despite the status of builds from prior stages. -``` +For example: + +```yaml stages: - build - cleanup_build @@ -245,28 +301,28 @@ stages: - deploy - cleanup -build: +build_job: stage: build script: - make build -cleanup_build: +cleanup_build_job: stage: cleanup_build script: - cleanup build when failed when: on_failure -test: +test_job: stage: test script: - make test -deploy: +deploy_job: stage: deploy script: - make deploy -cleanup: +cleanup_job: stage: cleanup script: - cleanup after builds @@ -274,84 +330,107 @@ cleanup: ``` The above script will: -1. Execute `cleanup_build` only when the `build` failed, -2. Always execute `cleanup` as the last step in pipeline. + +1. Execute `cleanup_build_job` only when `build_job` fails +2. Always execute `cleanup_job` as the last step in pipeline. ### artifacts -`artifacts` is used to specify list of files and directories which should be attached to build after success. -1. Send all files in `binaries` and `.config`: +_**Note:** Introduced in GitLab Runner v0.7.0._ - artifacts: - paths: - - binaries/ - - .config +`artifacts` is used to specify list of files and directories which should be +attached to build after success. Below are some examples. -2. Send all git untracked files: +Send all files in `binaries` and `.config`: - artifacts: - untracked: true +```yaml +artifacts: + paths: + - binaries/ + - .config +``` -3. Send all git untracked files and files in `binaries`: +Send all git untracked files: - artifacts: - untracked: true - paths: - - binaries/ +```yaml +artifacts: + untracked: true +``` + +Send all git untracked files and files in `binaries`: -The artifacts will be send after the build success to GitLab and will be accessible in GitLab interface to download. +```yaml +artifacts: + untracked: true + paths: + - binaries/ +``` -This feature requires GitLab Runner v0.7.0 or higher. +The artifacts will be send after a successful build success to GitLab, and will +be accessible in the GitLab UI to download. ### cache -`cache` is used to specify list of files and directories which should be cached between builds. -1. Cache all files in `binaries` and `.config`: +_**Note:** Introduced in GitLab Runner v0.7.0._ - rspec: - script: test - cache: - paths: - - binaries/ - - .config +`cache` is used to specify list of files and directories which should be cached +between builds. Below are some examples: -2. Cache all git untracked files: +Cache all files in `binaries` and `.config`: - rspec: - script: test - cache: - untracked: true - -3. Cache all git untracked files and files in `binaries`: +```yaml +rspec: + script: test + cache: + paths: + - binaries/ + - .config +``` - rspec: - script: test - cache: - untracked: true - paths: - - binaries/ +Cache all git untracked files: -4. Locally defined cache overwrites globally defined options. This will cache only `binaries/`: +```yaml +rspec: + script: test + cache: + untracked: true +``` + +Cache all git untracked files and files in `binaries`: + +```yaml +rspec: + script: test + cache: + untracked: true + paths: + - binaries/ +``` - cache: - paths: - - my/files - - rspec: - script: test - cache: - paths: - - binaries/ +Locally defined cache overwrites globally defined options. This will cache only +`binaries/`: -The cache is provided on best effort basis, so don't expect that cache will be present. -For implementation details please check GitLab Runner. +```yaml +cache: + paths: + - my/files -This feature requires GitLab Runner v0.7.0 or higher. +rspec: + script: test + cache: + paths: + - binaries/ +``` +The cache is provided on best effort basis, so don't expect that cache will be +always present. For implementation details please check GitLab Runner. ## Validate the .gitlab-ci.yml + Each instance of GitLab CI has an embedded debug tool called Lint. -You can find the link to the Lint in the project's settings page or use short url `/lint`. +You can find the link under `/ci/lint` of your gitlab instance. ## Skipping builds -There is one more way to skip all builds, if your commit message contains tag [ci skip]. In this case, commit will be created but builds will be skipped + +If your commit message contains `[ci skip]`, the commit will be created but the +builds will be skipped. -- cgit v1.2.1 From d2b5ef1c1e1011b5ccc8a3142b0147ce29632963 Mon Sep 17 00:00:00 2001 From: Cauan Cabral Date: Wed, 16 Dec 2015 14:23:02 -0300 Subject: Remove CI_BUILD_BEFORE_SHA from CI documentation As pointed in #3210, the environment variable isn't usable any more. --- doc/ci/variables/README.md | 2 -- 1 file changed, 2 deletions(-) (limited to 'doc') diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md index 022afb70042..b99ea25a3fe 100644 --- a/doc/ci/variables/README.md +++ b/doc/ci/variables/README.md @@ -27,7 +27,6 @@ The API_TOKEN will take the Secure Variable value: `SECURE`. | **CI_BUILD_TAG** | 0.5 | The commit tag name. Present only when building tags. | | **CI_BUILD_NAME** | 0.5 | The name of the build as defined in `.gitlab-ci.yml` | | **CI_BUILD_STAGE** | 0.5 | The name of the stage as defined in `.gitlab-ci.yml` | -| **CI_BUILD_BEFORE_SHA** | all | The first commit that were included in push request | | **CI_BUILD_REF_NAME** | all | The branch or tag name for which project is built | | **CI_BUILD_ID** | all | The unique id of the current build that GitLab CI uses internally | | **CI_BUILD_REPO** | all | The URL to clone the Git repository | @@ -40,7 +39,6 @@ The API_TOKEN will take the Secure Variable value: `SECURE`. Example values: ```bash -export CI_BUILD_BEFORE_SHA="9df57456fa9de2a6d335ca5edf9750ed812b9df0" export CI_BUILD_ID="50" export CI_BUILD_REF="1ecfd275763eff1d6b4844ea3168962458c9f27a" export CI_BUILD_REF_NAME="master" -- cgit v1.2.1 From c36821df9f571855b477b09c102b90a78b9079e9 Mon Sep 17 00:00:00 2001 From: Zeger-Jan van de Weg Date: Wed, 16 Dec 2015 21:39:27 +0100 Subject: Api support for requesting starred projects for user Fixes #4112 --- doc/api/projects.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'doc') diff --git a/doc/api/projects.md b/doc/api/projects.md index 2c7a3d5c552..658e65c6f01 100644 --- a/doc/api/projects.md +++ b/doc/api/projects.md @@ -139,6 +139,21 @@ Parameters: - `sort` (optional) - Return requests sorted in `asc` or `desc` order. Default is `desc` - `search` (optional) - Return list of authorized projects according to a search criteria +### List starred projects + +Get a list of projects which are starred by the authenticated user. + +``` +GET /projects/starred +``` + +Parameters: + +- `archived` (optional) - if passed, limit by archived status +- `order_by` (optional) - Return requests ordered by `id`, `name`, `path`, `created_at`, `updated_at` or `last_activity_at` fields. Default is `created_at` +- `sort` (optional) - Return requests sorted in `asc` or `desc` order. Default is `desc` +- `search` (optional) - Return list of authorized projects according to a search criteria + ### List ALL projects Get a list of all GitLab projects (admin only). -- cgit v1.2.1 From 8579fea2cfe4c822dae12efaf50f9e01adbc752e Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Thu, 17 Dec 2015 08:53:00 +0200 Subject: Add info on using private Docker registries in CI [ci skip] --- doc/ci/docker/using_docker_images.md | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md index 8d4bd44053e..31458d61674 100644 --- a/doc/ci/docker/using_docker_images.md +++ b/doc/ci/docker/using_docker_images.md @@ -1,11 +1,11 @@ # Using Docker Images -GitLab CI in conjuction with [GitLab Runner](../runners/README.md) can use +GitLab CI in conjunction with [GitLab Runner](../runners/README.md) can use [Docker Engine](https://www.docker.com/) to test and build any application. Docker is an open-source project that allows you to use predefined images to run applications in independent "containers" that are run within a single Linux -instance. [Docker Hub][hub] has a rich database of prebuilt images that can be +instance. [Docker Hub][hub] has a rich database of pre-built images that can be used to test and build your applications. Docker, when used with GitLab CI, runs each build in a separate and isolated @@ -136,6 +136,24 @@ Look for the `[runners.docker]` section: The image and services defined this way will be added to all builds run by that runner. +## Define an image from a private Docker registry + +Starting with GitLab Runner 0.6.0, you are able to define images located to +private registries that could also require authentication. + +All you have to do is be explicit on the image definition in `.gitlab-ci.yml`. + +```yaml +image: my.registry.tld:5000/namepace/image:tag +``` + +In the example above, GitLab Runner will look at `my.registry.tld:5000` for the +image `namespace/image:tag`. + +If the repository is private you need to authenticate your GitLab Runner in the +registry. Learn how to do that on +[GitLab Runner's documentation][runner-priv-reg]. + ## Accessing the services Let's say that you need a Wordpress instance to test some API integration with @@ -258,3 +276,4 @@ creation. [tutum/wordpress]: https://registry.hub.docker.com/u/tutum/wordpress/ [postgres-hub]: https://registry.hub.docker.com/u/library/postgres/ [mysql-hub]: https://registry.hub.docker.com/u/library/mysql/ +[runner-priv-reg]: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/configuration/advanced-configuration.md#using-a-private-docker-registry -- cgit v1.2.1 From b336eb01f711f170c20393cc07e7f9a7b80fea87 Mon Sep 17 00:00:00 2001 From: Jacob Vosmaer Date: Thu, 17 Dec 2015 11:55:13 +0100 Subject: Use gitlab-workhorse 0.5.1 --- doc/install/installation.md | 2 +- doc/update/8.2-to-8.3.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/install/installation.md b/doc/install/installation.md index d4b5c01f72d..81edd8da2b8 100644 --- a/doc/install/installation.md +++ b/doc/install/installation.md @@ -348,7 +348,7 @@ GitLab Shell is an SSH access and repository management software developed speci cd /home/git sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-workhorse.git cd gitlab-workhorse - sudo -u git -H git checkout 0.5.0 + sudo -u git -H git checkout 0.5.1 sudo -u git -H make ### Initialize Database and Activate Advanced Features diff --git a/doc/update/8.2-to-8.3.md b/doc/update/8.2-to-8.3.md index 8ea2b674a1c..b7022458396 100644 --- a/doc/update/8.2-to-8.3.md +++ b/doc/update/8.2-to-8.3.md @@ -78,7 +78,7 @@ which should already be on your system from GitLab 8.1. ```bash cd /home/git/gitlab-workhorse sudo -u git -H git fetch --all -sudo -u git -H git checkout 0.5.0 +sudo -u git -H git checkout 0.5.1 sudo -u git -H make ``` -- cgit v1.2.1 From c019154a911e751efba707f0323797b240775b08 Mon Sep 17 00:00:00 2001 From: Drew Blessing Date: Thu, 17 Dec 2015 13:01:57 -0600 Subject: Clarify Windows shell executor artifact upload support --- doc/ci/yaml/README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index c5bdce2f778..fd0d49de4e4 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -336,7 +336,8 @@ The above script will: ### artifacts -_**Note:** Introduced in GitLab Runner v0.7.0._ +_**Note:** Introduced in GitLab Runner v0.7.0. Also, the Windows shell executor + does not currently support artifact uploads._ `artifacts` is used to specify list of files and directories which should be attached to build after success. Below are some examples. -- cgit v1.2.1 From 56d780cf2c5b351479f002b221755bfb85b3ff70 Mon Sep 17 00:00:00 2001 From: Jacob Vosmaer Date: Thu, 17 Dec 2015 20:54:27 +0100 Subject: Use gitlab-shell 2.6.9 --- doc/update/8.2-to-8.3.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/update/8.2-to-8.3.md b/doc/update/8.2-to-8.3.md index b7022458396..c4661dc16af 100644 --- a/doc/update/8.2-to-8.3.md +++ b/doc/update/8.2-to-8.3.md @@ -67,7 +67,7 @@ sudo -u git -H git checkout 8-3-stable-ee ```bash cd /home/git/gitlab-shell sudo -u git -H git fetch --all -sudo -u git -H git checkout v2.6.8 +sudo -u git -H git checkout v2.6.9 ``` ### 5. Update gitlab-workhorse -- cgit v1.2.1 From f177aaa5fa789654dc440d6ec4ae3546544c1401 Mon Sep 17 00:00:00 2001 From: Drew Blessing Date: Thu, 17 Dec 2015 16:08:14 -0600 Subject: Backport JIRA service --- doc/integration/README.md | 1 + doc/integration/jira.md | 113 +++++++++++++++++++++++++++ doc/integration/jira_issue_reference.png | Bin 0 -> 39942 bytes doc/integration/jira_project_name.png | Bin 0 -> 60598 bytes doc/integration/jira_service.png | Bin 0 -> 59082 bytes doc/integration/jira_service_close_issue.png | Bin 0 -> 88433 bytes doc/integration/jira_service_page.png | Bin 0 -> 162449 bytes doc/integration/jira_workflow_screenshot.png | Bin 0 -> 121534 bytes 8 files changed, 114 insertions(+) create mode 100644 doc/integration/jira.md create mode 100644 doc/integration/jira_issue_reference.png create mode 100644 doc/integration/jira_project_name.png create mode 100644 doc/integration/jira_service.png create mode 100644 doc/integration/jira_service_close_issue.png create mode 100644 doc/integration/jira_service_page.png create mode 100644 doc/integration/jira_workflow_screenshot.png (limited to 'doc') diff --git a/doc/integration/README.md b/doc/integration/README.md index eff39a626ae..8ea4111bc8a 100644 --- a/doc/integration/README.md +++ b/doc/integration/README.md @@ -4,6 +4,7 @@ GitLab integrates with multiple third-party services to allow external issue tra See the documentation below for details on how to configure these services. +- [Jira](jira.md) Integrate with the JIRA issue tracker - [External issue tracker](external-issue-tracker.md) Redmine, JIRA, etc. - [LDAP](ldap.md) Set up sign in via LDAP - [OmniAuth](omniauth.md) Sign in via Twitter, GitHub, GitLab, and Google via OAuth. diff --git a/doc/integration/jira.md b/doc/integration/jira.md new file mode 100644 index 00000000000..624601d0fac --- /dev/null +++ b/doc/integration/jira.md @@ -0,0 +1,113 @@ +# GitLab Jira integration + +GitLab can be configured to interact with Jira. +Configuration happens via username and password. +Connecting to a Jira server via CAS is not possible. + +Each project can be configured to connect to a different Jira instance, configuration is explained [here](#configuration). +If you have one Jira instance you can pre-fill the settings page with a default template. To configure the template [see external issue tracker document](external-issue-tracker.md#service-template)). + +Once the project is connected to Jira, you can reference and close the issues in Jira directly from GitLab. + + +## Table of Contents + +* [Referencing Jira Issues from GitLab](#referencing-jira-issues) +* [Closing Jira Issues from GitLab](#closing-jira-issues) +* [Configuration](#configuration) + +### Referencing Jira Issues + +When GitLab project has Jira issue tracker configured and enabled, mentioning Jira issue in GitLab will automatically add a comment in Jira issue with the link back to GitLab. This means that in comments in merge requests and commits referencing an issue, eg. `PROJECT-7`, will add a comment in Jira issue in the format: + + +``` + USER mentioned this issue in LINK_TO_THE_MENTION +``` + +* `USER` A user that mentioned the issue. This is the link to the user profile in GitLab. +* `LINK_TO_THE_MENTION` Link to the origin of mention with a name of the entity where Jira issue was mentioned. +Can be commit or merge request. + + +![example of mentioning or closing the Jira issue](jira_issue_reference.png) + + +### Closing Jira Issues + +Jira issues can be closed directly from GitLab by using trigger words, eg. `Resolves PROJECT-1`, `Closes PROJECT-1` or `Fixes PROJECT-1`, in commits and merge requests. +When a commit which contains the trigger word in the commit message is pushed, GitLab will add a comment in the mentioned Jira issue. + +For example, for project named PROJECT in Jira, we implemented a new feature and created a merge request in GitLab. + +This feature was requested in Jira issue PROJECT-7. Merge request in GitLab contains the improvement and in merge request description we say that this merge request `Closes PROJECT-7` issue. + +Once this merge request is merged, Jira issue will be automatically closed with a link to the commit that resolved the issue. + +![A Git commit that causes the Jira issue to be closed](merge_request_close_jira.png) + + +![The GitLab integration user leaves a comment on Jira](jira_service_close_issue.png) + + +## Configuration + +### Configuring JIRA + +We need to create a user in JIRA which will have access to all projects that need to integrate with GitLab. +Login to your JIRA instance as admin and under Administration go to User Management and create a new user. +As an example, we'll create a user named `gitlab` and add it to `jira-developers` group. + +**It is important that the user `gitlab` has write-access to projects in JIRA** + +### Configuring GitLab + +### GitLab 7.8 EE and up with JIRA v6.x + +To enable JIRA integration in a project, navigate to the project Settings page and go to Services. Here you will find JIRA. + +Fill in the required details on the page: + +![Jira service page](jira_service_page.png) + +* `description` A name for the issue tracker (to differentiate between instances, for instance). +* `project url` The URL to the JIRA project which is being linked to this GitLab project. +* `issues url` The URL to the JIRA project issues overview for the project that is linked to this GitLab project. +* `new issue url` This is the URL to create a new issue in JIRA for the project linked to this GitLab project. +* `api url` The base URL of the JIRA API. It may be omitted, in which case GitLab will automatically use API version `2` based on the `project url`, i.e. `https://jira.example.com/rest/api/2`. +* `username` The username of the user created in [configuring JIRA step](#configuring-jira). +* `password` The password of the user created in [configuring JIRA step](#configuring-jira). +* `Jira issue transition` This is the id of a transition that moves issues to a closed state. You can find this number under [JIRA workflow administration, see screenshot](jira_workflow_screenshot.png). By default, this id is `2`. (In the example image, this is `2` as well) + +After saving the configuration, your GitLab project will be able to interact with the linked JIRA project. + + +### GitLab 6.x-7.7 with JIRA v6.x + +**Note: GitLab 7.8 and up contain various integration improvements. We strongly recommend upgrading.** + + +In `gitlab.yml` enable [JIRA issue tracker section by uncommenting the lines](https://gitlab.com/subscribers/gitlab-ee/blob/6-8-stable-ee/config/gitlab.yml.example#L111-115). +This will make sure that all issues within GitLab are pointing to the JIRA issue tracker. + +We can also enable JIRA service that will allow us to interact with JIRA issues. + +For example, we can close issues in JIRA by a commit in GitLab. + +Go to project settings page and fill in the project name for the JIRA project: + +![Set the JIRA project name in GitLab to 'NEW'](jira_project_name.png) + +Next, go to the services page and find JIRA. + +![Jira services page](jira_service.png) + +1. Tick the active check box to enable the service. +1. Supply the url to JIRA server, for example http://jira.sample +1. Supply the username of a user we created under `Configuring JIRA` section, for example `gitlab` +1. Supply the password of the user +1. Optional: supply the JIRA api version, default is version +1. Optional: supply the JIRA issue transition ID (issue transition to closed). This is dependant on JIRA settings, default is 2 +1. Save + +Now we should be able to interact with JIRA issues. diff --git a/doc/integration/jira_issue_reference.png b/doc/integration/jira_issue_reference.png new file mode 100644 index 00000000000..15739a22dc7 Binary files /dev/null and b/doc/integration/jira_issue_reference.png differ diff --git a/doc/integration/jira_project_name.png b/doc/integration/jira_project_name.png new file mode 100644 index 00000000000..5986fdb63fb Binary files /dev/null and b/doc/integration/jira_project_name.png differ diff --git a/doc/integration/jira_service.png b/doc/integration/jira_service.png new file mode 100644 index 00000000000..1f6628c4371 Binary files /dev/null and b/doc/integration/jira_service.png differ diff --git a/doc/integration/jira_service_close_issue.png b/doc/integration/jira_service_close_issue.png new file mode 100644 index 00000000000..67dfc6144c4 Binary files /dev/null and b/doc/integration/jira_service_close_issue.png differ diff --git a/doc/integration/jira_service_page.png b/doc/integration/jira_service_page.png new file mode 100644 index 00000000000..69ec44e826f Binary files /dev/null and b/doc/integration/jira_service_page.png differ diff --git a/doc/integration/jira_workflow_screenshot.png b/doc/integration/jira_workflow_screenshot.png new file mode 100644 index 00000000000..8635a32eb68 Binary files /dev/null and b/doc/integration/jira_workflow_screenshot.png differ -- cgit v1.2.1 From a3de46654b2fe0f02995913a771e6423bb584d64 Mon Sep 17 00:00:00 2001 From: Jose Torres Date: Sat, 19 Dec 2015 15:16:50 -0600 Subject: Adding how we manage CRIME vulnerability to security docs [ci skip] --- doc/security/README.md | 1 + doc/security/crime_vulnerability.md | 59 +++++++++++++++++++++++++++++++++++++ 2 files changed, 60 insertions(+) create mode 100644 doc/security/crime_vulnerability.md (limited to 'doc') diff --git a/doc/security/README.md b/doc/security/README.md index fba6013d9c1..7df7cef6aa5 100644 --- a/doc/security/README.md +++ b/doc/security/README.md @@ -6,3 +6,4 @@ - [Information exclusivity](information_exclusivity.md) - [Reset your root password](reset_root_password.md) - [User File Uploads](user_file_uploads.md) +- [How we manage the CRIME vulnerability](crime_vulnerability.md) diff --git a/doc/security/crime_vulnerability.md b/doc/security/crime_vulnerability.md new file mode 100644 index 00000000000..d716bff85a5 --- /dev/null +++ b/doc/security/crime_vulnerability.md @@ -0,0 +1,59 @@ +# How we manage the TLS protocol CRIME vulnerability + +> CRIME ("Compression Ratio Info-leak Made Easy") is a security exploit against +secret web cookies over connections using the HTTPS and SPDY protocols that also +use data compression.[1][2] When used to recover the content of secret +authentication cookies, it allows an attacker to perform session hijacking on an +authenticated web session, allowing the launching of further attacks. +([CRIME](https://en.wikipedia.org/w/index.php?title=CRIME&oldid=692423806)) + +### Description + +The TLS Protocol CRIME Vulnerability affects compression over HTTPS therefore +it warns against using SSL Compression, take gzip for example, or SPDY which +optionally uses compression as well. + +GitLab support both gzip and SPDY and manages the CRIME vulnerability by +deactivating gzip when https is enabled and not activating the compression +feature on SDPY. + +Take a look at our configuration file for NGINX if you'd like to explore how the +conditions are setup for gzip deactivation on this link: +[GitLab NGINX File](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/nginx-gitlab-http.conf.erb). + +For SPDY you can also watch how its implmented on NGINX at [GitLab NGINX File](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/nginx-gitlab-http.conf.erb) +but take into consideration the NGINX documentation on its default state here: +[Module ngx_http_spdy_module](http://nginx.org/en/docs/http/ngx_http_spdy_module.html). + + +### Nessus + +The Nessus scanner reports a possible CRIME vunerability for GitLab similar to the +following format: + + Description + + This remote service has one of two configurations that are known to be required for the CRIME attack: + SSL/TLS compression is enabled. + TLS advertises the SPDY protocol earlier than version 4. + + ... + + Output + + The following configuration indicates that the remote service may be vulnerable to the CRIME attack: + SPDY support earlier than version 4 is advertised. + +*[This](http://www.tenable.com/plugins/index.php?view=single&id=62565) is a complete description from Nessus.* + +From the report above its important to note that Nessus is only checkng if TLS +advertises the SPDY protocol earlier than version 4, it does not perform an +attack nor does it check if compression is enabled. With just this approach it +cannot tell that SPDY's compression is disabled and not subject to the CRIME +vulnerbility. + + +### Reference +* Nginx. "Module ngx_http_spdy_module", Fri. 18 Dec. +* Tenable Network Security, Inc. "Transport Layer Security (TLS) Protocol CRIME Vulnerability", Web. 15 Dec. +* Wikipedia contributors. "CRIME." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 25 Nov. 2015. Web. 15 Dec. 2015. \ No newline at end of file -- cgit v1.2.1 From 33ef13c641a63c4c82c5867a6f01a90c57f3aa04 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Mon, 21 Dec 2015 15:53:08 +0200 Subject: Init documentation on Triggers [ci skip] --- doc/ci/README.md | 39 ++++++++++++++++++++------------------- doc/ci/triggers/README.md | 11 +++++++++++ 2 files changed, 31 insertions(+), 19 deletions(-) create mode 100644 doc/ci/triggers/README.md (limited to 'doc') diff --git a/doc/ci/README.md b/doc/ci/README.md index 5d9d7a81db3..aef6e69b7a6 100644 --- a/doc/ci/README.md +++ b/doc/ci/README.md @@ -2,34 +2,35 @@ ### User documentation -+ [Quick Start](quick_start/README.md) -+ [Configuring project (.gitlab-ci.yml)](yaml/README.md) -+ [Configuring runner](runners/README.md) -+ [Configuring deployment](deployment/README.md) -+ [Using Docker Images](docker/using_docker_images.md) -+ [Using Docker Build](docker/using_docker_build.md) -+ [Using Variables](variables/README.md) -+ [Using SSH keys](ssh_keys/README.md) +* [Quick Start](quick_start/README.md) +* [Configuring project (.gitlab-ci.yml)](yaml/README.md) +* [Configuring runner](runners/README.md) +* [Configuring deployment](deployment/README.md) +* [Using Docker Images](docker/using_docker_images.md) +* [Using Docker Build](docker/using_docker_build.md) +* [Using Variables](variables/README.md) +* [Using SSH keys](ssh_keys/README.md) +* [Triggering builds through the API](triggers/README.md) ### Languages -+ [Testing PHP](languages/php.md) +* [Testing PHP](languages/php.md) ### Services -+ [Using MySQL](services/mysql.md) -+ [Using PostgreSQL](services/postgres.md) -+ [Using Redis](services/redis.md) -+ [Using Other Services](docker/using_docker_images.md#how-to-use-other-images-as-services) +* [Using MySQL](services/mysql.md) +* [Using PostgreSQL](services/postgres.md) +* [Using Redis](services/redis.md) +* [Using Other Services](docker/using_docker_images.md#how-to-use-other-images-as-services) ### Examples -+ [Test and deploy Ruby applications to Heroku](examples/test-and-deploy-ruby-application-to-heroku.md) -+ [Test and deploy Python applications to Heroku](examples/test-and-deploy-python-application-to-heroku.md) -+ [Test Clojure applications](examples/test-clojure-application.md) -+ Help your favorite programming language and GitLab by sending a merge request with a guide for that language. +* [Test and deploy Ruby applications to Heroku](examples/test-and-deploy-ruby-application-to-heroku.md) +* [Test and deploy Python applications to Heroku](examples/test-and-deploy-python-application-to-heroku.md) +* [Test Clojure applications](examples/test-clojure-application.md) +* Help your favorite programming language and GitLab by sending a merge request with a guide for that language. ### Administrator documentation -+ [User permissions](permissions/README.md) -+ [API](api/README.md) +* [User permissions](permissions/README.md) +* [API](api/README.md) diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md new file mode 100644 index 00000000000..5990d74fda1 --- /dev/null +++ b/doc/ci/triggers/README.md @@ -0,0 +1,11 @@ +# Triggering Builds through the API + +_**Note:** This feature was [introduced][ci-229] in GitLab CE 7.14_ + +Triggers can be used to force a rebuild of a specific branch or tag with an API +call. + +## Add a trigger + + +[ci-229]: https://gitlab.com/gitlab-org/gitlab-ci/merge_requests/229 -- cgit v1.2.1 From 7fc2422c8d660d310b819b2b6ffbca9a9e4d8cd6 Mon Sep 17 00:00:00 2001 From: Douwe Maan Date: Mon, 21 Dec 2015 17:37:55 +0100 Subject: Add link to CAS doc --- doc/integration/README.md | 1 + doc/integration/cas.md | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) (limited to 'doc') diff --git a/doc/integration/README.md b/doc/integration/README.md index eff39a626ae..50213f500b9 100644 --- a/doc/integration/README.md +++ b/doc/integration/README.md @@ -8,6 +8,7 @@ See the documentation below for details on how to configure these services. - [LDAP](ldap.md) Set up sign in via LDAP - [OmniAuth](omniauth.md) Sign in via Twitter, GitHub, GitLab, and Google via OAuth. - [SAML](saml.md) Configure GitLab as a SAML 2.0 Service Provider +- [CAS](cas.md) Configure GitLab to sign in using CAS - [Slack](slack.md) Integrate with the Slack chat service - [OAuth2 provider](oauth_provider.md) OAuth2 application creation - [Gmail actions buttons](gmail_action_buttons_for_gitlab.md) Adds GitLab actions to messages diff --git a/doc/integration/cas.md b/doc/integration/cas.md index 3490f6a38e0..e6b2071f193 100644 --- a/doc/integration/cas.md +++ b/doc/integration/cas.md @@ -1,6 +1,6 @@ # CAS OmniAuth Provider -To enable the CAS OmniAuth provider you must register your application with your CAS instance. This requires the service URL gitlab will supply to CAS. It should be something like: `https://gitlab.example.com:443/users/auth/cas3/callback?url`. By default handling for SLO is enabled, you only need to configure CAS for backchannel logout. +To enable the CAS OmniAuth provider you must register your application with your CAS instance. This requires the service URL GitLab will supply to CAS. It should be something like: `https://gitlab.example.com:443/users/auth/cas3/callback?url`. By default handling for SLO is enabled, you only need to configure CAS for backchannel logout. 1. On your GitLab server, open the configuration file. @@ -10,7 +10,7 @@ To enable the CAS OmniAuth provider you must register your application with your sudo editor /etc/gitlab/gitlab.rb ``` - For instalations from source: + For installations from source: ```sh cd /home/git/gitlab @@ -59,4 +59,4 @@ To enable the CAS OmniAuth provider you must register your application with your 1. Restart GitLab for the changes to take effect. -On the sign in page there should now be a CAS tab in the sign in form. \ No newline at end of file +On the sign in page there should now be a CAS tab in the sign in form. -- cgit v1.2.1 From d5e9436033d75da74c40ced450e060c8a5c307f9 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Mon, 21 Dec 2015 20:41:51 +0200 Subject: Document triggers in yaml/README.md [ci skip] --- doc/ci/yaml/README.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'doc') diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index fd0d49de4e4..6862116cc5b 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -66,6 +66,7 @@ There are a few reserved `keywords` that **cannot** be used as job names: | before_script | no | Define commands that run before each job's script | | variables | no | Define build variables | | cache | no | Define list of files that should be cached between subsequent runs | +| trigger | no | Force a rebuild of a specific branch or tag with an API call | ### image and services @@ -152,6 +153,32 @@ cache: - binaries/ ``` +### trigger + +Triggers can be used to force a rebuild of a specific branch or tag with an API +call. You can add a trigger by visiting the project's **Settings > Triggers**. + +Every new trigger you create, gets assigned a different token which you can +then use inside your `.gitlab-ci.yml`: + +```yaml +trigger: + stage: deploy + script: + - "curl -X POST -F token=TOKEN -F ref=master https://gitlab.com/api/v3/projects/9/trigger/builds" +``` + +In the example above, a rebuild on master branch will be triggered after all +previous stages build successfully (denoted by `stage: deploy`). + +You can find the endpoint containing the ID of the project on the **Triggers** +page. + +_**Warning:** Be careful how you set up your triggers, because you could end up +in an infinite loop._ + +Read more in the dedicated [triggers documentation](../triggers/README.md). + ## Jobs `.gitlab-ci.yml` allows you to specify an unlimited number of jobs. Each job -- cgit v1.2.1 From 9a166c1ed85dc4ba96cbd43098d71c83bda2a93a Mon Sep 17 00:00:00 2001 From: Raymii Date: Tue, 22 Dec 2015 05:29:19 +0000 Subject: `update-init-script` was listed two times. removed one without explanation. --- doc/update/8.2-to-8.3.md | 2 -- 1 file changed, 2 deletions(-) (limited to 'doc') diff --git a/doc/update/8.2-to-8.3.md b/doc/update/8.2-to-8.3.md index c4661dc16af..3748941b781 100644 --- a/doc/update/8.2-to-8.3.md +++ b/doc/update/8.2-to-8.3.md @@ -99,8 +99,6 @@ sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production # Clean up assets and cache sudo -u git -H bundle exec rake assets:clean assets:precompile cache:clear RAILS_ENV=production -# Update init.d script -sudo cp lib/support/init.d/gitlab /etc/init.d/gitlab ``` ### 7. Update configuration files -- cgit v1.2.1 From 301a30e0ea573c83c28358b2c856396fda878089 Mon Sep 17 00:00:00 2001 From: Stan Hu Date: Sun, 13 Dec 2015 11:43:17 -0800 Subject: Add project permissions to all project API endpoints This standardizes all the project API formats. Also needed to support Huboard. --- doc/api/projects.md | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'doc') diff --git a/doc/api/projects.md b/doc/api/projects.md index 658e65c6f01..0ca81ffd49e 100644 --- a/doc/api/projects.md +++ b/doc/api/projects.md @@ -118,6 +118,16 @@ Parameters: "path": "brightbox", "updated_at": "2013-09-30T13:46:02Z" }, + "permissions": { + "project_access": { + "access_level": 10, + "notification_level": 3 + }, + "group_access": { + "access_level": 50, + "notification_level": 3 + } + }, "archived": false, "avatar_url": null } -- cgit v1.2.1 From 5a8c65b508614dd8896ff8af7cad6e2b33fb7244 Mon Sep 17 00:00:00 2001 From: Stan Hu Date: Sat, 12 Dec 2015 22:02:05 -0800 Subject: Add API support for looking up a user by username Needed to support Huboard --- doc/api/users.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/api/users.md b/doc/api/users.md index 7ba2db248ff..66d2fd52526 100644 --- a/doc/api/users.md +++ b/doc/api/users.md @@ -90,7 +90,17 @@ GET /users You can search for users by email or username with: `/users?search=John` -Also see `def search query` in `app/models/user.rb`. +In addition, you can lookup users by username: + +``` +GET /users?username=:username +``` + +For example: + +``` +GET /users?username=jack_smith +``` ## Single user -- cgit v1.2.1 From 6fce8b6f5cfee1fe17ef7cdb5508b66da93f1f14 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Thu, 24 Dec 2015 21:48:24 +0200 Subject: Add triggers doc in top level readme [ci skip] --- doc/README.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'doc') diff --git a/doc/README.md b/doc/README.md index 8bac00f2f23..f40a257b42f 100644 --- a/doc/README.md +++ b/doc/README.md @@ -28,17 +28,18 @@ - [Using SSH keys](ci/ssh_keys/README.md) - [User permissions](ci/permissions/README.md) - [API](ci/api/README.md) +- [Triggering builds through the API](ci/triggers/README.md) ### CI Languages -+ [Testing PHP](ci/languages/php.md) +- [Testing PHP](ci/languages/php.md) ### CI Services -+ [Using MySQL](ci/services/mysql.md) -+ [Using PostgreSQL](ci/services/postgres.md) -+ [Using Redis](ci/services/redis.md) -+ [Using Other Services](ci/docker/using_docker_images.md#how-to-use-other-images-as-services) +- [Using MySQL](ci/services/mysql.md) +- [Using PostgreSQL](ci/services/postgres.md) +- [Using Redis](ci/services/redis.md) +- [Using Other Services](ci/docker/using_docker_images.md#how-to-use-other-images-as-services) ### CI Examples -- cgit v1.2.1 From aafd7ce83bf1f6c1074b93ad489caa03e5b20786 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Thu, 24 Dec 2015 21:50:03 +0200 Subject: Remove triggers from yaml doc [ci skip] --- doc/ci/yaml/README.md | 27 --------------------------- 1 file changed, 27 deletions(-) (limited to 'doc') diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 6862116cc5b..fd0d49de4e4 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -66,7 +66,6 @@ There are a few reserved `keywords` that **cannot** be used as job names: | before_script | no | Define commands that run before each job's script | | variables | no | Define build variables | | cache | no | Define list of files that should be cached between subsequent runs | -| trigger | no | Force a rebuild of a specific branch or tag with an API call | ### image and services @@ -153,32 +152,6 @@ cache: - binaries/ ``` -### trigger - -Triggers can be used to force a rebuild of a specific branch or tag with an API -call. You can add a trigger by visiting the project's **Settings > Triggers**. - -Every new trigger you create, gets assigned a different token which you can -then use inside your `.gitlab-ci.yml`: - -```yaml -trigger: - stage: deploy - script: - - "curl -X POST -F token=TOKEN -F ref=master https://gitlab.com/api/v3/projects/9/trigger/builds" -``` - -In the example above, a rebuild on master branch will be triggered after all -previous stages build successfully (denoted by `stage: deploy`). - -You can find the endpoint containing the ID of the project on the **Triggers** -page. - -_**Warning:** Be careful how you set up your triggers, because you could end up -in an infinite loop._ - -Read more in the dedicated [triggers documentation](../triggers/README.md). - ## Jobs `.gitlab-ci.yml` allows you to specify an unlimited number of jobs. Each job -- cgit v1.2.1 From 1249289f89feba725109ce769e685b07cf746e4b Mon Sep 17 00:00:00 2001 From: Gabriel Mazetto Date: Thu, 24 Dec 2015 18:58:46 -0200 Subject: Fixed codestyle and added 2FA documentation --- doc/security/README.md | 1 + doc/security/two_factor_authentication.md | 38 +++++++++++++++++++++++++++++++ 2 files changed, 39 insertions(+) create mode 100644 doc/security/two_factor_authentication.md (limited to 'doc') diff --git a/doc/security/README.md b/doc/security/README.md index fba6013d9c1..384df570394 100644 --- a/doc/security/README.md +++ b/doc/security/README.md @@ -6,3 +6,4 @@ - [Information exclusivity](information_exclusivity.md) - [Reset your root password](reset_root_password.md) - [User File Uploads](user_file_uploads.md) +- [Enforce Two-Factor authentication](two_factor_authentication.md) diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md new file mode 100644 index 00000000000..4e25a1fdc3f --- /dev/null +++ b/doc/security/two_factor_authentication.md @@ -0,0 +1,38 @@ +# Enforce Two-factor Authentication (2FA) + +Two-factor Authentication (2FA) provides an additional level of security to your +users' GitLab account. Once enabled, in addition to supplying their username and +password to login, they'll be prompted for a code generated by an application on +their phone. + +You can read more about it here: +[Two-factor Authentication (2FA)](doc/profile/two_factor_authentication.md) + +## Enabling 2FA + +Users on GitLab, can enable it without any admin's intervention. If you want to +enforce everyone to setup 2FA, you can choose from two different ways: + + 1. Enforce on next login + 2. Suggest on next login, but allow a grace period before enforcing. + +In the Admin area under **Settings** (`/admin/application_settings`), look for +the "Sign-in Restrictions" area, where you can configure both. + +If you want 2FA enforcement to take effect on next login, change the grace +period to `0` + +## Disabling 2FA for everyone + +There may be some special situations where you want to disable 2FA for everyone +even when forced 2FA is disabled. There is a rake task for that: + +``` +# use this command if you've installed GitLab with the Omnibus package +sudo gitlab-rake gitlab:two_factor:disable_for_all_users + +# if you've installed GitLab from source +sudo -u git -H bundle exec rake gitlab:two_factor:disable_for_all_users RAILS_ENV=production +``` + +**IMPORTANT: this is a permanent and irreversible action. Users will have to reactivate 2FA from scratch if they want to use it again.** -- cgit v1.2.1 From e74affcfa84acaddc236d6dfed7be1a61470dc0e Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Fri, 25 Dec 2015 01:29:27 +0200 Subject: Add images and examples --- doc/ci/triggers/README.md | 97 ++++++++++++++++++++++++++- doc/ci/triggers/img/builds_page.png | Bin 0 -> 39713 bytes doc/ci/triggers/img/trigger_single_build.png | Bin 0 -> 2895 bytes doc/ci/triggers/img/trigger_variables.png | Bin 0 -> 5418 bytes doc/ci/triggers/img/triggers_page.png | Bin 0 -> 15889 bytes 5 files changed, 95 insertions(+), 2 deletions(-) create mode 100644 doc/ci/triggers/img/builds_page.png create mode 100644 doc/ci/triggers/img/trigger_single_build.png create mode 100644 doc/ci/triggers/img/trigger_variables.png create mode 100644 doc/ci/triggers/img/triggers_page.png (limited to 'doc') diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md index 5990d74fda1..63661ee4858 100644 --- a/doc/ci/triggers/README.md +++ b/doc/ci/triggers/README.md @@ -2,10 +2,103 @@ _**Note:** This feature was [introduced][ci-229] in GitLab CE 7.14_ -Triggers can be used to force a rebuild of a specific branch or tag with an API -call. +Triggers can be used to force a rebuild of a specific branch, tag or commit, +with an API call. ## Add a trigger +You can add a new trigger by going to your project's **Settings > Triggers**. +The **Add trigger** button will create a new token which you can then use to +trigger a rebuild of this particular project. + +Once at least one trigger is created, on the **Triggers** page you will find +some descriptive information on how you can + +Every new trigger you create, gets assigned a different token which you can +then use inside your scripts or `.gitlab-ci.yml`. You also have a nice +overview of the time the triggers were last used. + +![Triggers page overview](img/triggers_page.png) + +## Revoke a trigger + +You can revoke a trigger any time by going at your project's +**Settings > Triggers** and hitting the **Revoke** button. The action is +irreversible. + +## Trigger a build + +To trigger a build you need to send a `POST` request to GitLab's API endpoint: + +``` +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) +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 +the **Builds** page and the builds are marked as `triggered`. + +![Marked rebuilds as triggered on builds page](img/builds_page.png) + +--- + +You can see which trigger caused the rebuild by visiting the single build page. +The token of the trigger is exposed in the UI as you can see from the image +below. + +![Marked rebuilds as triggered on a single build page](img/trigger_single_build.png) + +--- + +See the [Examples](#examples) section for more details on how to actually +trigger a rebuild. + +## Pass build variables to a trigger + +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: + +``` +variables[key]=value +``` + +This information is also exposed in the UI. + +![Build variables in UI](img/trigger_variables.png) + +--- + +See the [Examples](#examples) section below for more details. + +## Examples + +Using cURL you can trigger a rebuild with minimal effort, for example: + +```bash +curl -X POST \ + -F token=TOKEN \ + -F ref=master \ + https://gitlab.com/api/v3/projects/9/trigger/builds +``` + +In this case, the project with ID `9` will get rebuilt on `master` branch. + +You can also use triggers in your `.gitlab-ci.yml`. Let's say that you have +two projects, A and B, and you want to trigger a rebuild on the `master` +branch of project B whenever a tag on project A is created. + +```yaml +build_docs: + stage: deploy + script: + - "curl -X POST -F token=TOKEN -F ref=master https://gitlab.com/api/v3/projects/9/trigger/builds" + only: + - tags +``` [ci-229]: https://gitlab.com/gitlab-org/gitlab-ci/merge_requests/229 diff --git a/doc/ci/triggers/img/builds_page.png b/doc/ci/triggers/img/builds_page.png new file mode 100644 index 00000000000..e78794fbee7 Binary files /dev/null and b/doc/ci/triggers/img/builds_page.png differ diff --git a/doc/ci/triggers/img/trigger_single_build.png b/doc/ci/triggers/img/trigger_single_build.png new file mode 100644 index 00000000000..c25f27409d6 Binary files /dev/null and b/doc/ci/triggers/img/trigger_single_build.png differ diff --git a/doc/ci/triggers/img/trigger_variables.png b/doc/ci/triggers/img/trigger_variables.png new file mode 100644 index 00000000000..2207e8b34cb Binary files /dev/null and b/doc/ci/triggers/img/trigger_variables.png differ diff --git a/doc/ci/triggers/img/triggers_page.png b/doc/ci/triggers/img/triggers_page.png new file mode 100644 index 00000000000..268368dc3c5 Binary files /dev/null and b/doc/ci/triggers/img/triggers_page.png differ -- cgit v1.2.1 From 662e9cffe1dc278bad06c8b44c527cac1d0e913d Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Fri, 25 Dec 2015 13:37:46 +0200 Subject: Add examples for triggers [ci skip] --- doc/ci/triggers/README.md | 81 ++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 76 insertions(+), 5 deletions(-) (limited to 'doc') diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md index 63661ee4858..2c1de5859f8 100644 --- a/doc/ci/triggers/README.md +++ b/doc/ci/triggers/README.md @@ -83,22 +83,93 @@ Using cURL you can trigger a rebuild with minimal effort, for example: curl -X POST \ -F token=TOKEN \ -F ref=master \ - https://gitlab.com/api/v3/projects/9/trigger/builds + https://gitlab.example.com/api/v3/projects/9/trigger/builds ``` In this case, the project with ID `9` will get rebuilt on `master` branch. -You can also use triggers in your `.gitlab-ci.yml`. Let's say that you have -two projects, A and B, and you want to trigger a rebuild on the `master` -branch of project B whenever a tag on project A is created. + +### Triggering a build within `.gitlab-ci.yml` + +You can also benefit by using triggers in your `.gitlab-ci.yml`. Let's say that +you have two projects, A and B, and you want to trigger a rebuild on the `master` +branch of project B whenever a tag on project A is created. This is the job you +need to add in project's A `.gitlab-ci.yml`: ```yaml build_docs: stage: deploy script: - - "curl -X POST -F token=TOKEN -F ref=master https://gitlab.com/api/v3/projects/9/trigger/builds" + - "curl -X POST -F token=TOKEN -F ref=master https://gitlab.example.com/api/v3/projects/9/trigger/builds" only: - tags ``` +Now, whenever a new tag is pushed on project A, the build will run and the +`build_docs` job will be executed, triggering a rebuild of project B. The +`stage: deploy` ensures that this job will run only after all jobs with +`stage: test` complete successfully. + +_**Note:** If your project is public, passing the token in plain text is +probably not the wiser idea, so you might want to use a +[secure variable](../variables/README.md#user-defined-variables-secure-variables) +for that purpose._ + +### Making use of trigger variables + +Using trigger variables can be proven useful for a variety of reasons. + +* Identifiable jobs. Since the variable is exposed in the UI you can know + why the rebuild was triggered if you pass a variable that explains the + purpose. +* Conditional job processing. You can have conditional jobs that run whenever + a certain variable is present. + +Consider the following `.gitlab-ci.yml` where we set three +[stages](../yaml/README.md#stages) and the `upload_package` job is run only +when all jobs from the test and build stages pass. When the `UPLOAD_TO_S3` +variable is non-zero, `make upload` is run. + +```yaml +stages: +- test +- build +- package + +run_tests: + script: + - make test + +build_package: + stage: build + script: + - make build + +upload_package: + stage: package + script: + - if [ -n "${UPLOAD_TO_S3}" ]; then make upload; fi +``` + +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 +curl -X POST \ + -F token=TOKEN \ + -F ref=master \ + -F "variables[UPLOAD_TO_S3]=true" \ + https://gitlab.example.com/api/v3/projects/9/trigger/builds +``` + +### Using cron to trigger nightly builds + +Whether you craft a script or just run cURL directly, you can trigger builds +in conjunction with cron. The example below triggers a build on the `master` +branch of project with ID `9` every night at `00:30`: + +```bash +30 0 * * * curl -X POST -F token=TOKEN -F ref=master https://gitlab.example.com/api/v3/projects/9/trigger/builds +``` + [ci-229]: https://gitlab.com/gitlab-org/gitlab-ci/merge_requests/229 -- cgit v1.2.1 From e081edc1c474dec558f54983f0d0dc8c5841eaf6 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Fri, 25 Dec 2015 15:23:06 +0200 Subject: Clean up CRIME security doc [ci skip] --- doc/security/crime_vulnerability.md | 78 +++++++++++++++++++------------------ 1 file changed, 41 insertions(+), 37 deletions(-) (limited to 'doc') diff --git a/doc/security/crime_vulnerability.md b/doc/security/crime_vulnerability.md index d716bff85a5..94ba5d1375d 100644 --- a/doc/security/crime_vulnerability.md +++ b/doc/security/crime_vulnerability.md @@ -1,59 +1,63 @@ # How we manage the TLS protocol CRIME vulnerability -> CRIME ("Compression Ratio Info-leak Made Easy") is a security exploit against -secret web cookies over connections using the HTTPS and SPDY protocols that also -use data compression.[1][2] When used to recover the content of secret -authentication cookies, it allows an attacker to perform session hijacking on an +> CRIME ("Compression Ratio Info-leak Made Easy") is a security exploit against +secret web cookies over connections using the HTTPS and SPDY protocols that also +use data compression. When used to recover the content of secret +authentication cookies, it allows an attacker to perform session hijacking on an authenticated web session, allowing the launching of further attacks. ([CRIME](https://en.wikipedia.org/w/index.php?title=CRIME&oldid=692423806)) ### Description -The TLS Protocol CRIME Vulnerability affects compression over HTTPS therefore -it warns against using SSL Compression, take gzip for example, or SPDY which -optionally uses compression as well. +The TLS Protocol CRIME Vulnerability affects compression over HTTPS, therefore +it warns against using SSL Compression (for example gzip) or SPDY which +optionally uses compression as well. -GitLab support both gzip and SPDY and manages the CRIME vulnerability by -deactivating gzip when https is enabled and not activating the compression -feature on SDPY. +GitLab supports both gzip and [SPDY][ngx-spdy] and mitigates the CRIME +vulnerability by deactivating gzip when HTTPS is enabled. You can see the +sources of the files in question: -Take a look at our configuration file for NGINX if you'd like to explore how the -conditions are setup for gzip deactivation on this link: -[GitLab NGINX File](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/nginx-gitlab-http.conf.erb). - -For SPDY you can also watch how its implmented on NGINX at [GitLab NGINX File](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/nginx-gitlab-http.conf.erb) -but take into consideration the NGINX documentation on its default state here: -[Module ngx_http_spdy_module](http://nginx.org/en/docs/http/ngx_http_spdy_module.html). +* [Source installation NGINX file][source-nginx] +* [Omnibus installation NGINX file][omnibus-nginx] +Although SPDY is enabled in Omnibus installations, CRIME relies on compression +(the 'C') and the default compression level in NGINX's SPDY module is 0 +(no compression). ### Nessus -The Nessus scanner reports a possible CRIME vunerability for GitLab similar to the -following format: - - Description +The Nessus scanner, [reports a possible CRIME vulnerability][nessus] in GitLab +similar to the following format: - This remote service has one of two configurations that are known to be required for the CRIME attack: - SSL/TLS compression is enabled. - TLS advertises the SPDY protocol earlier than version 4. +``` +Description - ... +This remote service has one of two configurations that are known to be required for the CRIME attack: +SSL/TLS compression is enabled. +TLS advertises the SPDY protocol earlier than version 4. - Output +... - The following configuration indicates that the remote service may be vulnerable to the CRIME attack: - SPDY support earlier than version 4 is advertised. +Output -*[This](http://www.tenable.com/plugins/index.php?view=single&id=62565) is a complete description from Nessus.* +The following configuration indicates that the remote service may be vulnerable to the CRIME attack: +SPDY support earlier than version 4 is advertised. +``` -From the report above its important to note that Nessus is only checkng if TLS -advertises the SPDY protocol earlier than version 4, it does not perform an -attack nor does it check if compression is enabled. With just this approach it +From the report above it is important to note that Nessus is only checking if +TLS advertises the SPDY protocol earlier than version 4, it does not perform an +attack nor does it check if compression is enabled. With just this approach, it cannot tell that SPDY's compression is disabled and not subject to the CRIME -vulnerbility. +vulnerability. + +### References +* Nginx ["Module ngx_http_spdy_module"][ngx-spdy] +* Tenable Network Security, Inc. ["Transport Layer Security (TLS) Protocol CRIME Vulnerability"][nessus] +* Wikipedia contributors, ["CRIME"][wiki-crime] Wikipedia, The Free Encyclopedia -### Reference -* Nginx. "Module ngx_http_spdy_module", Fri. 18 Dec. -* Tenable Network Security, Inc. "Transport Layer Security (TLS) Protocol CRIME Vulnerability", Web. 15 Dec. -* Wikipedia contributors. "CRIME." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 25 Nov. 2015. Web. 15 Dec. 2015. \ No newline at end of file +[source-nginx]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/support/nginx/gitlab-ssl +[omnibus-nginx]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/nginx-gitlab-http.conf.erb +[ngx-spdy]: http://nginx.org/en/docs/http/ngx_http_spdy_module.html +[nessus]: https://www.tenable.com/plugins/index.php?view=single&id=62565 +[wiki-crime]: https://en.wikipedia.org/wiki/CRIME -- cgit v1.2.1 From f0d46b4de6acce7d09deda5449972ebb238591cb Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Sat, 26 Dec 2015 13:50:47 +0200 Subject: Remove incomplete text [ci skip] --- doc/ci/triggers/README.md | 3 --- 1 file changed, 3 deletions(-) (limited to 'doc') diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md index 2c1de5859f8..d41aed2eb2e 100644 --- a/doc/ci/triggers/README.md +++ b/doc/ci/triggers/README.md @@ -11,9 +11,6 @@ You can add a new trigger by going to your project's **Settings > Triggers**. The **Add trigger** button will create a new token which you can then use to trigger a rebuild of this particular project. -Once at least one trigger is created, on the **Triggers** page you will find -some descriptive information on how you can - Every new trigger you create, gets assigned a different token which you can then use inside your scripts or `.gitlab-ci.yml`. You also have a nice overview of the time the triggers were last used. -- cgit v1.2.1 From 8eed3ab35953a4d142fbb8e14fdaba3cdb9d3a29 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Sat, 26 Dec 2015 13:56:33 +0200 Subject: Fix typo on triggers docs [ci skip] --- doc/ci/triggers/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md index d41aed2eb2e..9f7c1bfe6a0 100644 --- a/doc/ci/triggers/README.md +++ b/doc/ci/triggers/README.md @@ -108,7 +108,7 @@ Now, whenever a new tag is pushed on project A, the build will run and the `stage: test` complete successfully. _**Note:** If your project is public, passing the token in plain text is -probably not the wiser idea, so you might want to use a +probably not the wisest idea, so you might want to use a [secure variable](../variables/README.md#user-defined-variables-secure-variables) for that purpose._ -- cgit v1.2.1 From 4ebd447a056ad3af624814ac3094ce132d38b1e9 Mon Sep 17 00:00:00 2001 From: Sytse Sijbrandij Date: Sun, 27 Dec 2015 17:36:08 +0100 Subject: Use environment variables to configure GitLab. --- doc/README.md | 1 + 1 file changed, 1 insertion(+) (limited to 'doc') diff --git a/doc/README.md b/doc/README.md index f40a257b42f..d82ff8b908b 100644 --- a/doc/README.md +++ b/doc/README.md @@ -56,6 +56,7 @@ - [Issue closing](customization/issue_closing.md) Customize how to close an issue from commit messages. - [Libravatar](customization/libravatar.md) Use Libravatar for user avatars. - [Log system](logs/logs.md) Log system. +- [Environmental Variables](administration/environmental_variables.md) to configure GitLab. - [Operations](operations/README.md) Keeping GitLab up and running - [Raketasks](raketasks/README.md) Backups, maintenance, automatic web hook setup and the importing of projects. - [Security](security/README.md) Learn what you can do to further secure your GitLab instance. -- cgit v1.2.1 From fe2f1b44813116ed1e1cafef293460ae8a4cf11a Mon Sep 17 00:00:00 2001 From: Sytse Sijbrandij Date: Sun, 27 Dec 2015 17:36:50 +0100 Subject: Add documentation and example file for environent variables. --- doc/administration/enviroment_variables.md | 45 ++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 doc/administration/enviroment_variables.md (limited to 'doc') diff --git a/doc/administration/enviroment_variables.md b/doc/administration/enviroment_variables.md new file mode 100644 index 00000000000..8c9e2fd03ad --- /dev/null +++ b/doc/administration/enviroment_variables.md @@ -0,0 +1,45 @@ +# Environment Variables + +## Introduction + +Commonly people configure GitLab via the gitlab.rb configuration file in the Omnibus package. + +But if you prefer to use environment variables we allow that too. + +## Supported environment variables + +Variable | Type | Explanation +--- | --- | --- +GITLAB_ROOT_PASSWORD | string | sets the password for the `root` user on installation +GITLAB_HOST | url | hostname of the GitLab server includes http or https +RAILS_ENV | production/development/staging/test | Rails environment +DATABASE_URL | url | For example: postgresql://localhost/blog_development?pool=5 + +## Complete database variables + +As explained in the [Heroku documentation](https://devcenter.heroku.com/articles/rails-database-connection-behavior) the DATABASE_URL doesn't let you set: + +- adapter +- database +- username +- password +- host +- port + +To do set these please `cp config/database.yml.rb config/database.yml` and use the following variables: + +Variable | Default +--- | --- +GITLAB_DATABASE_ADAPTER | postgresql +GITLAB_DATABASE_ENCODING | unicode +GITLAB_DATABASE_DATABASE | gitlab_#{ENV['RAILS_ENV'] +GITLAB_DATABASE_POOL | 10 +GITLAB_DATABASE_USERNAME | root +GITLAB_DATABASE_PASSWORD | +GITLAB_DATABASE_HOST | localhost +GITLAB_DATABASE_PORT | 5432 + +## Other variables + +We welcome merge requests to make more settings configurable via variables. +Please stick to the naming scheme "GITLAB_#{name 1_settings.rb in upper case}". -- cgit v1.2.1 From 9e0f532f3eca474bbb4bdf49ea744afb23178b82 Mon Sep 17 00:00:00 2001 From: Stan Hu Date: Sun, 27 Dec 2015 20:36:33 -0800 Subject: Add documentation for using reCAPTCHA --- doc/integration/README.md | 1 + doc/integration/recaptcha.md | 56 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+) create mode 100644 doc/integration/recaptcha.md (limited to 'doc') diff --git a/doc/integration/README.md b/doc/integration/README.md index 6263353851f..2a9f76533b7 100644 --- a/doc/integration/README.md +++ b/doc/integration/README.md @@ -13,6 +13,7 @@ See the documentation below for details on how to configure these services. - [Slack](slack.md) Integrate with the Slack chat service - [OAuth2 provider](oauth_provider.md) OAuth2 application creation - [Gmail actions buttons](gmail_action_buttons_for_gitlab.md) Adds GitLab actions to messages +- [reCAPTCHA](recaptcha.md) Configure GitLab to use Google reCAPTCHA for new users GitLab Enterprise Edition contains [advanced JIRA support](http://doc.gitlab.com/ee/integration/jira.html) and [advanced Jenkins support](http://doc.gitlab.com/ee/integration/jenkins.html). diff --git a/doc/integration/recaptcha.md b/doc/integration/recaptcha.md new file mode 100644 index 00000000000..7e6f7e7e30a --- /dev/null +++ b/doc/integration/recaptcha.md @@ -0,0 +1,56 @@ +# reCAPTCHA + +GitLab leverages [Google's reCAPTCHA](https://www.google.com/recaptcha/intro/index.html) +to protect against spam and abuse. GitLab displays the CAPTCHA form on the sign-up page +to confirm that a real user, not a bot, is attempting to create an account. + +## Configuration + +To use reCAPTCHA, first you must create a public and private key. + +1. Go to the URL: https://www.google.com/recaptcha/admin + +1. Fill out the form necessary to obtain reCAPTCHA keys. + +1. On your GitLab server, open the configuration file. + + For omnibus package: + + ```sh + sudo editor /etc/gitlab/gitlab.rb + ``` + + For installations from source: + + ```sh + cd /home/git/gitlab + + sudo -u git -H editor config/gitlab.yml + ``` + +1. Enable reCAPTCHA and add the settings: + + For omnibus package: + + ```ruby + gitlab_rails['recaptcha_enabled'] = true + gitlab_rails['recaptcha_public_key'] = 'YOUR_PUBLIC_KEY' + gitlab_rails['recaptcha_private_key'] = 'YOUR_PUBLIC_KEY' + ``` + + For installation from source: + + ``` + recaptcha: + enabled: true + public_key: 'YOUR_PUBLIC_KEY' + private_key: 'YOUR_PRIVATE_KEY' + ``` + +1. Change 'YOUR_PUBLIC_KEY' to the public key from step 2. + +1. Change 'YOUR_PRIVATE_KEY' to the private key from step 2. + +1. Save the configuration file. + +1. Restart GitLab. -- cgit v1.2.1 From 61fba0f4cca1348978efd510ebb57ad55d991fdd Mon Sep 17 00:00:00 2001 From: Sytse Sijbrandij Date: Mon, 28 Dec 2015 09:37:59 +0100 Subject: Thanks Robert for the corrections in the environment variables docs. --- doc/administration/enviroment_variables.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/administration/enviroment_variables.md b/doc/administration/enviroment_variables.md index 8c9e2fd03ad..d7f5cb7c21f 100644 --- a/doc/administration/enviroment_variables.md +++ b/doc/administration/enviroment_variables.md @@ -26,7 +26,7 @@ As explained in the [Heroku documentation](https://devcenter.heroku.com/articles - host - port -To do set these please `cp config/database.yml.rb config/database.yml` and use the following variables: +To do so please `cp config/database.yml.env config/database.yml` and use the following variables: Variable | Default --- | --- -- cgit v1.2.1 From 83d42c1518274dc0af0f49fda3a10e846569cbcc Mon Sep 17 00:00:00 2001 From: Valery Sizov Date: Fri, 25 Dec 2015 18:13:55 +0200 Subject: Revert upvotes and downvotes params to MR API --- doc/api/merge_requests.md | 17 +++++------------ doc/api/notes.md | 3 +-- 2 files changed, 6 insertions(+), 14 deletions(-) (limited to 'doc') diff --git a/doc/api/merge_requests.md b/doc/api/merge_requests.md index 366a1f8abec..8bc0a67067a 100644 --- a/doc/api/merge_requests.md +++ b/doc/api/merge_requests.md @@ -4,8 +4,7 @@ Get all merge requests for this project. The `state` parameter can be used to get only merge requests with a given state (`opened`, `closed`, or `merged`) or all of them (`all`). -The pagination parameters `page` and `per_page` can be used to restrict the list of merge requests. With GitLab 8.2 the return fields `upvotes` and -`downvotes` are deprecated and always return `0`. +The pagination parameters `page` and `per_page` can be used to restrict the list of merge requests. ``` GET /projects/:id/merge_requests @@ -58,7 +57,7 @@ Parameters: ## Get single MR -Shows information about a single merge request. With GitLab 8.2 the return fields `upvotes` and `downvotes` are deprecated and always return `0`. +Shows information about a single merge request. ``` GET /projects/:id/merge_request/:merge_request_id @@ -141,8 +140,6 @@ Parameters: ## Get single MR changes Shows information about the merge request including its files and changes. -With GitLab 8.2 the return fields `upvotes` and `downvotes` are deprecated and -always return `0`. ``` GET /projects/:id/merge_request/:merge_request_id/changes @@ -213,9 +210,7 @@ Parameters: ## Create MR -Creates a new merge request. With GitLab 8.2 the return fields `upvotes` and ` -downvotes` are deprecated and always return `0`. - +Creates a new merge request. ``` POST /projects/:id/merge_requests ``` @@ -266,8 +261,7 @@ If an error occurs, an error number and a message explaining the reason is retur ## Update MR -Updates an existing merge request. You can change the target branch, title, or even close the MR. With GitLab 8.2 the return fields `upvotes` and `downvotes` -are deprecated and always return `0`. +Updates an existing merge request. You can change the target branch, title, or even close the MR. ``` PUT /projects/:id/merge_request/:merge_request_id @@ -318,8 +312,7 @@ If an error occurs, an error number and a message explaining the reason is retur ## Accept MR -Merge changes submitted with MR using this API. With GitLab 8.2 the return -fields `upvotes` and `downvotes` are deprecated and always return `0`. +Merge changes submitted with MR using this API. If merge success you get `200 OK`. diff --git a/doc/api/notes.md b/doc/api/notes.md index 4d7ef288df8..d4d63e825ab 100644 --- a/doc/api/notes.md +++ b/doc/api/notes.md @@ -6,8 +6,7 @@ Notes are comments on snippets, issues or merge requests. ### List project issue notes -Gets a list of all notes for a single issue. With GitLab 8.2 the return fields -`upvote` and `downvote` are deprecated and always return `false`. +Gets a list of all notes for a single issue. ``` GET /projects/:id/issues/:issue_id/notes -- cgit v1.2.1 From a3469d914aaf28a1184247cbe72e5197ce7ca006 Mon Sep 17 00:00:00 2001 From: Gabriel Mazetto Date: Mon, 28 Dec 2015 18:21:34 -0200 Subject: reCAPTCHA is configurable through Admin Settings, no reload needed. --- doc/integration/recaptcha.md | 47 +++++++------------------------------------- 1 file changed, 7 insertions(+), 40 deletions(-) (limited to 'doc') diff --git a/doc/integration/recaptcha.md b/doc/integration/recaptcha.md index 7e6f7e7e30a..a301d1a613c 100644 --- a/doc/integration/recaptcha.md +++ b/doc/integration/recaptcha.md @@ -6,51 +6,18 @@ to confirm that a real user, not a bot, is attempting to create an account. ## Configuration -To use reCAPTCHA, first you must create a public and private key. +To use reCAPTCHA, first you must create a site and private key. 1. Go to the URL: https://www.google.com/recaptcha/admin -1. Fill out the form necessary to obtain reCAPTCHA keys. +2. Fill out the form necessary to obtain reCAPTCHA keys. -1. On your GitLab server, open the configuration file. +3. Login to your GitLab server, with administrator credentials. - For omnibus package: +4. Go to Applications Settings on Admin Area (`admin/application_settings`) - ```sh - sudo editor /etc/gitlab/gitlab.rb - ``` +5. Fill all recaptcha fields with keys from previous steps - For installations from source: +6. Check the `Enable reCAPTCHA` checkbox - ```sh - cd /home/git/gitlab - - sudo -u git -H editor config/gitlab.yml - ``` - -1. Enable reCAPTCHA and add the settings: - - For omnibus package: - - ```ruby - gitlab_rails['recaptcha_enabled'] = true - gitlab_rails['recaptcha_public_key'] = 'YOUR_PUBLIC_KEY' - gitlab_rails['recaptcha_private_key'] = 'YOUR_PUBLIC_KEY' - ``` - - For installation from source: - - ``` - recaptcha: - enabled: true - public_key: 'YOUR_PUBLIC_KEY' - private_key: 'YOUR_PRIVATE_KEY' - ``` - -1. Change 'YOUR_PUBLIC_KEY' to the public key from step 2. - -1. Change 'YOUR_PRIVATE_KEY' to the private key from step 2. - -1. Save the configuration file. - -1. Restart GitLab. +7. Save the configuration. -- cgit v1.2.1 From c5c6a945f29921b969663aa3e79e09148145e60c Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Mon, 28 Dec 2015 23:06:40 +0200 Subject: Fix broken link in permissions page [ci skip] --- doc/permissions/permissions.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'doc') diff --git a/doc/permissions/permissions.md b/doc/permissions/permissions.md index bcd00cfc6bf..1be78ac1823 100644 --- a/doc/permissions/permissions.md +++ b/doc/permissions/permissions.md @@ -6,11 +6,11 @@ If a user is both in a project group and in the project itself, the highest perm If a user is a GitLab administrator they receive all permissions. -On public projects the Guest role is not enforced. -All users will be able to create issues, leave comments, and pull or download the project code. +On public projects the Guest role is not enforced. +All users will be able to create issues, leave comments, and pull or download the project code. To add or import a user, you can follow the [project users and members -documentation](doc/workflow/add-user/add-user.md). +documentation](../workflow/add-user/add-user.md). ## Project -- cgit v1.2.1 From 82bfa8f40c9ee7d292e8c4f8543cca27ca2c3c25 Mon Sep 17 00:00:00 2001 From: Gabriel Mazetto Date: Wed, 30 Dec 2015 12:45:24 -0200 Subject: Added additional config environmental variables to help Debian packaging * GITLAB_EMAIL_FROM * GITLAB_EMAIL_DISPLAY_NAME * GITLAB_EMAIL_REPLY_TO --- doc/README.md | 2 +- doc/administration/enviroment_variables.md | 7 +++++-- 2 files changed, 6 insertions(+), 3 deletions(-) (limited to 'doc') diff --git a/doc/README.md b/doc/README.md index d82ff8b908b..8a297f8267f 100644 --- a/doc/README.md +++ b/doc/README.md @@ -56,7 +56,7 @@ - [Issue closing](customization/issue_closing.md) Customize how to close an issue from commit messages. - [Libravatar](customization/libravatar.md) Use Libravatar for user avatars. - [Log system](logs/logs.md) Log system. -- [Environmental Variables](administration/environmental_variables.md) to configure GitLab. +- [Environmental Variables](administration/environment_variables.md) to configure GitLab. - [Operations](operations/README.md) Keeping GitLab up and running - [Raketasks](raketasks/README.md) Backups, maintenance, automatic web hook setup and the importing of projects. - [Security](security/README.md) Learn what you can do to further secure your GitLab instance. diff --git a/doc/administration/enviroment_variables.md b/doc/administration/enviroment_variables.md index d7f5cb7c21f..7d8f9d29eef 100644 --- a/doc/administration/enviroment_variables.md +++ b/doc/administration/enviroment_variables.md @@ -9,11 +9,14 @@ But if you prefer to use environment variables we allow that too. ## Supported environment variables Variable | Type | Explanation ---- | --- | --- +-------- | ---- | ----------- GITLAB_ROOT_PASSWORD | string | sets the password for the `root` user on installation GITLAB_HOST | url | hostname of the GitLab server includes http or https -RAILS_ENV | production/development/staging/test | Rails environment +RAILS_ENV | production / development / staging / test | Rails environment DATABASE_URL | url | For example: postgresql://localhost/blog_development?pool=5 +GITLAB_EMAIL_FROM | email | Email address used in the "From" field in mails sent by GitLab +GITLAB_EMAIL_DISPLAY_NAME | string | Name used in the "From" field in mails sent by GitLab +GITLAB_EMAIL_REPLY_TO | email | Email address used in the "Reply-To" field in mails sent by GitLab ## Complete database variables -- cgit v1.2.1