diff options
Diffstat (limited to 'doc/workflow')
| -rw-r--r-- | doc/workflow/README.md | 16 | ||||
| -rw-r--r-- | doc/workflow/file_finder.md | 4 | ||||
| -rw-r--r-- | doc/workflow/forking_workflow.md | 34 | ||||
| -rw-r--r-- | doc/workflow/git_annex.md | 30 | ||||
| -rw-r--r-- | doc/workflow/gitlab_flow.md | 37 | ||||
| -rw-r--r-- | doc/workflow/img/ci_mr.png (renamed from doc/workflow/ci_mr.png) | bin | 12024 -> 12024 bytes | |||
| -rw-r--r-- | doc/workflow/img/close_issue_mr.png (renamed from doc/workflow/close_issue_mr.png) | bin | 42108 -> 42108 bytes | |||
| -rw-r--r-- | doc/workflow/img/environment_branches.png (renamed from doc/workflow/environment_branches.png) | bin | 12354 -> 12354 bytes | |||
| -rw-r--r-- | doc/workflow/img/four_stages.png (renamed from doc/workflow/four_stages.png) | bin | 7124 -> 7124 bytes | |||
| -rw-r--r-- | doc/workflow/img/git_pull.png (renamed from doc/workflow/git_pull.png) | bin | 28701 -> 28701 bytes | |||
| -rw-r--r-- | doc/workflow/img/gitdashflow.png (renamed from doc/workflow/gitdashflow.png) | bin | 68177 -> 68177 bytes | |||
| -rw-r--r-- | doc/workflow/img/github_flow.png (renamed from doc/workflow/github_flow.png) | bin | 6173 -> 6173 bytes | |||
| -rw-r--r-- | doc/workflow/img/gitlab_flow.png (renamed from doc/workflow/gitlab_flow.png) | bin | 47430 -> 47430 bytes | |||
| -rw-r--r-- | doc/workflow/img/good_commit.png (renamed from doc/workflow/good_commit.png) | bin | 8740 -> 8740 bytes | |||
| -rw-r--r-- | doc/workflow/img/merge_commits.png (renamed from doc/workflow/merge_commits.png) | bin | 7564 -> 7564 bytes | |||
| -rw-r--r-- | doc/workflow/img/merge_request.png (renamed from doc/workflow/merge_request.png) | bin | 47225 -> 47225 bytes | |||
| -rw-r--r-- | doc/workflow/img/messy_flow.png (renamed from doc/workflow/messy_flow.png) | bin | 11663 -> 11663 bytes | |||
| -rw-r--r-- | doc/workflow/img/mr_inline_comments.png (renamed from doc/workflow/mr_inline_comments.png) | bin | 52503 -> 52503 bytes | |||
| -rw-r--r-- | doc/workflow/img/notification_global_settings.png | bin | 118914 -> 67652 bytes | |||
| -rw-r--r-- | doc/workflow/img/production_branch.png (renamed from doc/workflow/production_branch.png) | bin | 7262 -> 7262 bytes | |||
| -rw-r--r-- | doc/workflow/img/rebase.png (renamed from doc/workflow/rebase.png) | bin | 28939 -> 28939 bytes | |||
| -rw-r--r-- | doc/workflow/img/release_branches.png (renamed from doc/workflow/release_branches.png) | bin | 12736 -> 12736 bytes | |||
| -rw-r--r-- | doc/workflow/img/remove_checkbox.png (renamed from doc/workflow/remove_checkbox.png) | bin | 6904 -> 6904 bytes | |||
| -rw-r--r-- | doc/workflow/issue_weight.md | 4 | ||||
| -rw-r--r-- | doc/workflow/lfs/lfs_administration.md | 102 | ||||
| -rw-r--r-- | doc/workflow/lfs/manage_large_binaries_with_git_lfs.md | 33 | ||||
| -rw-r--r-- | doc/workflow/lfs/migrate_from_git_annex_to_git_lfs.md | 147 | ||||
| -rw-r--r-- | doc/workflow/notifications.md | 46 | ||||
| -rw-r--r-- | doc/workflow/repository_mirroring.md | 76 | ||||
| -rw-r--r-- | doc/workflow/shortcuts.md | 14 | ||||
| -rw-r--r-- | doc/workflow/time_tracking.md | 17 | ||||
| -rw-r--r-- | doc/workflow/timezone.md | 8 | ||||
| -rw-r--r-- | doc/workflow/todos.md | 140 | ||||
| -rw-r--r-- | doc/workflow/workflow.md | 38 |
34 files changed, 389 insertions, 357 deletions
diff --git a/doc/workflow/README.md b/doc/workflow/README.md index 40e2486ace5..c6396672e59 100644 --- a/doc/workflow/README.md +++ b/doc/workflow/README.md @@ -4,7 +4,7 @@ comments: false # Workflow -- [Automatic issue closing](../user/project/issues/automatic_issue_closing.md) +- [Automatic issue closing](../user/project/issues/managing_issues.md#closing-issues-automatically) - [Change your time zone](timezone.md) - [Cycle Analytics](../user/project/cycle_analytics.md) - [Description templates](../user/project/description_templates.md) @@ -13,15 +13,15 @@ comments: false - [Groups](../user/group/index.md) - Issues - The GitLab Issue Tracker is an advanced and complete tool for tracking the evolution of a new idea or the process of solving a problem. - - [Exporting Issues](../user/project/issues/csv_export.md) **[STARTER]** Export issues as a CSV, emailed as an attachment. + - [Exporting Issues](../user/project/issues/csv_export.md) **(STARTER)** Export issues as a CSV, emailed as an attachment. - [Confidential issues](../user/project/issues/confidential_issues.md) - [Due date for issues](../user/project/issues/due_dates.md) - [Issue Board](../user/project/issue_board.md) - [Keyboard shortcuts](shortcuts.md) - [File finder](file_finder.md) -- [File lock](../user/project/file_lock.md) **[PREMIUM]** +- [File lock](../user/project/file_lock.md) **(PREMIUM)** - [Labels](../user/project/labels.md) -- [Issue weight](issue_weight.md) **[STARTER]** +- [Issue weight](issue_weight.md) **(STARTER)** - [Notification emails](notifications.md) - [Projects](../user/project/index.md) - [Project forking workflow](forking_workflow.md) @@ -38,15 +38,15 @@ comments: false - [Authorization for merge requests](../user/project/merge_requests/authorization_for_merge_requests.md) - [Cherry-pick changes](../user/project/merge_requests/cherry_pick_changes.md) - [Merge when pipeline succeeds](../user/project/merge_requests/merge_when_pipeline_succeeds.md) - - [Resolve discussion comments in merge requests reviews](../user/discussions/index.md) + - [Resolve threads in merge requests reviews](../user/discussions/index.md) - [Resolve merge conflicts in the UI](../user/project/merge_requests/resolve_conflicts.md) - [Revert changes in the UI](../user/project/merge_requests/revert_changes.md) - [Merge requests versions](../user/project/merge_requests/versions.md) - ["Work In Progress" merge requests](../user/project/merge_requests/work_in_progress_merge_requests.md) - [Fast-forward merge requests](../user/project/merge_requests/fast_forward_merge.md) - - [Merge request approvals](../user/project/merge_requests/merge_request_approvals.md) **[STARTER]** -- [Repository mirroring](repository_mirroring.md) **[STARTER]** -- [Service Desk](../user/project/service_desk.md) **[PREMIUM]** + - [Merge request approvals](../user/project/merge_requests/merge_request_approvals.md) **(STARTER)** +- [Repository mirroring](repository_mirroring.md) **(STARTER)** +- [Service Desk](../user/project/service_desk.md) **(PREMIUM)** - [Manage large binaries with Git LFS](lfs/manage_large_binaries_with_git_lfs.md) - [Importing from SVN, GitHub, Bitbucket, etc](importing/README.md) - [Todos](todos.md) diff --git a/doc/workflow/file_finder.md b/doc/workflow/file_finder.md index 8d87b030c83..52c83caeea8 100644 --- a/doc/workflow/file_finder.md +++ b/doc/workflow/file_finder.md @@ -2,8 +2,6 @@ > [Introduced][gh-9889] in GitLab 8.4. ---- - The file finder feature allows you to quickly shortcut your way when you are searching for a file in a repository using the GitLab UI. @@ -12,8 +10,6 @@ project.  ---- - For those who prefer to keep their fingers on the keyboard, there is a [shortcut button](shortcuts.md) as well, which you can invoke from _anywhere_ in a project. diff --git a/doc/workflow/forking_workflow.md b/doc/workflow/forking_workflow.md index 02be0ad191d..869a0a621c3 100644 --- a/doc/workflow/forking_workflow.md +++ b/doc/workflow/forking_workflow.md @@ -10,31 +10,25 @@ document more information about using branches to work together. Forking a project is in most cases a two-step process. -1. Click on the fork button located in the middle of the page or a project's - home page right next to the stars button. +1. Click on the fork button located in the middle of the page or a project's + home page right next to the stars button. -  +  - --- +1. Once you do that, you'll be presented with a screen where you can choose + the namespace to fork to. Only namespaces (groups and your own + namespace) where you have write access to, will be shown. Click on the + namespace to create your fork there. -1. Once you do that, you'll be presented with a screen where you can choose - the namespace to fork to. Only namespaces (groups and your own - namespace) where you have write access to, will be shown. Click on the - namespace to create your fork there. +  -  + **Note:** + If the namespace you chose to fork the project to has another project with + the same path name, you will be presented with a warning that the forking + could not be completed. Try to resolve the error and repeat the forking + process. - --- - - **Note:** - If the namespace you chose to fork the project to has another project with - the same path name, you will be presented with a warning that the forking - could not be completed. Try to resolve the error and repeat the forking - process. - -  - - --- +  After the forking is done, you can start working on the newly created repository. There, you will have full [Owner](../user/permissions.md) diff --git a/doc/workflow/git_annex.md b/doc/workflow/git_annex.md index 84d25951908..9543859f86f 100644 --- a/doc/workflow/git_annex.md +++ b/doc/workflow/git_annex.md @@ -54,13 +54,13 @@ sudo yum install epel-release && sudo yum install git-annex For omnibus-gitlab packages, only one configuration setting is needed. The Omnibus package will internally set the correct options in all locations. -1. In `/etc/gitlab/gitlab.rb` add the following line: +1. In `/etc/gitlab/gitlab.rb` add the following line: - ```ruby - gitlab_shell['git_annex_enabled'] = true - ``` + ```ruby + gitlab_shell['git_annex_enabled'] = true + ``` -1. Save the file and [reconfigure GitLab][] for the changes to take effect. +1. Save the file and [reconfigure GitLab][] for the changes to take effect. ### Configuration for installations from source @@ -69,20 +69,20 @@ There are 2 settings to enable git-annex on your GitLab server. One is located in `config/gitlab.yml` of the GitLab repository and the other one is located in `config.yml` of gitlab-shell. -1. In `config/gitlab.yml` add or edit the following lines: +1. In `config/gitlab.yml` add or edit the following lines: - ```yaml - gitlab_shell: - git_annex_enabled: true - ``` + ```yaml + gitlab_shell: + git_annex_enabled: true + ``` -1. In `config.yml` of gitlab-shell add or edit the following lines: +1. In `config.yml` of gitlab-shell add or edit the following lines: - ```yaml - git_annex_enabled: true - ``` + ```yaml + git_annex_enabled: true + ``` -1. Save the files and [restart GitLab][] for the changes to take effect. +1. Save the files and [restart GitLab][] for the changes to take effect. ## Using GitLab git-annex diff --git a/doc/workflow/gitlab_flow.md b/doc/workflow/gitlab_flow.md index 3e24557591c..2f365e42cc9 100644 --- a/doc/workflow/gitlab_flow.md +++ b/doc/workflow/gitlab_flow.md @@ -1,7 +1,8 @@ - # Introduction to GitLab Flow + + Git allows a wide variety of branching strategies and workflows. Because of this, many organizations end up with workflows that are too complicated, not clearly defined, or not integrated with issue tracking systems. Therefore, we propose GitLab flow as a clearly defined set of best practices. @@ -11,7 +12,7 @@ Organizations coming to Git from other version control systems frequently find i This article describes GitLab flow, which integrates the Git workflow with an issue tracking system. It offers a simple, transparent, and effective way to work with Git. - + When converting to Git, you have to get used to the fact that it takes three steps to share a commit with colleagues. Most version control systems have only one step: committing from the working copy to a shared server. @@ -19,7 +20,7 @@ In Git, you add files from the working copy to the staging area. After that, you The third step is pushing to a shared remote repository. After getting used to these three steps, the next challenge is the branching model. - + Since many organizations new to Git have no conventions for how to work with it, their repositories can quickly become messy. The biggest problem is that many long-running branches emerge that all contain part of the changes. @@ -31,7 +32,7 @@ For a video introduction of how this works in GitLab, see [GitLab Flow](https:// ## Git flow and its problems - + Git flow was one of the first proposals to use Git branches, and it has received a lot of attention. It suggests a `master` branch and a separate `develop` branch, as well as supporting branches for features, releases, and hotfixes. @@ -54,7 +55,7 @@ For example, many projects do releases but don't need to do hotfixes. ## GitHub flow as a simpler alternative - + In reaction to Git flow, GitHub created a simpler alternative. [GitHub flow](https://guides.github.com/introduction/flow/index.html) has only feature branches and a `master` branch. @@ -66,7 +67,7 @@ With GitLab flow, we offer additional guidance for these questions. ## Production branch with GitLab flow - + GitHub flow assumes you can deploy to production every time you merge a feature branch. While this is possible in some cases, such as SaaS applications, there are many cases where this is not possible. @@ -82,7 +83,7 @@ This flow prevents the overhead of releasing, tagging, and merging that happens ## Environment branches with GitLab flow - + It might be a good idea to have an environment that is automatically updated to the `master` branch. Only, in this case, the name of this environment might differ from the branch name. @@ -98,7 +99,7 @@ If this is not possible because more manual testing is required, you can send me ## Release branches with GitLab flow - + You only need to work with release branches if you need to release software to the outside world. In this case, each branch contains a minor version, for example, 2-3-stable, 2-4-stable, etc. @@ -114,7 +115,7 @@ In this flow, it is not common to have a production branch (or Git flow `master` ## Merge/pull requests with GitLab flow - + Merge or pull requests are created in a Git management application. They ask an assigned person to merge two branches. Tools such as GitHub and Bitbucket choose the name "pull request" since the first manual action is to pull the feature branch. @@ -147,11 +148,11 @@ It also ensures that if someone reopens the issue, they can use the same branch NOTE: **Note:** When you reopen an issue you need to create a new merge request. - + ## Issue tracking with GitLab flow - + GitLab flow is a way to make the relation between the code and the issue tracker more transparent. @@ -175,7 +176,7 @@ A merge request is an online place to discuss the change and review the code. If you open the merge request but do not assign it to anyone, it is a "Work In Progress" merge request. These are used to discuss the proposed implementation but are not ready for inclusion in the `master` branch yet. -Start the title of the merge request with "[WIP]" or "WIP:" to prevent it from being merged before it's ready. +Start the title of the merge request with `[WIP]` or `WIP:` to prevent it from being merged before it's ready. When you think the code is ready, assign the merge request to a reviewer. The reviewer can merge the changes when they think the code is ready for inclusion in the `master` branch. @@ -192,7 +193,7 @@ It is possible that one feature branch solves more than one issue. ## Linking and closing issues from merge requests - + Link to issues by mentioning them in commit messages or the description of a merge request, for example, "Fixes #16" or "Duck typing is preferred. See #12." GitLab then creates links to the mentioned issues and creates comments in the issues linking back to the merge request. @@ -203,7 +204,7 @@ If you have an issue that spans across multiple repositories, create an issue fo ## Squashing commits with rebase - + With Git, you can use an interactive rebase (`rebase -i`) to squash multiple commits into one or reorder them. This functionality is useful if you want to replace a couple of small commits with a single commit, or if you want to make the order more logical. @@ -229,7 +230,7 @@ Git does not allow you to merge the code again otherwise. ## Reducing merge commits in feature branches - + Having lots of merge commits can make your repository history messy. Therefore, you should try to avoid merge commits in feature branches. @@ -289,7 +290,7 @@ Sharing your work before it's complete also allows for discussion and feedback a ## How to write a good commit message - + A commit message should reflect your intention, not just the contents of the commit. It is easy to see the changes in a commit, so the commit message should explain why you made those changes. @@ -300,7 +301,7 @@ For more information about formatting commit messages, please see this excellent ## Testing before merging - + In old workflows, the continuous integration (CI) server commonly ran tests on the `master` branch only. Developers had to ensure their code did not break the `master` branch. @@ -317,7 +318,7 @@ As said before, if you often have feature branches that last for more than a few ## Working with feature branches - + When creating a feature branch, always branch from an up-to-date `master`. If you know before you start that your work depends on another branch, you can also branch from there. diff --git a/doc/workflow/ci_mr.png b/doc/workflow/img/ci_mr.png Binary files differindex 85a609cb814..85a609cb814 100644 --- a/doc/workflow/ci_mr.png +++ b/doc/workflow/img/ci_mr.png diff --git a/doc/workflow/close_issue_mr.png b/doc/workflow/img/close_issue_mr.png Binary files differindex 70de2fb6cee..70de2fb6cee 100644 --- a/doc/workflow/close_issue_mr.png +++ b/doc/workflow/img/close_issue_mr.png diff --git a/doc/workflow/environment_branches.png b/doc/workflow/img/environment_branches.png Binary files differindex 0aff33c6bb8..0aff33c6bb8 100644 --- a/doc/workflow/environment_branches.png +++ b/doc/workflow/img/environment_branches.png diff --git a/doc/workflow/four_stages.png b/doc/workflow/img/four_stages.png Binary files differindex 3ef6a33d2d4..3ef6a33d2d4 100644 --- a/doc/workflow/four_stages.png +++ b/doc/workflow/img/four_stages.png diff --git a/doc/workflow/git_pull.png b/doc/workflow/img/git_pull.png Binary files differindex 0e56e59471c..0e56e59471c 100644 --- a/doc/workflow/git_pull.png +++ b/doc/workflow/img/git_pull.png diff --git a/doc/workflow/gitdashflow.png b/doc/workflow/img/gitdashflow.png Binary files differindex 65900853d84..65900853d84 100644 --- a/doc/workflow/gitdashflow.png +++ b/doc/workflow/img/gitdashflow.png diff --git a/doc/workflow/github_flow.png b/doc/workflow/img/github_flow.png Binary files differindex 21a22becdb6..21a22becdb6 100644 --- a/doc/workflow/github_flow.png +++ b/doc/workflow/img/github_flow.png diff --git a/doc/workflow/gitlab_flow.png b/doc/workflow/img/gitlab_flow.png Binary files differindex a6f3c947843..a6f3c947843 100644 --- a/doc/workflow/gitlab_flow.png +++ b/doc/workflow/img/gitlab_flow.png diff --git a/doc/workflow/good_commit.png b/doc/workflow/img/good_commit.png Binary files differindex ceb0d4b1691..ceb0d4b1691 100644 --- a/doc/workflow/good_commit.png +++ b/doc/workflow/img/good_commit.png diff --git a/doc/workflow/merge_commits.png b/doc/workflow/img/merge_commits.png Binary files differindex 4a80811c6e3..4a80811c6e3 100644 --- a/doc/workflow/merge_commits.png +++ b/doc/workflow/img/merge_commits.png diff --git a/doc/workflow/merge_request.png b/doc/workflow/img/merge_request.png Binary files differindex 010e95983fc..010e95983fc 100644 --- a/doc/workflow/merge_request.png +++ b/doc/workflow/img/merge_request.png diff --git a/doc/workflow/messy_flow.png b/doc/workflow/img/messy_flow.png Binary files differindex 4fa22d2bb5d..4fa22d2bb5d 100644 --- a/doc/workflow/messy_flow.png +++ b/doc/workflow/img/messy_flow.png diff --git a/doc/workflow/mr_inline_comments.png b/doc/workflow/img/mr_inline_comments.png Binary files differindex a18801f56e4..a18801f56e4 100644 --- a/doc/workflow/mr_inline_comments.png +++ b/doc/workflow/img/mr_inline_comments.png diff --git a/doc/workflow/img/notification_global_settings.png b/doc/workflow/img/notification_global_settings.png Binary files differindex 72f7418f1f8..699f726c442 100644 --- a/doc/workflow/img/notification_global_settings.png +++ b/doc/workflow/img/notification_global_settings.png diff --git a/doc/workflow/production_branch.png b/doc/workflow/img/production_branch.png Binary files differindex c132d51bfb6..c132d51bfb6 100644 --- a/doc/workflow/production_branch.png +++ b/doc/workflow/img/production_branch.png diff --git a/doc/workflow/rebase.png b/doc/workflow/img/rebase.png Binary files differindex fe865177ba8..fe865177ba8 100644 --- a/doc/workflow/rebase.png +++ b/doc/workflow/img/rebase.png diff --git a/doc/workflow/release_branches.png b/doc/workflow/img/release_branches.png Binary files differindex 0a7f61d0248..0a7f61d0248 100644 --- a/doc/workflow/release_branches.png +++ b/doc/workflow/img/release_branches.png diff --git a/doc/workflow/remove_checkbox.png b/doc/workflow/img/remove_checkbox.png Binary files differindex fb0e792b37b..fb0e792b37b 100644 --- a/doc/workflow/remove_checkbox.png +++ b/doc/workflow/img/remove_checkbox.png diff --git a/doc/workflow/issue_weight.md b/doc/workflow/issue_weight.md index 267160dae2a..a80519f0748 100644 --- a/doc/workflow/issue_weight.md +++ b/doc/workflow/issue_weight.md @@ -1,4 +1,4 @@ -# Issue Weight **[STARTER]** +# Issue Weight **(STARTER)** > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/76) > in [GitLab Starter](https://about.gitlab.com/pricing/) 8.3. @@ -9,7 +9,7 @@ value or complexity a given issue has or will cost. You can set the weight of an issue during its creation, by simply changing the value in the dropdown menu. You can set it to a non-negative integer -value from 0, 1, 2, and so on. (The database stores a 4-byte value, so the +value from 0, 1, 2, and so on. (The database stores a 4-byte value, so the upper bound is essentially limitless). You can remove weight from an issue as well. diff --git a/doc/workflow/lfs/lfs_administration.md b/doc/workflow/lfs/lfs_administration.md index 6d941135bf2..7e880b3009d 100644 --- a/doc/workflow/lfs/lfs_administration.md +++ b/doc/workflow/lfs/lfs_administration.md @@ -46,15 +46,14 @@ In `config/gitlab.yml`: ## Storing LFS objects in remote object storage -> [Introduced][ee-2760] in [GitLab Premium][eep] 10.0. Brought to GitLab Core -in 10.7. +> [Introduced][ee-2760] in [GitLab Premium][eep] 10.0. Brought to GitLab Core in 10.7. It is possible to store LFS objects in remote object storage which allows you to offload local hard disk R/W operations, and free up disk space significantly. GitLab is tightly integrated with `Fog`, so you can refer to its [documentation](http://fog.io/about/provider_documentation.html) to check which storage services can be integrated with GitLab. You can also use external object storage in a private local network. For example, -[Minio](https://www.minio.io/) is a standalone object storage service, is easy to set up, and works well with GitLab instances. +[Minio](https://min.io/) is a standalone object storage service, is easy to set up, and works well with GitLab instances. GitLab provides two different options for the uploading mechanism: "Direct upload" and "Background upload". @@ -91,6 +90,7 @@ Here is a configuration example with S3. | `aws_access_key_id` | AWS credentials, or compatible | `ABC123DEF456` | | `aws_secret_access_key` | AWS credentials, or compatible | `ABC123DEF456ABC123DEF456ABC123DEF456` | | `aws_signature_version` | AWS signature version to use. 2 or 4 are valid options. Digital Ocean Spaces and other providers may need 2. | 4 | +| `enable_signature_v4_streaming` | Set to true to enable HTTP chunked transfers with [AWS v4 signatures](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-streaming.html). Oracle Cloud S3 needs this to be false | true | | `region` | AWS region | us-east-1 | | `host` | S3 compatible host for when not using AWS, e.g. `localhost` or `storage.example.com` | s3.amazonaws.com | | `endpoint` | Can be used when configuring an S3 compatible service such as [Minio](https://www.minio.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) | @@ -106,7 +106,9 @@ Here is a configuration example with GCS. | `google_client_email` | The email address of the service account | `foo@gcp-project-12345.iam.gserviceaccount.com` | | `google_json_key_location` | The json key path | `/path/to/gcp-project-12345-abcde.json` | -_NOTE: The service account must have permission to access the bucket. [See more](https://cloud.google.com/storage/docs/authentication)_ +NOTE: **Note:** +The service account must have permission to access the bucket. +[See more](https://cloud.google.com/storage/docs/authentication) Here is a configuration example with Rackspace Cloud Files. @@ -118,7 +120,13 @@ Here is a configuration example with Rackspace Cloud Files. | `rackspace_region` | The Rackspace storage region to use, a three letter code from the [list of service access endpoints](https://developer.rackspace.com/docs/cloud-files/v1/general-api-info/service-access/) | `iad` | | `rackspace_temp_url_key` | The private key you have set in the Rackspace API for temporary URLs. Read more [here](https://developer.rackspace.com/docs/cloud-files/v1/use-cases/public-access-to-your-cloud-files-account/#tempurl) | `ABC123DEF456ABC123DEF456ABC123DE` | -_NOTES: Regardless of whether the container has public access enabled or disabled, Fog will use the TempURL method to grant access to LFS objects. If you see errors in logs referencing instantiating storage with a temp-url-key, ensure that you have set they key properly on the Rackspace API and in gitlab.rb. You can verify the value of the key Rackspace has set by sending a GET request with token header to the service access endpoint URL and comparing the output of the returned headers._ +NOTE: **Note:** +Regardless of whether the container has public access enabled or disabled, Fog will +use the TempURL method to grant access to LFS objects. If you see errors in logs referencing +instantiating storage with a temp-url-key, ensure that you have set they key properly +on the Rackspace API and in gitlab.rb. You can verify the value of the key Rackspace +has set by sending a GET request with token header to the service access endpoint URL +and comparing the output of the returned headers. ### Manual uploading to an object storage @@ -148,31 +156,31 @@ On Omnibus installations, the settings are prefixed by `lfs_object_store_`: 1. Edit `/etc/gitlab/gitlab.rb` and add the following lines by replacing with the values you want: - ```ruby - gitlab_rails['lfs_object_store_enabled'] = true - gitlab_rails['lfs_object_store_remote_directory'] = "lfs-objects" - gitlab_rails['lfs_object_store_connection'] = { - 'provider' => 'AWS', - 'region' => 'eu-central-1', - 'aws_access_key_id' => '1ABCD2EFGHI34JKLM567N', - 'aws_secret_access_key' => 'abcdefhijklmnopQRSTUVwxyz0123456789ABCDE', - # The below options configure an S3 compatible host instead of AWS - 'host' => 'localhost', - 'endpoint' => 'http://127.0.0.1:9000', - 'path_style' => true - } - ``` + ```ruby + gitlab_rails['lfs_object_store_enabled'] = true + gitlab_rails['lfs_object_store_remote_directory'] = "lfs-objects" + gitlab_rails['lfs_object_store_connection'] = { + 'provider' => 'AWS', + 'region' => 'eu-central-1', + 'aws_access_key_id' => '1ABCD2EFGHI34JKLM567N', + 'aws_secret_access_key' => 'abcdefhijklmnopQRSTUVwxyz0123456789ABCDE', + # The below options configure an S3 compatible host instead of AWS + 'host' => 'localhost', + 'endpoint' => 'http://127.0.0.1:9000', + 'path_style' => true + } + ``` 1. Save the file and [reconfigure GitLab]s for the changes to take effect. 1. Migrate any existing local LFS objects to the object storage: - ```bash - gitlab-rake gitlab:lfs:migrate - ``` + ```bash + gitlab-rake gitlab:lfs:migrate + ``` - This will migrate existing LFS objects to object storage. New LFS objects - will be forwarded to object storage unless - `gitlab_rails['lfs_object_store_background_upload']` is set to false. + This will migrate existing LFS objects to object storage. New LFS objects + will be forwarded to object storage unless + `gitlab_rails['lfs_object_store_background_upload']` is set to false. ### S3 for installations from source @@ -182,33 +190,33 @@ For source installations the settings are nested under `lfs:` and then 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines: - ```yaml - lfs: - enabled: true - object_store: - enabled: false - remote_directory: lfs-objects # Bucket name - connection: - provider: AWS - aws_access_key_id: 1ABCD2EFGHI34JKLM567N - aws_secret_access_key: abcdefhijklmnopQRSTUVwxyz0123456789ABCDE - region: eu-central-1 - # Use the following options to configure an AWS compatible host such as Minio - host: 'localhost' - endpoint: 'http://127.0.0.1:9000' - path_style: true - ``` + ```yaml + lfs: + enabled: true + object_store: + enabled: false + remote_directory: lfs-objects # Bucket name + connection: + provider: AWS + aws_access_key_id: 1ABCD2EFGHI34JKLM567N + aws_secret_access_key: abcdefhijklmnopQRSTUVwxyz0123456789ABCDE + region: eu-central-1 + # Use the following options to configure an AWS compatible host such as Minio + host: 'localhost' + endpoint: 'http://127.0.0.1:9000' + path_style: true + ``` 1. Save the file and [restart GitLab][] for the changes to take effect. 1. Migrate any existing local LFS objects to the object storage: - ```bash - sudo -u git -H bundle exec rake gitlab:lfs:migrate RAILS_ENV=production - ``` + ```bash + sudo -u git -H bundle exec rake gitlab:lfs:migrate RAILS_ENV=production + ``` - This will migrate existing LFS objects to object storage. New LFS objects - will be forwarded to object storage unless `background_upload` is set to - false. + This will migrate existing LFS objects to object storage. New LFS objects + will be forwarded to object storage unless `background_upload` is set to + false. ## Storage statistics diff --git a/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md b/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md index 202f2e39975..f5593927cc2 100644 --- a/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md +++ b/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md @@ -35,9 +35,10 @@ Documentation for GitLab instance administrators is under [LFS administration do - Git LFS always assumes HTTPS so if you have GitLab server on HTTP you will have to add the URL to Git config manually (see [troubleshooting](#troubleshooting)) ->**Note**: With 8.12 GitLab added LFS support to SSH. The Git LFS communication - still goes over HTTP, but now the SSH client passes the correct credentials - to the Git LFS client, so no action is required by the user. +NOTE: **Note:** +With 8.12 GitLab added LFS support to SSH. The Git LFS communication +still goes over HTTP, but now the SSH client passes the correct credentials +to the Git LFS client, so no action is required by the user. ## Using Git LFS @@ -61,12 +62,13 @@ git commit -am "Added Debian iso" # commit the file meta data git push origin master # sync the git repo and large file to the GitLab server ``` -> **Note**: Make sure that `.gitattributes` is tracked by git. Otherwise Git -> LFS will not be working properly for people cloning the project. -> -> ```bash -> git add .gitattributes -> ``` +NOTE: **Note:** +**Make sure** that `.gitattributes` is tracked by Git. Otherwise Git +LFS will not be working properly for people cloning the project. + +```bash +git add .gitattributes +``` Cloning the repository works the same as before. Git automatically detects the LFS-tracked files and clones them via HTTP. If you performed the git clone @@ -84,6 +86,10 @@ that are on the remote repository, eg. for a branch from origin: git lfs fetch origin master ``` +### Migrate an existing repo to Git LFS + +Read the documentation on how to [migrate an existing Git repo with Git LFS](../../topics/git/migrate_to_git_lfs/index.md). + ## File Locking > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/35856) in GitLab 10.5. @@ -212,9 +218,10 @@ git config --add lfs.url "http://gitlab.example.com/group/project.git/info/lfs" ### Credentials are always required when pushing an object ->**Note**: With 8.12 GitLab added LFS support to SSH. The Git LFS communication - still goes over HTTP, but now the SSH client passes the correct credentials - to the Git LFS client, so no action is required by the user. +NOTE: **Note:** +With 8.12 GitLab added LFS support to SSH. The Git LFS communication +still goes over HTTP, but now the SSH client passes the correct credentials +to the Git LFS client, so no action is required by the user. Given that Git LFS uses HTTP Basic Authentication to authenticate the user pushing the LFS object on every push for every object, user HTTPS credentials are required. @@ -250,7 +257,7 @@ If you are storing LFS files outside of GitLab you can disable LFS on the projec It is possible to host LFS objects externally by setting a custom LFS url with `git config -f .lfsconfig lfs.url https://example.com/<project>.git/info/lfs`. -You might choose to do this if you are using an appliance like a Sonatype Nexus to store LFS data. If you choose to use an external LFS store, +You might choose to do this if you are using an appliance like a Sonatype Nexus to store LFS data. If you choose to use an external LFS store, GitLab will not be able to verify LFS objects which means that pushes will fail if you have GitLab LFS support enabled. To stop push failure, LFS support can be disabled in the [Project settings](../../user/project/settings/index.md). This means you will lose GitLab LFS value-adds (Verifying LFS objects, UI integration for LFS). diff --git a/doc/workflow/lfs/migrate_from_git_annex_to_git_lfs.md b/doc/workflow/lfs/migrate_from_git_annex_to_git_lfs.md index 71c73e3dffe..5ceeb3253f1 100644 --- a/doc/workflow/lfs/migrate_from_git_annex_to_git_lfs.md +++ b/doc/workflow/lfs/migrate_from_git_annex_to_git_lfs.md @@ -46,25 +46,24 @@ need to do (we assume you have [git-annex enabled](../git_annex.md#using-gitlab- repository and that you have made backups in case something goes wrong). Fire up a terminal, navigate to your Git repository and: - 1. Disable `git-annex`: - ```bash - git annex sync --content - git annex direct - git annex uninit - git annex indirect - ``` + ```bash + git annex sync --content + git annex direct + git annex uninit + git annex indirect + ``` 1. Enable `git-lfs`: - ``` - git lfs install - git lfs track <files> - git add . - git commit -m "commit message" - git push - ``` + ``` + git lfs install + git lfs track <files> + git add . + git commit -m "commit message" + git push + ``` ### Disabling Git Annex in your repo @@ -77,7 +76,7 @@ Here you'll find a guide on Since Annex files are stored as objects with symlinks and cannot be directly modified, we need to first remove those symlinks. ->**Note:** +NOTE: **Note:** Make sure the you read about the [`direct` mode][annex-direct] as it contains useful information that may fit in your use case. Note that `annex direct` is deprecated in Git Annex version 6, so you may need to upgrade your repository @@ -86,72 +85,72 @@ if the server also has Git Annex 6 installed. Read more in the 1. Backup your repository - ```bash - cd repository - git annex sync --content - cd .. - git clone repository repository-backup - cd repository-backup - git annex get - cd .. - ``` + ```bash + cd repository + git annex sync --content + cd .. + git clone repository repository-backup + cd repository-backup + git annex get + cd .. + ``` 1. Use `annex direct`: - ```bash - cd repository - git annex direct - ``` + ```bash + cd repository + git annex direct + ``` - The output should be similar to this: + The output should be similar to this: - ```bash - commit - On branch master - Your branch is up-to-date with 'origin/master'. - nothing to commit, working tree clean - ok - direct debian.iso ok - direct ok - ``` + ```bash + commit + On branch master + Your branch is up-to-date with 'origin/master'. + nothing to commit, working tree clean + ok + direct debian.iso ok + direct ok + ``` 1. Disable Git Annex with [`annex uninit`][uninit]: - ```bash - git annex uninit - ``` + ```bash + git annex uninit + ``` - The output should be similar to this: + The output should be similar to this: - ```bash - unannex debian.iso ok - Deleted branch git-annex (was 2534d2c). - ``` + ```bash + unannex debian.iso ok + Deleted branch git-annex (was 2534d2c). + ``` - This will `unannex` every file in the repository, leaving the original files. + This will `unannex` every file in the repository, leaving the original files. 1. Switch back to `indirect` mode: - ```bash - git annex indirect - ``` - - The output should be similar to this: + ```bash + git annex indirect + ``` - ```bash - (merging origin/git-annex into git-annex...) - (recording state in git...) - commit (recording state in git...) + The output should be similar to this: - ok - (recording state in git...) - [master fac3194] commit before switching to indirect mode - 1 file changed, 1 deletion(-) - delete mode 120000 alpine-virt-3.4.4-x86_64.iso - ok - indirect ok - ok - ``` + ```bash + (merging origin/git-annex into git-annex...) + (recording state in git...) + commit (recording state in git...) + + ok + (recording state in git...) + [master fac3194] commit before switching to indirect mode + 1 file changed, 1 deletion(-) + delete mode 120000 alpine-virt-3.4.4-x86_64.iso + ok + indirect ok + ok + ``` --- @@ -216,16 +215,16 @@ branches created by Git Annex: `git-annex`, and all under `synced/`.  -You can also do this on the commandline with: +You can also do this on the command line with: - ```bash - git branch -d synced/master - git branch -d synced/git-annex - git push origin :synced/master - git push origin :synced/git-annex - git push origin :git-annex - git remote prune origin - ``` +```bash +git branch -d synced/master +git branch -d synced/git-annex +git push origin :synced/master +git push origin :synced/git-annex +git push origin :git-annex +git remote prune origin +``` If there are still some Annex objects inside your repository (`.git/annex/`) or references inside `.git/config`, run `annex uninit` again: diff --git a/doc/workflow/notifications.md b/doc/workflow/notifications.md index 5d560f2e000..ccb8844aea3 100644 --- a/doc/workflow/notifications.md +++ b/doc/workflow/notifications.md @@ -51,6 +51,10 @@ Organization like this is suitable for users that belong to different groups but same need for being notified for every group they are member of. These settings can be configured on group page under the name of the group. It will be the dropdown with the bell icon. They can also be configured on the user profile notifications dropdown. +The group owner can disable email notifications for a group, which also includes +it's subgroups and projects. If this is the case, you will not receive any corresponding notifications, +and the notification button will be disabled with an explanatory tooltip. + ### Project Settings  @@ -60,22 +64,26 @@ other setting. This is suitable for users that have different needs for notifications per project basis. These settings can be configured on project page under the name of the project. It will be the dropdown with the bell icon. They can also be configured on the user profile notifications dropdown. +The project owner (or it's group owner) can disable email notifications for the project. +If this is the case, you will not receive any corresponding notifications, and the notification +button will be disabled with an explanatory tooltip. + ## Notification events Below is the table of events users can be notified of: -| Event | Sent to | Settings level | -|------------------------------|-------------------------------------------------------------------|------------------------------| -| New SSH key added | User | Security email, always sent. | -| New email added | User | Security email, always sent. | -| Email changed | User | Security email, always sent. | -| Password changed | User | Security email, always sent. | -| New user created | User | Sent on user creation, except for omniauth (LDAP)| -| User added to project | User | Sent when user is added to project | -| Project access level changed | User | Sent when user project access level is changed | -| User added to group | User | Sent when user is added to group | -| Group access level changed | User | Sent when user group access level is changed | -| Project moved | Project members [1] | [1] not disabled | +| Event | Sent to | Settings level | +|------------------------------|---------------------|------------------------------| +| New SSH key added | User | Security email, always sent. | +| New email added | User | Security email, always sent. | +| Email changed | User | Security email, always sent. | +| Password changed | User | Security email, always sent. | +| New user created | User | Sent on user creation, except for omniauth (LDAP)| +| User added to project | User | Sent when user is added to project | +| Project access level changed | User | Sent when user project access level is changed | +| User added to group | User | Sent when user is added to group | +| Group access level changed | User | Sent when user group access level is changed | +| Project moved | Project members (1) | (1) not disabled | ### Issue / Epics / Merge request events @@ -84,11 +92,11 @@ In most of the below cases, the notification will be sent to: - Participants: - the author and assignee of the issue/merge request - authors of comments on the issue/merge request - - anyone mentioned by `@username` in the title or description of the issue, merge request or epic **[ULTIMATE]** + - anyone mentioned by `@username` in the title or description of the issue, merge request or epic **(ULTIMATE)** - anyone with notification level "Participating" or higher that is mentioned by `@username` - in any of the comments on the issue, merge request, or epic **[ULTIMATE]** + in any of the comments on the issue, merge request, or epic **(ULTIMATE)** - Watchers: users with notification level "Watch" -- Subscribers: anyone who manually subscribed to the issue, merge request, or epic **[ULTIMATE]** +- Subscribers: anyone who manually subscribed to the issue, merge request, or epic **(ULTIMATE)** - Custom: Users with notification level "custom" who turned on notifications for any of the events present in the table below | Event | Sent to | @@ -111,9 +119,9 @@ In most of the below cases, the notification will be sent to: | New comment | The above, plus anyone mentioned by `@username` in the comment, with notification level "Mention" or higher | | Failed pipeline | The author of the pipeline | | Successful pipeline | The author of the pipeline, if they have the custom notification setting for successful pipelines set | -| New epic **[ULTIMATE]** | | -| Close epic **[ULTIMATE]** | | -| Reopen epic **[ULTIMATE]** | | +| New epic **(ULTIMATE)** | | +| Close epic **(ULTIMATE)** | | +| Reopen epic **(ULTIMATE)** | | In addition, if the title or description of an Issue or Merge Request is changed, notifications will be sent to any **new** mentions by `@username` as @@ -138,7 +146,7 @@ Notification emails include headers that provide extra content about the notific | X-GitLab-Project-Id | The ID of the project | | X-GitLab-Project-Path | The path of the project | | X-GitLab-(Resource)-ID | The ID of the resource the notification is for, where resource is `Issue`, `MergeRequest`, `Commit`, etc| -| X-GitLab-Discussion-ID | Only in comment emails, the ID of the discussion the comment is from | +| X-GitLab-Discussion-ID | Only in comment emails, the ID of the thread the comment is from | | X-GitLab-Pipeline-Id | Only in pipeline emails, the ID of the pipeline the notification is for | | X-GitLab-Reply-Key | A unique token to support reply by email | | X-GitLab-NotificationReason | The reason for being notified. "mentioned", "assigned", etc | diff --git a/doc/workflow/repository_mirroring.md b/doc/workflow/repository_mirroring.md index 9772bd385ba..753518d0424 100644 --- a/doc/workflow/repository_mirroring.md +++ b/doc/workflow/repository_mirroring.md @@ -13,7 +13,7 @@ Repository mirroring is useful when you want to use a repository outside of GitL There are two kinds of repository mirroring supported by GitLab: - Push: for mirroring a GitLab repository to another location. -- Pull: for mirroring a repository from another location to GitLab. **[STARTER]** +- Pull: for mirroring a repository from another location to GitLab. **(STARTER)** When the mirror repository is updated, all new branches, tags, and commits will be visible in the project's activity feed. @@ -30,15 +30,14 @@ The following are some possible use cases for repository mirroring: - You migrated to GitLab but still need to keep your project in another source. In that case, you can simply set it up to mirror to GitLab (pull) and all the essential history of commits, tags, - and branches will be available in your GitLab instance. **[STARTER]** + and branches will be available in your GitLab instance. **(STARTER)** - You have old projects in another source that you don't use actively anymore, but don't want to remove for archiving purposes. In that case, you can create a push mirror so that your active GitLab repository can push its changes to the old location. -## Pushing to a remote repository **[CORE]** +## Pushing to a remote repository **(CORE)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/249) in GitLab Enterprise -> Edition 8.7. [Moved to GitLab Core](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18715) in 10.8. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/249) in GitLab Enterprise Edition 8.7. [Moved to GitLab Core](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18715) in 10.8. For an existing project, you can set up push mirroring as follows: @@ -65,17 +64,16 @@ Changes pushed to files in the repository are automatically pushed to the remote In the case of a diverged branch, you will see an error indicated at the **Mirroring repositories** section. -### Push only protected branches **[CORE]** +### Push only protected branches **(CORE)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3350) in -> [GitLab Starter](https://about.gitlab.com/pricing/) 10.3. [Moved to GitLab Core](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18715) in 10.8. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3350) in [GitLab Starter](https://about.gitlab.com/pricing/) 10.3. [Moved to GitLab Core](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18715) in 10.8. You can choose to only push your protected branches from GitLab to your remote repository. To use this option, check the **Only mirror protected branches** box when creating a repository mirror. -## Setting up a push mirror from GitLab to GitHub **[CORE]** +## Setting up a push mirror from GitLab to GitHub **(CORE)** To set up a mirror from GitLab to GitHub, you need to follow these steps: @@ -92,14 +90,16 @@ The repository will push soon. To force a push, click the appropriate button. 1. On the destination GitLab instance, create a [personal access token](../user/profile/personal_access_tokens.md) with `API` scope. 1. On the source GitLab instance: - 1. Fill in the **Git repository URL** field using this format: `https://oauth2@<destination host>/<your_gitlab_group_or_name>/<your_gitlab_project>.git`. - 1. Fill in **Password** field with the GitLab personal access token created on the destination GitLab instance. - 1. Click the **Mirror repository** button. + 1. Fill in the **Git repository URL** field using this format: `https://oauth2@<destination host>/<your_gitlab_group_or_name>/<your_gitlab_project>.git`. + 1. Fill in **Password** field with the GitLab personal access token created on the destination GitLab instance. + 1. Click the **Mirror repository** button. -## Pulling from a remote repository **[STARTER]** +## Pulling from a remote repository **(STARTER)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/51) in GitLab Enterprise Edition 8.2. -> [Added Git LFS support](https://gitlab.com/gitlab-org/gitlab-ee/issues/10871) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.11. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/51) in GitLab Enterprise Edition 8.2. [Added Git LFS support](https://gitlab.com/gitlab-org/gitlab-ee/issues/10871) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.11. + +NOTE: **Note:** This feature [is available for free](https://gitlab.com/gitlab-org/gitlab-ee/issues/10361) to +GitLab.com users until September 22nd, 2019. You can set up a repository to automatically have its branches, tags, and commits updated from an upstream repository. @@ -115,9 +115,9 @@ To configure mirror pulling for an existing project: 1. Select **Pull** from the **Mirror direction** dropdown. 1. Select an authentication method from the **Authentication method** dropdown, if necessary. 1. If necessary, check the following boxes: - - **Overwrite diverged branches**. - - **Trigger pipelines for mirror updates**. - - **Only mirror protected branches**. + - **Overwrite diverged branches**. + - **Trigger pipelines for mirror updates**. + - **Only mirror protected branches**. 1. Click the **Mirror repository** button to save the configuration.  @@ -154,8 +154,7 @@ Repository mirrors are updated as Sidekiq becomes available to process them. If ### SSH authentication -> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2551) for Pull mirroring in [GitLab Starter](https://about.gitlab.com/pricing/) 9.5. -> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22982) for Push mirroring in [GitLab Core](https://about.gitlab.com/pricing/) 11.6 +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2551) for Pull mirroring in [GitLab Starter](https://about.gitlab.com/pricing/) 9.5. [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22982) for Push mirroring in [GitLab Core](https://about.gitlab.com/pricing/) 11.6 SSH authentication is mutual: @@ -240,10 +239,9 @@ If you need to change the key at any time, you can remove and re-add the mirror to generate a new key. You'll have to update the other repository with the new key to keep the mirror running. -### Overwrite diverged branches **[STARTER]** +### Overwrite diverged branches **(STARTER)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4559) in -> [GitLab Starter](https://about.gitlab.com/pricing/) 10.6. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4559) in [GitLab Starter](https://about.gitlab.com/pricing/) 10.6. You can choose to always update your local branches with remote versions, even if they have diverged from the remote. @@ -253,20 +251,18 @@ For mirrored branches, enabling this option results in the loss of local changes To use this option, check the **Overwrite diverged branches** box when creating a repository mirror. -### Only mirror protected branches **[STARTER]** +### Only mirror protected branches **(STARTER)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3326) in -> [GitLab Starter](https://about.gitlab.com/pricing/) 10.3. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3326) in [GitLab Starter](https://about.gitlab.com/pricing/) 10.3. You can choose to pull mirror only the protected branches from your remote repository to GitLab. Non-protected branches are not mirrored and can diverge. To use this option, check the **Only mirror protected branches** box when creating a repository mirror. -### Hard failure **[STARTER]** +### Hard failure **(STARTER)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3117) in -> [GitLab Starter](https://about.gitlab.com/pricing/) 10.2. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3117) in [GitLab Starter](https://about.gitlab.com/pricing/) 10.2. Once the mirroring process is unsuccessfully retried 14 times in a row, it will get marked as hard failed. This will become visible in either the: @@ -277,25 +273,24 @@ failed. This will become visible in either the: When a project is hard failed, it will no longer get picked up for mirroring. A user can resume the project mirroring again by [Forcing an update](#forcing-an-update-core). -### Trigger update using API **[STARTER]** +### Trigger update using API **(STARTER)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3453) in -[GitLab Starter](https://about.gitlab.com/pricing/) 10.3. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3453) in [GitLab Starter](https://about.gitlab.com/pricing/) 10.3. Pull mirroring uses polling to detect new branches and commits added upstream, often minutes -afterwards. If you notify GitLab by [API](https://docs.gitlab.com/ee/api/projects.html#start-the-pull-mirroring-process-for-a-project-starter), +afterwards. If you notify GitLab by [API](../api/projects.md#start-the-pull-mirroring-process-for-a-project-starter), updates will be pulled immediately. -For more information, see [Start the pull mirroring process for a Project](https://docs.gitlab.com/ee/api/projects.html#start-the-pull-mirroring-process-for-a-project-starter). +For more information, see [Start the pull mirroring process for a Project](../api/projects.md#start-the-pull-mirroring-process-for-a-project-starter). -## Forcing an update **[CORE]** +## Forcing an update **(CORE)** While mirrors are scheduled to update automatically, you can always force an update by using the update button which is available on the **Mirroring repositories** section of the **Repository Settings** page.  -## Bidirectional mirroring **[STARTER]** +## Bidirectional mirroring **(STARTER)** CAUTION: **Caution:** Bidirectional mirroring may cause conflicts. @@ -322,9 +317,10 @@ protected branches. ### Preventing conflicts using a `pre-receive` hook -> **Warning:** The solution proposed will negatively impact the performance of -> Git push operations because they will be proxied to the upstream Git -> repository. +CAUTION: **Warning:** +The solution proposed will negatively impact the performance of +Git push operations because they will be proxied to the upstream Git +repository. A server-side `pre-receive` hook can be used to prevent the race condition described above by only accepting the push after first pushing the commit to @@ -392,7 +388,7 @@ else fi ``` -### Mirroring with Perforce Helix via Git Fusion **[STARTER]** +### Mirroring with Perforce Helix via Git Fusion **(STARTER)** CAUTION: **Warning:** Bidirectional mirroring should not be used as a permanent configuration. Refer to diff --git a/doc/workflow/shortcuts.md b/doc/workflow/shortcuts.md index 5068b5d4d20..5d08bf5e77d 100644 --- a/doc/workflow/shortcuts.md +++ b/doc/workflow/shortcuts.md @@ -35,11 +35,11 @@ You can see GitLab's keyboard shortcuts by using <kbd>shift</kbd> + <kbd>?</kbd> | Keyboard Shortcut | Description | | ----------------- | ----------- | -| <kbd>g</kbd> + <kbd>a</kbd> | Go to the activity feed | -| <kbd>g</kbd> + <kbd>p</kbd> | Go to projects | -| <kbd>g</kbd> + <kbd>i</kbd> | Go to issues | -| <kbd>g</kbd> + <kbd>m</kbd> | Go to merge requests | -| <kbd>g</kbd> + <kbd>t</kbd> | Go to todos | +| <kbd>Shift</kbd> + <kbd>a</kbd> | Go to the activity feed | +| <kbd>Shift</kbd> + <kbd>p</kbd> | Go to projects | +| <kbd>Shift</kbd> + <kbd>i</kbd> | Go to issues | +| <kbd>Shift</kbd> + <kbd>m</kbd> | Go to merge requests | +| <kbd>Shift</kbd> + <kbd>t</kbd> | Go to todos | ## Project @@ -84,8 +84,10 @@ You can see GitLab's keyboard shortcuts by using <kbd>shift</kbd> + <kbd>?</kbd> | <kbd>l</kbd> | Change label | | <kbd>]</kbd> or <kbd>j</kbd> | Move to next file | | <kbd>[</kbd> or <kbd>k</kbd> | Move to previous file | +| <kbd>n</kbd> | Move to next unresolved discussion | +| <kbd>p</kbd> | Move to previous unresolved discussion | -## Epics **[ULTIMATE]** +## Epics **(ULTIMATE)** | Keyboard Shortcut | Description | | ----------------- | ----------- | diff --git a/doc/workflow/time_tracking.md b/doc/workflow/time_tracking.md index c03dffa967d..fad853f8a44 100644 --- a/doc/workflow/time_tracking.md +++ b/doc/workflow/time_tracking.md @@ -22,8 +22,8 @@ below. ## How to enter data -Time Tracking uses two [quick actions] that GitLab introduced with this new -feature: `/spend` and `/estimate`. +Time Tracking uses two [quick actions](../user/project/quick_actions.md) +that GitLab introduced with this new feature: `/spend` and `/estimate`. Quick actions can be used in the body of an issue or a merge request, but also in a comment in both an issue or a merge request. @@ -73,8 +73,15 @@ The following time units are available: Default conversion rates are 1mo = 4w, 1w = 5d and 1d = 8h. -Other interesting links: +### Limit displayed units to hours **(CORE ONLY)** -- [Time Tracking landing page on about.gitlab.com](https://about.gitlab.com/solutions/time-tracking/) +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29469/) in GitLab 12.1. + +In GitLab self-managed instances, the display of time units can be limited to +hours through the option in **Admin Area > Settings > Preferences** under **Localization**. + +With this option enabled, `75h` is displayed instead of `1w 4d 3h`. -[quick actions]: ../user/project/quick_actions.md +## Other interesting links + +- [Time Tracking landing page on about.gitlab.com](https://about.gitlab.com/solutions/time-tracking/) diff --git a/doc/workflow/timezone.md b/doc/workflow/timezone.md index da51c0f2c93..60a4d0f19de 100644 --- a/doc/workflow/timezone.md +++ b/doc/workflow/timezone.md @@ -2,13 +2,12 @@ The global time zone configuration parameter can be changed in `config/gitlab.yml`: -``` +```text # time_zone: 'UTC' ``` Uncomment and customize if you want to change the default time zone of the GitLab application. - ## Viewing available timezones To see all available time zones, run `bundle exec rake time:zones:all`. @@ -26,14 +25,13 @@ To obtain a list of timezones, log in to your GitLab application server and run To update, add the timezone that best applies to your location. For example: -``` +```ruby gitlab_rails['time_zone'] = 'America/New_York' ``` After adding the configuration parameter, reconfigure and restart your GitLab instance: -``` +```sh gitlab-ctl reconfigure gitlab-ctl restart ``` - diff --git a/doc/workflow/todos.md b/doc/workflow/todos.md index 32907db4f46..211d242e2d3 100644 --- a/doc/workflow/todos.md +++ b/doc/workflow/todos.md @@ -1,48 +1,55 @@ -# GitLab Todos +# GitLab To-Do List > [Introduced][ce-2817] in GitLab 8.5. When you log into GitLab, you normally want to see where you should spend your -time and take some action, or what you need to keep an eye on. All without the -mess of a huge pile of e-mail notifications. GitLab is where you do your work, -so being able to get started quickly is very important. +time, take some action, or know what you need to keep an eye on without +a huge pile of e-mail notifications. GitLab is where you do your work, +so being able to get started quickly is important. -Todos is a chronological list of to-dos that are waiting for your input, all +Your To-Do List offers a chronological list of items that are waiting for your input, all in a simple dashboard. - + ---- +You can quickly access your To-Do List by clicking the checkmark icon next to the +search bar in the top navigation. If the count is: -You can quickly access the Todos dashboard using the checkmark icon next to the -search bar in the upper right corner. The number in blue is the number of Todos -you still have open if the count is < 100, else it's 99+. The exact number -will still be shown in the body of the _To do_ tab. +- Less than 100, the number in blue is the number of To-Do items. +- 100 or more, the number displays as 99+. The exact number displays + on the To-Do List. +you still have open. Otherwise, the number displays as 99+. The exact number +displays on the To-Do List. - + -## What triggers a Todo +## What triggers a To Do -A Todo appears in your Todos dashboard when: +A To Do displays on your To-Do List when: -- an issue or merge request is assigned to you -- you are `@mentioned` in the description or in a comment of an issue, merge request, or epic **[ULTIMATE]** -- you are `@mentioned` in a comment on a commit, -- a job in the CI pipeline running for your merge request failed, but this - job is not allowed to fail. -- an open merge request becomes unmergeable due to conflict, and you are either: - - the author, or - - have set it to automatically merge once pipeline succeeds. +- An issue or merge request is assigned to you +- You are `@mentioned` in the description or comment of an: + - Issue + - Merge Request + - Epic **(ULTIMATE)** +- You are `@mentioned` in a comment on a commit +- A job in the CI pipeline running for your merge request failed, but this + job is not allowed to fail +- An open merge request becomes unmergeable due to conflict, and you are either: + - The author + - Have set it to automatically merge once the pipeline succeeds + +To-do triggers are not affected by [GitLab Notification Email settings](notifications.md). NOTE: **Note:** -When an user no longer has access to a resource related to a Todo like an issue, merge request, project or group the related Todos, for security reasons, gets deleted within the next hour. The delete is delayed to prevent data loss in case user got their access revoked by mistake. +When a user no longer has access to a resource related to a To Do (like an issue, merge request, project, or group) the related To-Do items are deleted within the next hour for security reasons. The delete is delayed to prevent data loss, in case the user's access was revoked by mistake. -### Directly addressed Todos +### Directly addressing a To Do > [Introduced][ce-7926] in GitLab 9.0. -If you are mentioned at the start of a line, the todo you receive will be listed -as 'directly addressed'. For instance, in this comment: +If you are mentioned at the start of a line, the To Do you receive will be listed +as 'directly addressed'. For example, in this comment: ```markdown @alice What do you think? cc: @bob @@ -56,67 +63,76 @@ as 'directly addressed'. For instance, in this comment: @erin @frank thank you! ``` -The people receiving directly addressed todos are `@alice`, `@erin`, and -`@frank`. Directly addressed todos only differ from mention todos in their type, -for filtering; otherwise, they appear as normal. +The people receiving directly addressed To-Do items are `@alice`, `@erin`, and +`@frank`. Directly addressed To-Do items only differ from mentions in their type +for filtering purposes; otherwise, they appear as normal. + +### Manually creating a To Do + +You can also add the following to your To-Do List by clicking the **Add a To Do** button on an: + +- Issue +- Merge Request +- Epic **(ULTIMATE)** -### Manually creating a Todo + -You can also add an issue, merge request or epic to your Todos dashboard by clicking -the "Add todo" button in the sidebar of the issue, merge request, or epic **[ULTIMATE]**. +## Marking a To Do as done - +Any action to the following will mark the corresponding To Do as done: -## Marking a Todo as done +- Issue +- Merge Request +- Epic **(ULTIMATE)** -Any action to the corresponding issue, merge request or epic **[ULTIMATE]** will mark your Todo as -**Done**. Actions that dismiss Todos include: +Actions that dismiss To-Do items include: -- changing the assignee -- changing the milestone -- adding/removing a label -- commenting on the issue +- Changing the assignee +- Changing the milestone +- Adding/removing a label +- Commenting on the issue ---- +Your To-Do List is personal, and items are only marked as done if the action comes from +you. If you close the issue or merge request, your To Do is automatically +marked as done. -Todos are personal, and they're only marked as done if the action is coming from -you. If you close the issue or merge request, your Todo will automatically -be marked as done. +To prevent other users from closing issues without you being notified, if someone else closes, merges, or takes action on the any of the following, your To Do will remain pending: -If someone else closes, merges, or takes action on the issue, epic or merge -request, your Todo will remain pending. This prevents other users from closing issues without you being notified. +- Issue +- Merge request +- Epic **(ULTIMATE)** -There is just one Todo per issue, epic or merge request, so mentioning a user a -hundred times in an issue will only trigger one Todo. +There is just one To Do for each of these, so mentioning a user a hundred times in an issue will only trigger one To Do. ---- +If no action is needed, you can manually mark the To Do as done by clicking the +corresponding **Done** button, and it will disappear from your To-Do List. -If no action is needed, you can manually mark the Todo as done by clicking the -corresponding **Done** button, and it will disappear from your Todo list. + - +You can also mark a To Do as done by clicking the **Mark as done** button in the sidebar of the following: -A Todo can also be marked as done from the issue, merge request or epic sidebar using -the "Mark todo as done" button. +- Issue +- Merge Request +- Epic **(ULTIMATE)** - + -You can mark all your Todos as done at once by clicking on the **Mark all as +You can mark all your To-Do items as done at once by clicking the **Mark all as done** button. -## Filtering your Todos +## Filtering your To-Do List -There are four kinds of filters you can use on your Todos dashboard. +There are four kinds of filters you can use on your To-Do List. | Filter | Description | | ------- | ----------- | | Project | Filter by project | | Group | Filter by group | -| Author | Filter by the author that triggered the Todo | -| Type | Filter by issue, merge request, or epic **[ULTIMATE]** | -| Action | Filter by the action that triggered the Todo | +| Author | Filter by the author that triggered the To Do | +| Type | Filter by issue, merge request, or epic **(ULTIMATE)** | +| Action | Filter by the action that triggered the To Do | -You can also filter by more than one of these at the same time. The possible Actions are `Any Action`, `Assigned`, `Mentioned`, `Added`, `Pipelines`, and `Directly Addressed`, [as described above](#what-triggers-a-todo). +You can also filter by more than one of these at the same time. The possible Actions are `Any Action`, `Assigned`, `Mentioned`, `Added`, `Pipelines`, and `Directly Addressed`, [as described above](#what-triggers-a-to-do). [ce-2817]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2817 [ce-7926]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7926 diff --git a/doc/workflow/workflow.md b/doc/workflow/workflow.md index f70e41df842..7fac41c3b6f 100644 --- a/doc/workflow/workflow.md +++ b/doc/workflow/workflow.md @@ -1,31 +1,31 @@ # Feature branch workflow -1. Clone project: +1. Clone project: - ```bash - git clone git@example.com:project-name.git - ``` + ```bash + git clone git@example.com:project-name.git + ``` -1. Create branch with your feature: +1. Create branch with your feature: - ```bash - git checkout -b $feature_name - ``` + ```bash + git checkout -b $feature_name + ``` -1. Write code. Commit changes: +1. Write code. Commit changes: - ```bash - git commit -am "My feature is ready" - ``` + ```bash + git commit -am "My feature is ready" + ``` -1. Push your branch to GitLab: +1. Push your branch to GitLab: - ```bash - git push origin $feature_name - ``` + ```bash + git push origin $feature_name + ``` -1. Review your code on commits page. +1. Review your code on commits page. -1. Create a merge request. +1. Create a merge request. -1. Your team lead will review the code & merge it to the main branch. +1. Your team lead will review the code & merge it to the main branch. |
