Commit 8c253997 authored by James Lopez's avatar James Lopez

Merge branch 'master' of gitlab.com:gitlab-org/gitlab-ce into fix/import-export-gitlab-errors

parents 16ed545e 3f41eecf
......@@ -134,6 +134,11 @@ spinach 9 10: *spinach-knapsack
image: "ruby:2.3"
only:
- master
cache:
key: "ruby-23"
paths:
- vendor/apt
- vendor/ruby
.rspec-knapsack-ruby23: &rspec-knapsack-ruby23
<<: *rspec-knapsack
......
Please view this file on the master branch, on stable branches it's out of date.
v 8.9.0 (unreleased)
v 8.10.0 (unreleased)
- Wrap code blocks on Activies and Todos page. !4783 (winniehell)
- Fix MR-auto-close text added to description. !4836
- Implement Subresource Integrity for CSS and JavaScript assets. This prevents malicious assets from loading in the case of a CDN compromise.
v 8.9.0
- Fix builds API response not including commit data
- Fix error when CI job variables key specified but not defined
- Fix pipeline status when there are no builds in pipeline
......@@ -13,7 +18,6 @@ v 8.9.0 (unreleased)
- Fix endless redirections when accessing user OAuth applications when they are disabled
- Allow enabling wiki page events from Webhook management UI
- Bump rouge to 1.11.0
- Fix MR-auto-close text added to description
- Fix issue with arrow keys not working in search autocomplete dropdown
- Fix an issue where note polling stopped working if a window was in the
background during a refresh.
......
8.9.0-pre
8.10.0-pre
......@@ -4,10 +4,9 @@ hideEndFade = ($scrollingTabs) ->
$this
.find('.fade-right')
.toggleClass('end-scroll', $this.width() is $this.prop('scrollWidth'))
.toggleClass('scrolling', $this.width() < $this.prop('scrollWidth'))
$ ->
$('.fade-left').addClass('end-scroll')
hideEndFade($('.scrolling-tabs'))
......@@ -21,5 +20,5 @@ $ ->
currentPosition = $this.scrollLeft()
maxPosition = $this.prop('scrollWidth') - $this.outerWidth()
$this.find('.fade-left').toggleClass('end-scroll', currentPosition is 0)
$this.find('.fade-right').toggleClass('end-scroll', currentPosition is maxPosition)
$this.find('.fade-left').toggleClass('scrolling', currentPosition > 0)
$this.find('.fade-right').toggleClass('scrolling', currentPosition < maxPosition - 1)
......@@ -132,6 +132,10 @@ header {
transition-duration: .3s;
z-index: 999;
svg, img {
height: 36px;
}
&:hover {
cursor: pointer;
}
......
@mixin fade($gradient-direction, $rgba, $gradient-color) {
visibility: visible;
opacity: 1;
visibility: hidden;
opacity: 0;
z-index: 2;
position: absolute;
bottom: 12px;
......@@ -13,9 +13,9 @@
background: -moz-linear-gradient($gradient-direction, $rgba, $gradient-color 45%);
background: linear-gradient($gradient-direction, $rgba, $gradient-color 45%);
&.end-scroll {
visibility: hidden;
opacity: 0;
&.scrolling {
visibility: visible;
opacity: 1;
transition-duration: .3s;
}
......@@ -272,7 +272,7 @@
float: right;
padding: 7px 0 0;
@media (max-width: $screen-xs-max) {
@media (max-width: $screen-sm-max) {
display: none;
}
......@@ -377,9 +377,7 @@
.nav-control {
.fade-right {
@media (min-width: $screen-xs-max) {
right: 68px;
}
@media (max-width: $screen-xs-min) {
right: 0;
}
......
......@@ -54,6 +54,10 @@
}
}
code {
white-space: pre-wrap;
}
pre {
border: none;
background: #f9f9f9;
......
......@@ -6,6 +6,7 @@
height: 30px;
display: inline-block;
margin-right: 10px;
margin-bottom: 10px;
}
&.suggest-colors-dropdown {
......
......@@ -62,6 +62,10 @@
}
}
code {
white-space: pre-wrap;
}
pre {
border: none;
background: #f9f9f9;
......
......@@ -25,11 +25,14 @@
= favicon_link_tag 'favicon.ico'
= stylesheet_link_tag "application", media: "all"
= stylesheet_link_tag "print", media: "print"
= stylesheet_link_tag "application", media: "all", integrity: true
= stylesheet_link_tag "print", media: "print", integrity: true
= javascript_include_tag "application"
= javascript_include_tag "application", integrity: true
-# FIXME: SRI doesn't apply to the dynamically-generated per-page
-# JavaScript due to a bug in sprockets-rails.
-# See https://github.com/rails/sprockets-rails/issues/359
- if page_specific_javascripts
= javascript_include_tag page_specific_javascripts, {"data-turbolinks-track" => true}
......
%ul.nav-links.event-filter.scrolling-tabs
%li.fade-left
= icon('arrow-left')
= event_filter_link EventFilter.push, 'Push events'
= event_filter_link EventFilter.merged, 'Merge events'
= event_filter_link EventFilter.comments, 'Comments'
= event_filter_link EventFilter.team, 'Team'
%li.fade-right
= icon('arrow-right')
......@@ -7,7 +7,8 @@
- [GitLab as OAuth2 authentication service provider](integration/oauth_provider.md). It allows you to login to other applications from GitLab.
- [Container Registry](container_registry/README.md) Learn how to use GitLab Container Registry.
- [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)
- [Importing to GitLab](workflow/importing/README.md).
- [Importing and exporting projects between instances](user/project/settings/import_export.md).
- [Markdown](markdown/markdown.md) GitLab's advanced formatting system.
- [Migrating from SVN](workflow/importing/migrating_from_svn.md) Convert a SVN repository to Git and GitLab.
- [Permissions](permissions/permissions.md) Learn what each role in a project (external/guest/reporter/developer/master/owner) can do.
......
......@@ -85,6 +85,17 @@ GitLab does not ship with a Registry init file. Hence, [restarting GitLab][resta
will not restart the Registry should you modify its settings. Read the upstream
documentation on how to achieve that.
The Docker Registry configuration will need `container_registry` as the service and `https://gitlab.example.com/jwt/auth` as the realm:
```
auth:
token:
realm: https://gitlab.example.com/jwt/auth
service: container_registry
issuer: gitlab-issuer
rootcertbundle: /root/certs/certbundle
```
## Container Registry domain configuration
There are two ways you can configure the Registry's external domain.
......
# Project import/export
>**Note:**
- This feature was [introduced][ce-3050] in GitLab 8.9
- Importing will not be possible if the import instance version is lower
than that of the exporter.
- For existing installations, the project import option has to be enabled in
application settings (`/admin/application_settings`) under 'Import sources'.
- The exports are stored in a temporary [shared directory][tmp] and are deleted
every 24 hours by a specific worker.
The GitLab Import/Export version can be checked by using:
```bash
# Omnibus installations
sudo gitlab-rake gitlab:import_export:version
# Installations from source
bundle exec rake gitlab:import_export:version RAILS_ENV=production
```
The current list of DB tables that will get exported can be listed by using:
```bash
# Omnibus installations
sudo gitlab-rake gitlab:import_export:data
# Installations from source
bundle exec rake gitlab:import_export:data RAILS_ENV=production
```
[ce-3050]: https://gitlab.com/gitlab-org/gitlab-ce/issues/3050
[tmp]: ../../development/shared_files.md
......@@ -13,32 +13,34 @@ If you want a quick introduction to GitLab CI, follow our
**Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)*
- [.gitlab-ci.yml](#gitlab-ci-yml)
- [image and services](#image-and-services)
- [before_script](#before_script)
- [after_script](#after_script)
- [stages](#stages)
- [types](#types)
- [variables](#variables)
- [cache](#cache)
- [cache:key](#cache-key)
- [image and services](#image-and-services)
- [before_script](#before_script)
- [after_script](#after_script)
- [stages](#stages)
- [types](#types)
- [variables](#variables)
- [cache](#cache)
- [cache:key](#cache-key)
- [Jobs](#jobs)
- [script](#script)
- [stage](#stage)
- [job variables](#job-variables)
- [only and except](#only-and-except)
- [tags](#tags)
- [when](#when)
- [environment](#environment)
- [artifacts](#artifacts)
- [artifacts:name](#artifacts-name)
- [artifacts:when](#artifacts-when)
- [artifacts:expire_in](#artifacts-expire_in)
- [dependencies](#dependencies)
- [before_script and after_script](#before_script-and-after_script)
- [script](#script)
- [stage](#stage)
- [only and except](#only-and-except)
- [job variables](#job-variables)
- [tags](#tags)
- [when](#when)
- [environment](#environment)
- [artifacts](#artifacts)
- [artifacts:name](#artifactsname)
- [artifacts:when](#artifactswhen)
- [artifacts:expire_in](#artifactsexpire_in)
- [dependencies](#dependencies)
- [before_script and after_script](#before_script-and-after_script)
- [Git Strategy](#git-strategy)
- [Shallow cloning](#shallow-cloning)
- [Hidden jobs](#hidden-jobs)
- [Special YAML features](#special-yaml-features)
- [Anchors](#anchors)
- [Validate the .gitlab-ci.yml](#validate-the-gitlab-ci-yml)
- [Anchors](#anchors)
- [Validate the .gitlab-ci.yml](#validate-the-gitlab-ciyml)
- [Skipping builds](#skipping-builds)
- [Examples](#examples)
......@@ -724,8 +726,8 @@ time they are uploaded and stored on GitLab.
You can use the **Keep** button on the build page to override expiration and
keep artifacts forever.
By default, artifacts are deleted hourly (via a cron job), but they are not
accessible after expiry.
After expiry, artifacts are actually deleted hourly by default (via a cron job),
but they are not accessible after expiry.
The value of `expire_in` is an elapsed time. Examples of parseable values:
- '3 mins 4 sec'
......@@ -821,6 +823,61 @@ job:
- execute this after my script
```
## Git Strategy
>**Note:**
Introduced in GitLab 8.9 as an experimental feature. May change in future
releases or be removed completely.
You can set the `GIT_STRATEGY` used for getting recent application code. `clone`
is slower, but makes sure you have a clean directory before every build. `fetch`
is faster. `GIT_STRATEGY` can be specified in the global `variables` section or
in the `variables` section for individual jobs. If it's not specified, then the
default from project settings will be used.
```
variables:
GIT_STRATEGY: clone
```
or
```
variables:
GIT_STRATEGY: fetch
```
## Shallow cloning
>**Note:**
Introduced in GitLab 8.9 as an experimental feature. May change in future
releases or be removed completely.
You can specify the depth of fetching and cloning using `GIT_DEPTH`. This allows
shallow cloning of the repository which can significantly speed up cloning for
repositories with a large number of commits or old, large binaries. The value is
passed to `git fetch` and `git clone`.
>**Note:**
If you use a depth of 1 and have a queue of builds or retry
builds, jobs may fail.
Since Git fetching and cloning is based on a ref, such as a branch name, runners
can't clone a specific commit SHA. If there are multiple builds in the queue, or
you are retrying an old build, the commit to be tested needs to be within the
git history that is cloned. Setting too small a value for `GIT_DEPTH` can make
it impossible to run these old commits. You will see `unresolved reference` in
build logs. You should then reconsider changing `GIT_DEPTH` to a higher value.
Builds that rely on `git describe` may not work correctly when `GIT_DEPTH` is
set since only part of the git history is present.
To fetch or clone only the last 3 commits:
```
variables:
GIT_DEPTH: "3"
```
## Hidden jobs
>**Note:**
......
......@@ -12,7 +12,7 @@ Create projects and groups.
Create issues, labels, milestones, cast your vote, and review issues.
- [Create a new issue](../gitlab-basics/create-issue.md)
- [Assign labels to issues](../workflow/labels.md)
- [Assign labels to issues](../user/project/labels.md)
- [Use milestones as an overview of your project's tracker](../workflow/milestones.md)
- [Use voting to express your like/dislike to issues and merge requests](../workflow/award_emoji.md)
......
......@@ -13,6 +13,10 @@
git fetch origin
git checkout v3.0.3
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u gitlab -H vim Gemfile
# Install libs
sudo -u gitlab bundle install --without development test postgres
......
......@@ -13,6 +13,11 @@
sudo -u gitlab -H git fetch origin
sudo -u gitlab -H git checkout v3.0.3
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u gitlab -H vim Gemfile
# Install gems
sudo -u gitlab -H bundle install --without development test postgres
......
......@@ -25,6 +25,11 @@ sudo -u gitlab -H git checkout v3.1.0
# Install new charlock_holmes
sudo gem install charlock_holmes --version '0.6.9'
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u gitlab -H vim Gemfile
# Install gems for MySQL
sudo -u gitlab -H bundle install --without development test postgres sqlite
......
......@@ -26,6 +26,11 @@ I wrote a bash script which will do it automatically for you. Just make sure all
sudo -u gitlab -H git fetch
sudo -u gitlab -H git checkout 4-0-stable
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u gitlab -H vim Gemfile
# Install gems for MySQL
sudo -u gitlab -H bundle install --without development test postgres
......
......@@ -22,6 +22,11 @@ cd /home/gitlab/gitlab/
sudo -u gitlab -H git fetch
sudo -u gitlab -H git checkout 4-1-stable
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u gitlab -H vim Gemfile
# Install gems for MySQL
sudo -u gitlab -H bundle install --without development test postgres
......
......@@ -17,7 +17,15 @@ sudo -u gitlab -H git fetch
sudo -u gitlab -H git checkout 4-2-stable
# Install libs
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u gitlab -H vim Gemfile
# Run a bundle install without deployment to generate the new Gemfile
sudo -u gitlab -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u gitlab -H bundle install --without development test postgres --deployment
# update db
......
......@@ -85,8 +85,17 @@ sudo -u git -H cp config/gitlab.yml.example config/gitlab.yml
# edit it
sudo -u git -H vim config/gitlab.yml
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u git -H vim Gemfile
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production
sudo -u git -H bundle exec rake gitlab:shell:build_missing_projects RAILS_ENV=production
......
......@@ -42,7 +42,17 @@ cd /home/git/gitlab
sudo rm tmp/sockets/gitlab.socket
sudo -u git -H cp config/puma.rb.example config/puma.rb
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u git -H vim Gemfile
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
sudo -u git -H bundle exec rake migrate_merge_requests RAILS_ENV=production
sudo -u git -H bundle exec rake assets:precompile RAILS_ENV=production
......
......@@ -40,12 +40,28 @@ sudo -u git -H git checkout v1.4.0
```bash
cd /home/git/gitlab
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u git -H vim Gemfile
# MySQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
#PostgreSQL
# PostgreSQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test mysql --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test mysql --deployment
# Both MySQL and PostgreSQL
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
sudo -u git -H bundle exec rake assets:precompile RAILS_ENV=production
......
......@@ -37,12 +37,28 @@ sudo -u git -H git checkout v1.7.9 # Addresses multiple critical security vulner
```bash
cd /home/git/gitlab
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u git -H vim Gemfile
# MySQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
#PostgreSQL
# PostgreSQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test mysql --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test mysql --deployment
# Both MySQL and PostgreSQL
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
sudo -u git -H bundle exec rake assets:precompile RAILS_ENV=production
......
......@@ -137,12 +137,28 @@ sudo apt-get install python-docutils
```bash
cd /home/git/gitlab
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u git -H vim Gemfile
# MySQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
#PostgreSQL
# PostgreSQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test mysql --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test mysql --deployment
# Both MySQL and PostgreSQL
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
sudo -u git -H bundle exec rake migrate_groups RAILS_ENV=production
sudo -u git -H bundle exec rake migrate_global_projects RAILS_ENV=production
......
......@@ -31,12 +31,28 @@ sudo -u git -H git checkout 5-3-stable
```bash
cd /home/git/gitlab
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u git -H vim Gemfile
# MySQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
#PostgreSQL
# PostgreSQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test mysql --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test mysql --deployment
# Both MySQL and PostgreSQL
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
sudo -u git -H bundle exec rake assets:precompile RAILS_ENV=production
......
......@@ -35,12 +35,28 @@ sudo -u git -H git checkout v1.7.9 # Addresses multiple critical security vulner
```bash
cd /home/git/gitlab
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u git -H vim Gemfile
# MySQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
#PostgreSQL
# PostgreSQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test mysql --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test mysql --deployment
# Both MySQL and PostgreSQL
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
sudo -u git -H bundle exec rake assets:precompile RAILS_ENV=production
......
......@@ -73,12 +73,28 @@ sudo apt-get install python-docutils
```bash
cd /home/git/gitlab
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u git -H vim Gemfile
# MySQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
# PostgreSQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test mysql --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test mysql --deployment
# Both MySQL and PostgreSQL
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
sudo -u git -H bundle exec rake migrate_groups RAILS_ENV=production
sudo -u git -H bundle exec rake migrate_global_projects RAILS_ENV=production
......
......@@ -50,13 +50,28 @@ sudo -u git -H git checkout v1.7.9
```bash
cd /home/git/gitlab
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u git -H vim Gemfile
# MySQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
#PostgreSQL
sudo -u git -H bundle install --without development test mysql --deployment
# PostgreSQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test mysql --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test mysql --deployment
# Both MySQL and PostgreSQL
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
sudo -u git -H bundle exec rake migrate_iids RAILS_ENV=production
sudo -u git -H bundle exec rake assets:clean RAILS_ENV=production
......
......@@ -45,13 +45,28 @@ sudo apt-get install logrotate
```bash
cd /home/git/gitlab
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u git -H vim Gemfile
# MySQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
#PostgreSQL
sudo -u git -H bundle install --without development test mysql --deployment
# PostgreSQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test mysql --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test mysql --deployment
# Both MySQL and PostgreSQL
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
sudo -u git -H bundle exec rake assets:clean RAILS_ENV=production
sudo -u git -H bundle exec rake assets:precompile RAILS_ENV=production
......
......@@ -40,13 +40,28 @@ The gitlab-shell config changed recently, so check for config file changes and m
```bash
cd /home/git/gitlab
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u git -H vim Gemfile
# MySQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
# PostgreSQL
sudo -u git -H bundle install --without development test mysql --deployment
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test mysql --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test mysql --deployment
# Both MySQL and PostgreSQL
# Run database migrations
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
......
......@@ -36,13 +36,28 @@ sudo -u git -H git checkout v1.8.0
```bash
cd /home/git/gitlab
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u git -H vim Gemfile
# MySQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
# PostgreSQL
sudo -u git -H bundle install --without development test mysql --deployment
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test mysql --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test mysql --deployment
# Both MySQL and PostgreSQL
# Run database migrations
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
......
......@@ -46,13 +46,28 @@ sudo -u git -H git checkout v1.8.0
```bash
cd /home/git/gitlab
# MySQL installations (note: the line below states '--without ... postgres')
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u git -H vim Gemfile
# MySQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
# PostgreSQL installations (note: the line below states '--without ... mysql')
sudo -u git -H bundle install --without development test mysql --deployment
# PostgreSQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test mysql --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test mysql --deployment
# Both MySQL and PostgreSQL
# Run database migrations
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
......
......@@ -46,12 +46,28 @@ sudo -u git -H git checkout v1.8.0
```bash
cd /home/git/gitlab
# MySQL installations (note: the line below states '--without ... postgres')
# The Modernizr gem was yanked from RubyGems. It is required for GitLab >= 2.8.0
# Edit `Gemfile` and change `gem "modernizr", "2.5.3"` to
# `gem "modernizr-rails", "2.7.1"``
sudo -u git -H vim Gemfile
# MySQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
# PostgreSQL installations (note: the line below states '--without ... mysql')
# PostgreSQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test mysql --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test mysql --deployment
# Both MySQL and PostgreSQL
# Run database migrations
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
......
......@@ -46,13 +46,23 @@ sudo -u git -H git checkout v1.9.1
```bash
cd /home/git/gitlab
# MySQL installations (note: the line below states '--without ... postgres')
# MySQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test postgres --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test postgres --deployment
# PostgreSQL installations (note: the line below states '--without ... mysql')
sudo -u git -H bundle install --without development test mysql --deployment
# PostgreSQL
# Run a bundle install without deployment to generate the new Gemfile
sudo -u git -H bundle install --without development test mysql --no-deployment
# Install libs (with deployment this time)
sudo -u git -H bundle install --without development test mysql --deployment
# Both MySQL and PostgreSQL
# Run database migrations
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
......
......@@ -147,12 +147,15 @@ sudo -u git -H bundle install --without development test postgres --deployment
# PostgreSQL installations (note: the line below states '--without ... mysql')
sudo -u git -H bundle install --without development test mysql --deployment
# Run database migrations
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
# Run database migrations from 6.0 to 6.1
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production VERSION=20130909132950
# Enable internal issue IDs (introduced in GitLab 6.1)
sudo -u git -H bundle exec rake migrate_iids RAILS_ENV=production
# Run left database migrations
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
......
# Labels
Labels provide an easy way to categorize the issues or merge requests based on
descriptive titles like `bug`, `documentation` or any other text you feel like
it. They can have different colors, a description, and are visible throughout
the issue tracker or inside each issue individually.
With labels, you can navigate the issue tracker and filter any bloated
information to visualize only the issues you are interested in. Let's see how
that works.
## Create new labels
>**Note:**
A permission level of `Developer` or higher is required in order to manage
labels.
Head over a single project and navigate to **Issues > Labels**.
The first time you visit this page, you'll notice that there are no labels
created yet.
![Generate new labels](img/labels_generate.png)
---
You can skip that and create a new label or click that link and GitLab will
generate a set of predefined labels for you. There 8 default generated labels
in total and you can see them in the screenshot below.
![Default generated labels](img/labels_default.png)
---
You can see that from the labels page you can have an overview of the number of
issues and merge requests assigned to each label.
Creating a new label from scratch is as easy as pressing the **New label**
button. From there on you can choose the name, give it an optional description,
a color and you are set.
When you are ready press the **Create label** button to create the new label.
![New label](img/labels_new_label.png)
## Prioritize labels
>**Notes:**
- This feature was introduced in GitLab 8.9.
- Priority sorting is based on the highest priority label only. This might
change in the future, follow the discussion in
https://gitlab.com/gitlab-org/gitlab-ce/issues/18554.
Prioritized labels are like any other label, but sorted by priority. This allows
you to sort issues and merge requests by priority.
To prioritize labels, navigate to your project's **Issues > Labels** and click
on the star icon next to them to put them in the priority list. Click on the
star icon again to remove them from the list.
From there, you can drag them around to set the desired priority. Priority is
set from high to low with an ascending order. Labels with no priority, count as
having their priority set to null.
![Prioritize labels](img/labels_prioritize.png)
Now that you have labels prioritized, you can use the 'Priority' filter in the
issues or merge requests tracker. Those with the highest priority label, will
appear on top.
![Filter labels by priority](img/labels_filter_by_priority.png)
## Subscribe to labels
If you don’t want to miss issues or merge requests that are important to you,
simply subscribe to a label. You’ll get notified whenever the label gets added
to an issue or merge request, making sure you don’t miss a thing.
Go to your project's **Issues > Labels** area, find the label(s) you want to
subscribe to and click on the eye icon. Click again to unsubscribe.
![Subscribe to labels](img/labels_subscribe.png)
If you work on a large or popular project, try subscribing only to the labels
that are relevant to you. You’ll notice it’ll be much easier to focus on what’s
important.
## Create a new label right from the issue tracker
>**Note:**
This feature was introduced in GitLab 8.6.
There are times when you are already in the issue tracker searching for a
label, only to realize it doesn't exist. Instead of going to the **Labels**
page and being distracted from your original purpose, you can create new
labels on the fly.
Select **Create new** from the labels dropdown list, provide a name, pick a
color and hit **Create**.
![Create new label on the fly](img/labels_new_label_on_the_fly_create.png)
![New label on the fly](img/labels_new_label_on_the_fly.png)
## Assigning labels to issues and merge requests
There are generally two ways to assign a label to an issue or merge request.
You can assign a label when you first create or edit an issue or merge request.
![Assign label in new issue](img/labels_assign_label_in_new_issue.png)
---
The second way is by using the right sidebar when inside an issue or merge
request. Expand it and hit **Edit** in the labels area. Start typing the name
of the label you are looking for to narrow down the list, and select it. You
can add more than one labels at once. When done, click outside the sidebar area
for the changes to take effect.
![Assign label in sidebar](img/labels_assign_label_sidebar.png)
![Save labels in sidebar](img/labels_assign_label_sidebar_saved.png)
---
To remove labels, expand the left sidebar and unmark them from the labels list.
Simple as that.
## Use labels to filter issues
Once you start adding labels to your issues, you'll see the benefit of it.
Labels can have several uses, one of them being the quick filtering of issues
or merge requests.
Pick an existing label from the dropdown _Label_ menu or click on an existing
label from the issue tracker. In the latter case, you also get to see the
label description like shown below.
![Filter labels](img/labels_filter.png)
---
And if you added a description to your label, you can see it by hovering your
mouse over the label in the issue tracker or wherever else the label is
rendered.
![Label tooltips](img/labels_description_tooltip.png)
# Project import/export
>**Notes:**
- This feature was [introduced][ce-3050] in GitLab 8.9
- Importing will not be possible if the import instance version is lower
than that of the exporter.
- For existing installations, the project import option has to be enabled in
application settings (`/admin/application_settings`) under 'Import sources'.
Ask your administrator if you don't see the **GitLab export** button when
creating a new project.
- You can find some useful raketasks if you are an administrator in the
[import_export](../../../administration/raketasks/project_import_export.md)
raketask.
- The exports are stored in a temporary [shared directory][tmp] and are deleted
every 24 hours by a specific worker.
Existing projects running on any GitLab instance or GitLab.com can be exported
with all their related data and be moved into a new GitLab instance.
## Exported contents
The following items will be exported:
- Project and wiki repositories
- Project uploads
- Project configuration including web hooks and services
- Issues with comments, merge requests with diffs and comments, labels, milestones, snippets,
and other project entities
The following items will NOT be exported:
- Build traces and artifacts
- LFS objects
## Exporting a project and its data
1. Go to the project settings page by clicking on **Edit Project**:
![Project settings button](img/settings_edit_button.png)
1. Scroll down to find the **Export project** button:
![Export button](img/import_export_export_button.png)
1. Once the export is generated, you should receive an e-mail with a link to
download the file:
![Email download link](img/import_export_mail_link.png)
1. Alternatively, you can come back to the project settings and download the
file from there, or generate a new export. Once the file available, the page
should show the **Download export** button:
![Download export](img/import_export_download_export.png)
## Importing the project
1. The new GitLab project import feature is at the far right of the import
options when creating a New Project. Make sure you are in the right namespace
and you have entered a project name. Click on **GitLab export**:
![New project](img/import_export_new_project.png)
1. You can see where the project will be imported to. You can now select file
exported previously:
![Select file](img/import_export_select_file.png)
1. Click on **Import project** to begin importing. Your newly imported project
page will appear soon.
[ce-3050]: https://gitlab.com/gitlab-org/gitlab-ce/issues/3050
[tmp]: ../../../development/shared_files.md
......@@ -7,7 +7,7 @@
- [Groups](groups.md)
- [Keyboard shortcuts](shortcuts.md)
- [File finder](file_finder.md)
- [Labels](labels.md)
- [Labels](../user/project/labels.md)
- [Notification emails](notifications.md)
- [Project Features](project_features.md)
- [Project forking workflow](forking_workflow.md)
......
# Award emojis
# Award emoji
>**Note:**
This feature was [introduced][1825] in GitLab 8.2.
When you're collaborating online, you get fewer opportunities for high-fives
and thumbs-ups. In order to make virtual celebrations easier, you can now vote
on issues and merge requests using emoji!
and thumbs-ups. Emoji can be awarded to issues and merge requests, making
virtual celebrations easier.
![Award emoji](img/award_emoji_select.png)
This makes it much easier to give and receive feedback, without a long comment
thread. Any comment that contains only the thumbs up or down emojis is
converted to a vote and depicted in the emoji area.
You can then use that functionality to sort issues and merge requests based on
popularity.
Award emoji make it much easier to give and receive feedback without a long
comment thread. Comments that are only emoji will automatically become
award emoji.
## Sort issues and merge requests on vote count
>**Note:**
This feature was [introduced][2871] in GitLab 8.5.
You can quickly sort the issues or merge requests by the number of votes they
have received. The sort option can be found in the right dropdown menu.
You can quickly sort issues and merge requests by the number of votes they
have received. The sort options can be found in the dropdown menu as "Most
popular" and "Least popular".
![Votes sort options](img/award_emoji_votes_sort_options.png)
......@@ -40,9 +38,28 @@ Sort by least popular issues/merge requests.
---
The number of upvotes and downvotes is not summed up. That means that an issue
with 18 upvotes and 5 downvotes is considered more popular than an issue with
17 upvotes and no downvotes.
The total number of votes is not summed up. An issue with 18 upvotes and 5
downvotes is considered more popular than an issue with 17 upvotes and no
downvotes.
## Award emoji for comments
>**Note:**
This feature was [introduced][4291] in GitLab 8.9.
Award emoji can also be applied to individual comments when you want to
celebrate an accomplishment or agree with an opinion.
To add an award emoji, click the smile in the top right of the comment and pick
an emoji from the dropdown.
![Picking an emoji for a comment](img/award_emoji_comment_picker.png)
![An award emoji has been applied to a comment](img/award_emoji_comment_awarded.png)
If you want to remove an award emoji, just click the emoji again and the vote
will be removed.
[2871]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2781
[1825]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/1825
[4291]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4291
doc/workflow/award_emoji.png

6.46 KB | W: | H:

doc/workflow/award_emoji.png

16.5 KB | W: | H:

doc/workflow/award_emoji.png
doc/workflow/award_emoji.png
doc/workflow/award_emoji.png
doc/workflow/award_emoji.png
  • 2-up
  • Swipe
  • Onion skin
doc/workflow/img/todos_icon.png

7.22 KB | W: | H:

doc/workflow/img/todos_icon.png

6.17 KB | W: | H:

doc/workflow/img/todos_icon.png
doc/workflow/img/todos_icon.png
doc/workflow/img/todos_icon.png
doc/workflow/img/todos_icon.png
  • 2-up
  • Swipe
  • Onion skin
# Labels
In GitLab, you can easily tag issues and Merge Requests. If you have permission level `Developer` or higher, you can manage labels. To create, edit or delete a label, go to a project and then to `Issues` and then `Labels`.
Here you can create a new label.
![new label](labels/label1.png)
You can choose to set a color.
![label color](labels/label2.png)
If you want to change an existing label, press edit next to the listed label.
You will be presented with the same form as when creating a new label.
![edit label](labels/label3.png)
You can add labels to Merge Requests when you create or edit them.
This document was moved to [user/project/labels.md](../user/project/labels.md).
# GitLab ToDos
# GitLab Todos
>**Note:** This feature was [introduced][ce-2817] in GitLab 8.5.
......@@ -14,8 +14,9 @@ in a simple dashboard.
---
You can access quickly your Todos dashboard by clicking the round gray icon
next to the search bar in the upper right corner.
You can quickly access the Todos dashboard using the bell icon next to the
search bar in the upper right corner. The number in blue is the number of Todos
you still have open.
![Todos icon](img/todos_icon.png)
......@@ -29,45 +30,61 @@ A Todo appears in your Todos dashboard when:
>**Note:** Commenting on a commit will _not_ trigger a Todo.
## How a Todo is marked as Done
### Manually creating a Todo
You can also add an issue or merge request to your Todos dashboard by clicking
the "Add Todo" button in the issue or merge request sidebar.
![Adding a Todo from the issuable sidebar](img/todos_add_todo_sidebar.png)
## Marking a Todo as done
Any action to the corresponding issue or merge request will mark your Todo as
**Done**. This action can include:
**Done**. Actions that dismiss Todos include:
- changing the assignee
- changing the milestone
- adding/removing a label
- commenting on the issue
In case where you think no action is needed, you can manually mark the todo as
done by clicking the corresponding **Done** button, and it will disappear from
your Todos list. If you want to mark all your Todos as done, just click on the
**Mark all as done** button.
---
In order for a Todo to be marked as done, the action must be coming from you.
So, if you close the related issue or merge the merge request yourself, and you
had a Todo for that, it will automatically get marked as done. On the other
hand, if someone else closes, merges or takes action on the issue or merge
request, your Todo will remain pending. This makes sense because you may need
to give attention to an issue even if it has been resolved.
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.
If someone else closes, merges, or takes action on the issue or merge
request, your Todo will remain pending. This prevents other users from closing issues without you being notified.
There is just one Todo per issue or merge request, so mentioning a user a
hundred times in an issue will only trigger one Todo.
---
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.
![A Todo in the Todos dashboard](img/todo_list_item.png)
A Todo can also be marked as done from the issue or merge request sidebar using
the "Mark Done" button.
![Mark Done from the issuable sidebar](img/todos_mark_done_sidebar.png)
You can mark all your Todos as done at once by clicking on the **Mark all as
done** button.
## Filtering your Todos
In general, there are four kinds of filters you can use on your Todos
dashboard:
There are four kinds of filters you can use on your Todos dashboard.
| Filter | Description |
| ------ | ----------- |
| Filter | Description |
| ------- | ----------- |
| Project | Filter by project |
| Author | Filter by the author that triggered the Todo |
| Type | Filter by issue or merge request |
| Action | Filter by the action that triggered the Todo (Assigned or Mentioned)|
You can choose more than one filters at the same time.
You can also filter by more than one of these at the same time.
[ce-2817]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2817
......@@ -31,10 +31,14 @@ module Banzai
projects_per_reference.each do |path, project|
issue_ids = references_per_project[path]
next unless project.default_issues_tracker?
if project.default_issues_tracker?
issues = project.issues.where(iid: issue_ids.to_a)
else
issues = issue_ids.map { |id| ExternalIssue.new(id, project) }
end
project.issues.where(iid: issue_ids.to_a).each do |issue|
hash[project][issue.iid] = issue
issues.each do |issue|
hash[project][issue.iid.to_i] = issue
end
end
......
......@@ -74,7 +74,7 @@ module Gitlab
if user
# Case when a LDAP user already exists in Gitlab. Add the OAuth identity to existing account.
log.info "LDAP account found for user #{user.username}. Building new #{auth_hash.provider} identity."
user.identities.build(extern_uid: auth_hash.uid, provider: auth_hash.provider)
user.identities.find_or_initialize_by(extern_uid: auth_hash.uid, provider: auth_hash.provider)
else
log.info "No existing LDAP account was found in GitLab. Checking for #{auth_hash.provider} account."
user = find_by_uid_and_provider
......
namespace :gitlab do
namespace :import_export do
desc "GitLab | Show Import/Export version"
task version: :environment do
puts "Import/Export v#{Gitlab::ImportExport.version}"
end
desc "GitLab | Display exported DB structure"
task data: :environment do
puts YAML.load_file(Gitlab::ImportExport.config_file)['project_tree'].to_yaml(:SortKeys => true)
end
end
end
......@@ -198,4 +198,40 @@ describe Banzai::Filter::IssueReferenceFilter, lib: true do
expect(doc.to_html).to match(/\(<a.+>Reference<\/a>\.\)/)
end
end
describe '#issues_per_Project' do
context 'using an internal issue tracker' do
it 'returns a Hash containing the issues per project' do
doc = Nokogiri::HTML.fragment('')
filter = described_class.new(doc, project: project)
expect(filter).to receive(:projects_per_reference).
and_return({ project.path_with_namespace => project })
expect(filter).to receive(:references_per_project).
and_return({ project.path_with_namespace => Set.new([issue.iid]) })
expect(filter.issues_per_project).
to eq({ project => { issue.iid => issue } })
end
end
context 'using an external issue tracker' do
it 'returns a Hash containing the issues per project' do
doc = Nokogiri::HTML.fragment('')
filter = described_class.new(doc, project: project)
expect(project).to receive(:default_issues_tracker?).and_return(false)
expect(filter).to receive(:projects_per_reference).
and_return({ project.path_with_namespace => project })
expect(filter).to receive(:references_per_project).
and_return({ project.path_with_namespace => Set.new([1]) })
expect(filter.issues_per_project[project][1]).
to be_an_instance_of(ExternalIssue)
end
end
end
end
......@@ -164,7 +164,14 @@ describe Gitlab::Saml::User, lib: true do
end
context 'and LDAP user has an account already' do
let!(:existing_user) { create(:omniauth_user, email: 'john@mail.com', extern_uid: 'uid=user1,ou=People,dc=example', provider: 'ldapmain', username: 'john') }
before do
create(:omniauth_user,
email: 'john@mail.com',
extern_uid: 'uid=user1,ou=People,dc=example',
provider: 'ldapmain',
username: 'john')
end
it 'adds the omniauth identity to the LDAP account' do
saml_user.save
......@@ -177,6 +184,15 @@ describe Gitlab::Saml::User, lib: true do
{ provider: 'saml', extern_uid: uid }
])
end
it 'saves successfully on subsequent tries, when both identities are present' do
saml_user.save
local_saml_user = described_class.new(auth_hash)
local_saml_user.save
expect(local_saml_user.gl_user).to be_valid
expect(local_saml_user.gl_user).to be_persisted
end
end
context 'user has SAML user, and wants to add their LDAP identity' do
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment