diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/install/installation.md | 5 | ||||
| -rw-r--r-- | doc/raketasks/backup_restore.md | 2 | ||||
| -rw-r--r-- | doc/workflow/gitlab_flow.md | 2 |
3 files changed, 2 insertions, 7 deletions
diff --git a/doc/install/installation.md b/doc/install/installation.md index a470033f9ad..b48acb655ee 100644 --- a/doc/install/installation.md +++ b/doc/install/installation.md @@ -346,11 +346,6 @@ The `secrets.yml` file stores encryption keys for sessions and secure variables. Backup `secrets.yml` someplace safe, but don't store it in the same place as your database backups. Otherwise your secrets are exposed if one of your backups is compromised. -### Install schedules - - # Setup schedules - sudo -u gitlab_ci -H bundle exec whenever -w RAILS_ENV=production - ### Install Init Script Download the init script (will be `/etc/init.d/gitlab`): diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md index 06f582dcee8..606532a6fbe 100644 --- a/doc/raketasks/backup_restore.md +++ b/doc/raketasks/backup_restore.md @@ -29,7 +29,7 @@ sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production ``` Also you can choose what should be backed up by adding environment variable SKIP. Available options: db, -uploads (attachments), repositories. Use a comma to specify several options at the same time. +uploads (attachments), repositories, builds(CI build output logs). Use a comma to specify several options at the same time. ``` sudo gitlab-rake gitlab:backup:create SKIP=db,uploads diff --git a/doc/workflow/gitlab_flow.md b/doc/workflow/gitlab_flow.md index f608674faf6..9a24a1e252a 100644 --- a/doc/workflow/gitlab_flow.md +++ b/doc/workflow/gitlab_flow.md @@ -26,7 +26,7 @@ After getting used to these three steps the branching model becomes the challeng Since many organizations new to git have no conventions how to work with it, it can quickly become a mess. The biggest problem they run into is that many long running branches that each contain part of the changes are around. People have a hard time figuring out which branch they should develop on or deploy to production. -Frequently the reaction to this problem is to adopt a standardized pattern such as [git flow](http://nvie.com/posts/a-successful-git-branching-model/) and [GitHub flow](http://scottchacon.com/2011/08/31/github-flow.html) +Frequently the reaction to this problem is to adopt a standardized pattern such as [git flow](http://nvie.com/posts/a-successful-git-branching-model/) and [GitHub flow](http://scottchacon.com/2011/08/31/github-flow.html). We think there is still room for improvement and will detail a set of practices we call GitLab flow. ## Git flow and its problems |