Commit 95a67cdb authored by Douglas Barbosa Alexandre's avatar Douglas Barbosa Alexandre

Merge branch 'master' into branch-invalid-name

parents 4163eb56 08ddb8f7
Please view this file on the master branch, on stable branches it's out of date. Please view this file on the master branch, on stable branches it's out of date.
v 8.3.0 (unreleased) v 8.3.0 (unreleased)
- API support for starred projects for authorized user (Zeger-Jan van de Weg)
- Add open_issues_count to project API (Stan Hu) - Add open_issues_count to project API (Stan Hu)
- Expand character set of usernames created by Omniauth (Corey Hinshaw) - Expand character set of usernames created by Omniauth (Corey Hinshaw)
- Add button to automatically merge a merge request when the build succeeds (Zeger-Jan van de Weg) - Add button to automatically merge a merge request when the build succeeds (Zeger-Jan van de Weg)
- Merge when build succeeds (Zeger-Jan van de Weg)
- Provide better diagnostic message upon project creation errors (Stan Hu) - Provide better diagnostic message upon project creation errors (Stan Hu)
- Bump devise to 3.5.3 to fix reset token expiring after account creation (Stan Hu) - Bump devise to 3.5.3 to fix reset token expiring after account creation (Stan Hu)
- Bump gollum-lib to 4.1.0 (Stan Hu) - Bump gollum-lib to 4.1.0 (Stan Hu)
......
...@@ -251,7 +251,7 @@ group :development, :test do ...@@ -251,7 +251,7 @@ group :development, :test do
gem 'capybara', '~> 2.4.0' gem 'capybara', '~> 2.4.0'
gem 'capybara-screenshot', '~> 1.0.0' gem 'capybara-screenshot', '~> 1.0.0'
gem 'poltergeist', '~> 1.6.0' gem 'poltergeist', '~> 1.8.1'
gem 'teaspoon', '~> 1.0.0' gem 'teaspoon', '~> 1.0.0'
gem 'teaspoon-jasmine', '~> 2.2.0' gem 'teaspoon-jasmine', '~> 2.2.0'
......
...@@ -405,7 +405,7 @@ GEM ...@@ -405,7 +405,7 @@ GEM
method_source (0.8.2) method_source (0.8.2)
mime-types (1.25.1) mime-types (1.25.1)
mimemagic (0.3.0) mimemagic (0.3.0)
mini_portile (0.6.2) mini_portile2 (2.0.0)
minitest (5.7.0) minitest (5.7.0)
mousetrap-rails (1.4.6) mousetrap-rails (1.4.6)
multi_json (1.11.2) multi_json (1.11.2)
...@@ -420,8 +420,8 @@ GEM ...@@ -420,8 +420,8 @@ GEM
grape grape
newrelic_rpm newrelic_rpm
newrelic_rpm (3.9.4.245) newrelic_rpm (3.9.4.245)
nokogiri (1.6.6.4) nokogiri (1.6.7)
mini_portile (~> 0.6.0) mini_portile2 (~> 2.0.0.rc2)
nprogress-rails (0.1.6.7) nprogress-rails (0.1.6.7)
oauth (0.4.7) oauth (0.4.7)
oauth2 (1.0.0) oauth2 (1.0.0)
...@@ -488,7 +488,7 @@ GEM ...@@ -488,7 +488,7 @@ GEM
parser (2.2.3.0) parser (2.2.3.0)
ast (>= 1.1, < 3.0) ast (>= 1.1, < 3.0)
pg (0.18.4) pg (0.18.4)
poltergeist (1.6.0) poltergeist (1.8.1)
capybara (~> 2.1) capybara (~> 2.1)
cliver (~> 0.3.1) cliver (~> 0.3.1)
multi_json (~> 1.0) multi_json (~> 1.0)
...@@ -905,7 +905,7 @@ DEPENDENCIES ...@@ -905,7 +905,7 @@ DEPENDENCIES
org-ruby (~> 0.9.12) org-ruby (~> 0.9.12)
paranoia (~> 2.0) paranoia (~> 2.0)
pg (~> 0.18.2) pg (~> 0.18.2)
poltergeist (~> 1.6.0) poltergeist (~> 1.8.1)
pry-rails pry-rails
quiet_assets (~> 1.0.2) quiet_assets (~> 1.0.2)
rack-attack (~> 4.3.0) rack-attack (~> 4.3.0)
......
...@@ -18,7 +18,7 @@ class @IssuableContext ...@@ -18,7 +18,7 @@ class @IssuableContext
$('.issuable-affix').affix offset: $('.issuable-affix').affix offset:
top: -> top: ->
@top = ($('.issuable-affix').offset().top - 60) @top = ($('.issuable-affix').offset().top - 70)
bottom: -> bottom: ->
@bottom = $('.footer').outerHeight(true) @bottom = $('.footer').outerHeight(true)
......
...@@ -18,7 +18,7 @@ ...@@ -18,7 +18,7 @@
&.affix { &.affix {
position: fixed; position: fixed;
top: 60px; top: 70px;
margin-right: 35px; margin-right: 35px;
} }
} }
...@@ -39,16 +39,9 @@ ...@@ -39,16 +39,9 @@
section { section {
border-right: 1px solid $border-white-light; border-right: 1px solid $border-white-light;
> .tab-content { .issuable-discussion {
margin-right: 1px; margin-right: 1px;
} }
.issue-discussion > .gray-content-block,
> .gray-content-block {
margin-top: 0;
border-top: none;
margin-right: -15px;
}
} }
} }
......
...@@ -141,18 +141,6 @@ form.edit-issue { ...@@ -141,18 +141,6 @@ form.edit-issue {
} }
} }
.issue-closed-by-widget {
padding: 16px 0;
margin: 0px;
}
.issue-form .select2-container { .issue-form .select2-container {
width: 250px !important; width: 250px !important;
} }
.issue-discussion {
.common-note-form {
border-right: 1px solid $border-white-light;
}
}
.issue-closed-by-widget .issue-closed-by-widget.gray-content-block.second-block.white
= icon('check')
This issue will be closed automatically when merge request #{markdown(merge_requests_sentence(@closed_by_merge_requests), pipeline: :gfm)} is accepted. This issue will be closed automatically when merge request #{markdown(merge_requests_sentence(@closed_by_merge_requests), pipeline: :gfm)} is accepted.
...@@ -5,8 +5,5 @@ ...@@ -5,8 +5,5 @@
- else - else
= link_to 'Close Issue', issue_path(@issue, issue: {state_event: :close}, status_only: true), method: :put, class: 'btn btn-grouped btn-close js-note-target-close', title: 'Close Issue' = link_to 'Close Issue', issue_path(@issue, issue: {state_event: :close}, status_only: true), method: :put, class: 'btn btn-grouped btn-close js-note-target-close', title: 'Close Issue'
.gray-content-block.second-block.oneline-block
= render 'votes/votes_block', votable: @issue
#notes #notes
= render 'projects/notes/notes_with_form' = render 'projects/notes/notes_with_form'
...@@ -37,26 +37,30 @@ ...@@ -37,26 +37,30 @@
Edit Edit
.issue-details.issuable-details .issue-details.issuable-details
.row .detail-page-description.gray-content-block.second-block
%section.col-md-9 %h2.title
.detail-page-description.gray-content-block = markdown escape_once(@issue.title), pipeline: :single_line
%h2.title %div
= markdown escape_once(@issue.title), pipeline: :single_line - if @issue.description.present?
%div .description{class: can?(current_user, :update_issue, @issue) ? 'js-task-list-container' : ''}
- if @issue.description.present? .wiki
.description{class: can?(current_user, :update_issue, @issue) ? 'js-task-list-container' : ''} = preserve do
.wiki = markdown(@issue.description, cache_key: [@issue, "description"])
= preserve do %textarea.hidden.js-task-list-field
= markdown(@issue.description, cache_key: [@issue, "description"]) = @issue.description
%textarea.hidden.js-task-list-field
= @issue.description .merge-requests
= render 'merge_requests'
.merge-requests .gray-content-block.second-block.oneline-block
= render 'merge_requests' = render 'votes/votes_block', votable: @issue
- if @closed_by_merge_requests.present? - if @closed_by_merge_requests.present?
= render 'projects/issues/closed_by_box' = render 'projects/issues/closed_by_box'
.issue-discussion
.row
%section.col-md-9
.issuable-discussion
= render 'projects/issues/discussion' = render 'projects/issues/discussion'
%aside.col-md-3 %aside.col-md-3
......
...@@ -5,7 +5,4 @@ ...@@ -5,7 +5,4 @@
- if @merge_request.closed? - if @merge_request.closed?
= link_to 'Reopen', merge_request_path(@merge_request, merge_request: {state_event: :reopen }), method: :put, class: "btn btn-grouped btn-reopen reopen-mr-link js-note-target-reopen", title: "Reopen merge request" = link_to 'Reopen', merge_request_path(@merge_request, merge_request: {state_event: :reopen }), method: :put, class: "btn btn-grouped btn-reopen reopen-mr-link js-note-target-reopen", title: "Reopen merge request"
.gray-content-block.second-block.oneline-block
= render 'votes/votes_block', votable: @merge_request
#notes= render "projects/notes/notes_with_form" #notes= render "projects/notes/notes_with_form"
...@@ -23,15 +23,15 @@ ...@@ -23,15 +23,15 @@
= link_to url_for(params), data: {target: 'div#commits', action: 'commits', toggle: 'tab'} do = link_to url_for(params), data: {target: 'div#commits', action: 'commits', toggle: 'tab'} do
Commits Commits
%span.badge= @commits.size %span.badge= @commits.size
%li.diffs-tab.active
= link_to url_for(params), data: {target: 'div#diffs', action: 'diffs', toggle: 'tab'} do
Changes
%span.badge= @diffs.size
- if @ci_commit - if @ci_commit
%li.builds-tab.active %li.builds-tab.active
= link_to url_for(params), data: {target: 'div#builds', action: 'builds', toggle: 'tab'} do = link_to url_for(params), data: {target: 'div#builds', action: 'builds', toggle: 'tab'} do
Builds Builds
%span.badge= @statuses.size %span.badge= @statuses.size
%li.diffs-tab.active
= link_to url_for(params), data: {target: 'div#diffs', action: 'diffs', toggle: 'tab'} do
Changes
%span.badge= @diffs.size
.tab-content .tab-content
#commits.commits.tab-pane #commits.commits.tab-pane
......
...@@ -6,81 +6,83 @@ ...@@ -6,81 +6,83 @@
.merge-request{'data-url' => merge_request_path(@merge_request)} .merge-request{'data-url' => merge_request_path(@merge_request)}
= render "projects/merge_requests/show/mr_title" = render "projects/merge_requests/show/mr_title"
.merge-request-details.issuable-details
.row
%section.col-md-9
= render "projects/merge_requests/show/mr_box"
.append-bottom-default.mr-source-target.prepend-top-default
- if @merge_request.open?
.pull-right
- if @merge_request.source_branch_exists?
= link_to "#modal_merge_info", class: "btn btn-sm", "data-toggle" => "modal" do
= icon('cloud-download fw')
Check out branch
%span.dropdown .merge-request-details.issuable-details
%a.btn.btn-sm.dropdown-toggle{ data: {toggle: :dropdown} } = render "projects/merge_requests/show/mr_box"
= icon('download') .append-bottom-default.mr-source-target.prepend-top-default
Download as - if @merge_request.open?
%span.caret .pull-right
%ul.dropdown-menu - if @merge_request.source_branch_exists?
%li= link_to "Email Patches", merge_request_path(@merge_request, format: :patch) = link_to "#modal_merge_info", class: "btn btn-sm", "data-toggle" => "modal" do
%li= link_to "Plain Diff", merge_request_path(@merge_request, format: :diff) = icon('cloud-download fw')
.normal Check out branch
%span Request to merge
%span.label-branch= source_branch_with_namespace(@merge_request)
%span into
= link_to namespace_project_commits_path(@project.namespace, @project, @merge_request.target_branch), class: "label-branch" do
= @merge_request.target_branch
= render "projects/merge_requests/show/how_to_merge" %span.dropdown
= render "projects/merge_requests/widget/show.html.haml" %a.btn.btn-sm.dropdown-toggle{ data: {toggle: :dropdown} }
= icon('download')
Download as
%span.caret
%ul.dropdown-menu
%li= link_to "Email Patches", merge_request_path(@merge_request, format: :patch)
%li= link_to "Plain Diff", merge_request_path(@merge_request, format: :diff)
.normal
%span Request to merge
%span.label-branch= source_branch_with_namespace(@merge_request)
%span into
= link_to namespace_project_commits_path(@project.namespace, @project, @merge_request.target_branch), class: "label-branch" do
= @merge_request.target_branch
- if @merge_request.open? && @merge_request.source_branch_exists? && @merge_request.can_be_merged? && @merge_request.can_be_merged_by?(current_user) = render "projects/merge_requests/show/how_to_merge"
.light.prepend-top-default = render "projects/merge_requests/widget/show.html.haml"
You can also accept this merge request manually using the
= succeed '.' do
= link_to "command line", "#modal_merge_info", class: "how_to_merge_link vlink", title: "How To Merge", "data-toggle" => "modal"
- if @commits.present? - if @merge_request.open? && @merge_request.source_branch_exists? && @merge_request.can_be_merged? && @merge_request.can_be_merged_by?(current_user)
%ul.merge-request-tabs.center-top-menu.no-top.no-bottom .light.prepend-top-default
%li.notes-tab You can also accept this merge request manually using the
= link_to namespace_project_merge_request_path(@project.namespace, @project, @merge_request), data: {target: 'div#notes', action: 'notes', toggle: 'tab'} do = succeed '.' do
Discussion = link_to "command line", "#modal_merge_info", class: "how_to_merge_link vlink", title: "How To Merge", "data-toggle" => "modal"
%span.badge= @merge_request.mr_and_commit_notes.user.count
%li.commits-tab
= link_to commits_namespace_project_merge_request_path(@project.namespace, @project, @merge_request), data: {target: 'div#commits', action: 'commits', toggle: 'tab'} do
Commits
%span.badge= @commits.size
%li.diffs-tab
= link_to diffs_namespace_project_merge_request_path(@project.namespace, @project, @merge_request), data: {target: 'div#diffs', action: 'diffs', toggle: 'tab'} do
Changes
%span.badge= @merge_request.diffs.size
- if @ci_commit
%li.builds-tab
= link_to builds_namespace_project_merge_request_path(@project.namespace, @project, @merge_request), data: {target: '#builds', action: 'builds', toggle: 'tab'} do
Builds
%span.badge= @statuses.size
.tab-content - if @commits.present?
#notes.notes.tab-pane.voting_notes %ul.merge-request-tabs.center-top-menu.no-top.no-bottom
= render "projects/merge_requests/discussion" %li.notes-tab
#commits.commits.tab-pane = link_to namespace_project_merge_request_path(@project.namespace, @project, @merge_request), data: {target: 'div#notes', action: 'notes', toggle: 'tab'} do
- # This tab is always loaded via AJAX Discussion
#diffs.diffs.tab-pane %span.badge= @merge_request.mr_and_commit_notes.user.count
- # This tab is always loaded via AJAX %li.commits-tab
#builds.builds.tab-pane = link_to commits_namespace_project_merge_request_path(@project.namespace, @project, @merge_request), data: {target: 'div#commits', action: 'commits', toggle: 'tab'} do
- # This tab is always loaded via AJAX Commits
%span.badge= @commits.size
- if @ci_commit
%li.builds-tab
= link_to builds_namespace_project_merge_request_path(@project.namespace, @project, @merge_request), data: {target: '#builds', action: 'builds', toggle: 'tab'} do
Builds
%span.badge= @statuses.size
%li.diffs-tab
= link_to diffs_namespace_project_merge_request_path(@project.namespace, @project, @merge_request), data: {target: 'div#diffs', action: 'diffs', toggle: 'tab'} do
Changes
%span.badge= @merge_request.diffs.size
.mr-loading-status .tab-content
= spinner #notes.notes.tab-pane.voting_notes
.gray-content-block.second-block.oneline-block
= render 'votes/votes_block', votable: @merge_request
%aside.col-md-3 .row
= render 'shared/issuable/sidebar', issuable: @merge_request %section.col-md-9
.issuable-discussion
= render "projects/merge_requests/discussion"
%aside.col-md-3
= render 'shared/issuable/sidebar', issuable: @merge_request
= render 'shared/show_aside'
= render 'shared/show_aside' #commits.commits.tab-pane
- # This tab is always loaded via AJAX
#builds.builds.tab-pane
- # This tab is always loaded via AJAX
#diffs.diffs.tab-pane
- # This tab is always loaded via AJAX
.mr-loading-status
= spinner
:javascript :javascript
var merge_request; var merge_request;
......
.detail-page-description.gray-content-block.middle-block .detail-page-description.gray-content-block.second-block
%h2.title %h2.title
= markdown escape_once(@merge_request.title), pipeline: :single_line = markdown escape_once(@merge_request.title), pipeline: :single_line
......
...@@ -7,13 +7,13 @@ ...@@ -7,13 +7,13 @@
.accept-action .accept-action
- if @ci_commit && @ci_commit.active? - if @ci_commit && @ci_commit.active?
%span.btn-group %span.btn-group
= link_to "#", class: "btn btn-create merge_when_build_succeeds" do = button_tag class: "btn btn-create js-merge-button merge_when_build_succeeds" do
Merge When Build Succeeds Merge When Build Succeeds
%a.btn.btn-success.dropdown-toggle{ 'data-toggle' => 'dropdown' } = button_tag class: "btn btn-success dropdown-toggle", 'data-toggle' => 'dropdown' do
%span.caret %span.caret
%span.sr-only %span.sr-only
Select Merge Moment Select Merge Moment
%ul.dropdown-menu.dropdown-menu-right{ role: 'menu' } %ul.js-merge-dropdown.dropdown-menu.dropdown-menu-right{ role: 'menu' }
%li %li
= link_to "#", class: "merge_when_build_succeeds" do = link_to "#", class: "merge_when_build_succeeds" do
= icon('check fw') = icon('check fw')
...@@ -23,7 +23,7 @@ ...@@ -23,7 +23,7 @@
= icon('warning fw') = icon('warning fw')
Merge Immediately Merge Immediately
- else - else
= f.button class: "btn btn-create btn-grouped accept_merge_request #{status_class}" do = f.button class: "btn btn-create btn-grouped js-merge-button accept_merge_request #{status_class}" do
Accept Merge Request Accept Merge Request
- if @merge_request.can_remove_source_branch?(current_user) - if @merge_request.can_remove_source_branch?(current_user)
.accept-control.checkbox .accept-control.checkbox
...@@ -42,21 +42,19 @@ ...@@ -42,21 +42,19 @@
= hidden_field_tag :merge_when_build_succeeds, "", autocomplete: "off" = hidden_field_tag :merge_when_build_succeeds, "", autocomplete: "off"
:javascript :javascript
$('.accept_merge_request').on('click', function() {
$(this).html("<i class='fa fa-spinner fa-spin'></i> Merge in progress");
});
$('.accept-mr-form').on('ajax:send', function() { $('.accept-mr-form').on('ajax:send', function() {
$(".accept-mr-form :input").disable(); $(".accept-mr-form :input").disable();
}); });
$('a.accept_merge_request').on('click', function(e) { $('.accept_merge_request').on('click', function() {
e.preventDefault(); $('.js-merge-button').html("<i class='fa fa-spinner fa-spin'></i> Merge in progress");
$(this).closest("form").submit();
}); });
$('a.merge_when_build_succeeds').on('click', function(e) { $('.merge_when_build_succeeds').on('click', function() {
e.preventDefault();
$("#merge_when_build_succeeds").val("1"); $("#merge_when_build_succeeds").val("1");
});
$('.js-merge-dropdown a').on('click', function(e) {
e.preventDefault();
$(this).closest("form").submit(); $(this).closest("form").submit();
}); });
...@@ -20,16 +20,24 @@ ...@@ -20,16 +20,24 @@
%li %li
= link_to namespace_project_new_blob_path(@project.namespace, @project, @id), title: 'Create file', id: 'new-file-link' do = link_to namespace_project_new_blob_path(@project.namespace, @project, @id), title: 'Create file', id: 'new-file-link' do
= icon('pencil fw') = icon('pencil fw')
Create file New file
%li %li
= link_to '#modal-upload-blob', { 'data-target' => '#modal-upload-blob', 'data-toggle' => 'modal'} do = link_to '#modal-upload-blob', { 'data-target' => '#modal-upload-blob', 'data-toggle' => 'modal'} do
= icon('file fw') = icon('file fw')
Upload file Upload file
%li.divider
%li %li
= link_to '#modal-create-new-dir', { 'data-target' => '#modal-create-new-dir', 'data-toggle' => 'modal'} do = link_to '#modal-create-new-dir', { 'data-target' => '#modal-create-new-dir', 'data-toggle' => 'modal'} do
= icon('folder fw') = icon('folder fw')
New directory New directory
%li.divider
%li
= link_to new_namespace_project_branch_path(@project.namespace, @project) do
= icon('code-fork fw')
New branch
%li
= link_to new_namespace_project_tag_path(@project.namespace, @project) do
= icon('tags fw')
New tag
- elsif !on_top_of_branch? - elsif !on_top_of_branch?
%li %li
%span.btn.btn-sm.add-to-tree.disabled.has_tooltip{title: "You can only add files when you are on a branch.", data: {container: 'body'}} %span.btn.btn-sm.add-to-tree.disabled.has_tooltip{title: "You can only add files when you are on a branch.", data: {container: 'body'}}
......
...@@ -26,7 +26,8 @@ class MigrateCiToProject < ActiveRecord::Migration ...@@ -26,7 +26,8 @@ class MigrateCiToProject < ActiveRecord::Migration
def migrate_project_column(column, new_column = nil) def migrate_project_column(column, new_column = nil)
new_column ||= column new_column ||= column
subquery = "SELECT ci_projects.#{column} FROM ci_projects WHERE projects.id = ci_projects.gitlab_id" subquery = "SELECT ci_projects.#{column} FROM ci_projects WHERE projects.id = ci_projects.gitlab_id " \
'ORDER BY ci_projects.updated_at DESC LIMIT 1'
execute("UPDATE projects SET #{new_column}=(#{subquery}) WHERE (#{subquery}) IS NOT NULL") execute("UPDATE projects SET #{new_column}=(#{subquery}) WHERE (#{subquery}) IS NOT NULL")
end end
......
...@@ -139,6 +139,21 @@ Parameters: ...@@ -139,6 +139,21 @@ Parameters:
- `sort` (optional) - Return requests sorted in `asc` or `desc` order. Default is `desc` - `sort` (optional) - Return requests sorted in `asc` or `desc` order. Default is `desc`
- `search` (optional) - Return list of authorized projects according to a search criteria - `search` (optional) - Return list of authorized projects according to a search criteria
### List starred projects
Get a list of projects which are starred by the authenticated user.
```
GET /projects/starred
```
Parameters:
- `archived` (optional) - if passed, limit by archived status
- `order_by` (optional) - Return requests ordered by `id`, `name`, `path`, `created_at`, `updated_at` or `last_activity_at` fields. Default is `created_at`
- `sort` (optional) - Return requests sorted in `asc` or `desc` order. Default is `desc`
- `search` (optional) - Return list of authorized projects according to a search criteria
### List ALL projects ### List ALL projects
Get a list of all GitLab projects (admin only). Get a list of all GitLab projects (admin only).
......
# Using Docker Images # Using Docker Images
GitLab CI in conjuction with [GitLab Runner](../runners/README.md) can use GitLab CI in conjunction with [GitLab Runner](../runners/README.md) can use
[Docker Engine](https://www.docker.com/) to test and build any application. [Docker Engine](https://www.docker.com/) to test and build any application.
Docker is an open-source project that allows you to use predefined images to Docker is an open-source project that allows you to use predefined images to
run applications in independent "containers" that are run within a single Linux run applications in independent "containers" that are run within a single Linux
instance. [Docker Hub][hub] has a rich database of prebuilt images that can be instance. [Docker Hub][hub] has a rich database of pre-built images that can be
used to test and build your applications. used to test and build your applications.
Docker, when used with GitLab CI, runs each build in a separate and isolated Docker, when used with GitLab CI, runs each build in a separate and isolated
...@@ -136,6 +136,24 @@ Look for the `[runners.docker]` section: ...@@ -136,6 +136,24 @@ Look for the `[runners.docker]` section:
The image and services defined this way will be added to all builds run by The image and services defined this way will be added to all builds run by
that runner. that runner.
## Define an image from a private Docker registry
Starting with GitLab Runner 0.6.0, you are able to define images located to
private registries that could also require authentication.
All you have to do is be explicit on the image definition in `.gitlab-ci.yml`.
```yaml
image: my.registry.tld:5000/namepace/image:tag
```
In the example above, GitLab Runner will look at `my.registry.tld:5000` for the
image `namespace/image:tag`.
If the repository is private you need to authenticate your GitLab Runner in the
registry. Learn how to do that on
[GitLab Runner's documentation][runner-priv-reg].
## Accessing the services ## Accessing the services
Let's say that you need a Wordpress instance to test some API integration with Let's say that you need a Wordpress instance to test some API integration with
...@@ -258,3 +276,4 @@ creation. ...@@ -258,3 +276,4 @@ creation.
[tutum/wordpress]: https://registry.hub.docker.com/u/tutum/wordpress/ [tutum/wordpress]: https://registry.hub.docker.com/u/tutum/wordpress/
[postgres-hub]: https://registry.hub.docker.com/u/library/postgres/ [postgres-hub]: https://registry.hub.docker.com/u/library/postgres/
[mysql-hub]: https://registry.hub.docker.com/u/library/mysql/ [mysql-hub]: https://registry.hub.docker.com/u/library/mysql/
[runner-priv-reg]: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/configuration/advanced-configuration.md#using-a-private-docker-registry
# Configuration of your builds with .gitlab-ci.yml # Configuration of your builds with .gitlab-ci.yml
From version 7.12, GitLab CI uses a [YAML](https://en.wikipedia.org/wiki/YAML) file (**.gitlab-ci.yml**) for the project configuration.
It is placed in the root of your repository and contains definitions of how your project should be built.
The YAML file defines a set of jobs with constraints stating when they should be run. From version 7.12, GitLab CI uses a [YAML](https://en.wikipedia.org/wiki/YAML)
The jobs are defined as top-level elements with a name and always have to contain the `script` clause: file (`.gitlab-ci.yml`) for the project configuration. It is placed in the root
of your repository and contains definitions of how your project should be built.
The YAML file defines a set of jobs with constraints stating when they should
be run. The jobs are defined as top-level elements with a name and always have
to contain the `script` clause:
```yaml ```yaml
job1: job1:
...@@ -13,15 +16,21 @@ job2: ...@@ -13,15 +16,21 @@ job2:
script: "execute-script-for-job2" script: "execute-script-for-job2"
``` ```
The above example is the simplest possible CI configuration with two separate jobs, The above example is the simplest possible CI configuration with two separate
where each of the jobs executes a different command. jobs, where each of the jobs executes a different command.
Of course a command can execute code directly (`./configure;make;make install`) or run a script (`test.sh`) in the repository.
Of course a command can execute code directly (`./configure;make;make install`)
or run a script (`test.sh`) in the repository.
Jobs are used to create builds, which are then picked up by [runners](../runners/README.md) and executed within the environment of the runner. Jobs are used to create builds, which are then picked up by
What is important, is that each job is run independently from each other. [runners](../runners/README.md) and executed within the environment of the
runner. What is important, is that each job is run independently from each
other.
## .gitlab-ci.yml ## .gitlab-ci.yml
The YAML syntax allows for using more complex job specifications than in the above example:
The YAML syntax allows for using more complex job specifications than in the
above example:
```yaml ```yaml
image: ruby:2.1 image: ruby:2.1
...@@ -46,26 +55,31 @@ job1: ...@@ -46,26 +55,31 @@ job1:
- docker - docker
``` ```
There are a few `keywords` that can't be used as job names: There are a few reserved `keywords` that **cannot** be used as job names:
| keyword | required | description | | Keyword | Required | Description |
|---------------|----------|-------------| |---------------|----------|-------------|
| image | optional | Use docker image, covered in [Use Docker](../docker/README.md) | | image | no | Use docker image, covered in [Use Docker](../docker/README.md) |
| services | optional | Use docker services, covered in [Use Docker](../docker/README.md) | | services | no | Use docker services, covered in [Use Docker](../docker/README.md) |
| stages | optional | Define build stages | | stages | no | Define build stages |
| types | optional | Alias for `stages` | | types | no | Alias for `stages` |
| before_script | optional | Define commands prepended for each job's script | | before_script | no | Define commands that run before each job's script |
| variables | optional | Define build variables | | variables | no | Define build variables |
| cache | optional | Define list of files that should be cached between subsequent runs | | cache | no | Define list of files that should be cached between subsequent runs |
### image and services ### image and services
This allows to specify a custom Docker image and a list of services that can be used for time of the build.
The configuration of this feature is covered in separate document: [Use Docker](../docker/README.md). This allows to specify a custom Docker image and a list of services that can be
used for time of the build. The configuration of this feature is covered in
separate document: [Use Docker](../docker/README.md).
### before_script ### before_script
`before_script` is used to define the command that should be run before all builds, including deploy builds. This can be an array or a multiline string.
`before_script` is used to define the command that should be run before all
builds, including deploy builds. This can be an array or a multi-line string.
### stages ### stages
`stages` is used to define build stages that can be used by jobs. `stages` is used to define build stages that can be used by jobs.
The specification of `stages` allows for having flexible multi stage pipelines. The specification of `stages` allows for having flexible multi stage pipelines.
...@@ -75,7 +89,8 @@ The ordering of elements in `stages` defines the ordering of builds' execution: ...@@ -75,7 +89,8 @@ The ordering of elements in `stages` defines the ordering of builds' execution:
1. Builds of next stage are run after success. 1. Builds of next stage are run after success.
Let's consider the following example, which defines 3 stages: Let's consider the following example, which defines 3 stages:
```
```yaml
stages: stages:
- build - build
- test - test
...@@ -86,21 +101,26 @@ stages: ...@@ -86,21 +101,26 @@ stages:
1. If all jobs of `build` succeeds, the `test` jobs are executed in parallel. 1. If all jobs of `build` succeeds, the `test` jobs are executed in parallel.
1. If all jobs of `test` succeeds, the `deploy` jobs are executed in parallel. 1. If all jobs of `test` succeeds, the `deploy` jobs are executed in parallel.
1. If all jobs of `deploy` succeeds, the commit is marked as `success`. 1. If all jobs of `deploy` succeeds, the commit is marked as `success`.
1. If any of the previous jobs fails, the commit is marked as `failed` and no jobs of further stage are executed. 1. If any of the previous jobs fails, the commit is marked as `failed` and no
jobs of further stage are executed.
There are also two edge cases worth mentioning: There are also two edge cases worth mentioning:
1. If no `stages` is defined in `.gitlab-ci.yml`, then by default the `build`, `test` and `deploy` are allowed to be used as job's stage by default. 1. If no `stages` is defined in `.gitlab-ci.yml`, then by default the `build`,
`test` and `deploy` are allowed to be used as job's stage by default.
2. If a job doesn't specify `stage`, the job is assigned the `test` stage. 2. If a job doesn't specify `stage`, the job is assigned the `test` stage.
### types ### types
Alias for [stages](#stages). Alias for [stages](#stages).
### variables ### variables
**This feature requires `gitlab-runner` with version equal or greater than 0.5.0.**
GitLab CI allows you to add to `.gitlab-ci.yml` variables that are set in build environment. _**Note:** Introduced in GitLab Runner v0.5.0._
The variables are stored in repository and are meant to store non-sensitive project configuration, ie. RAILS_ENV or DATABASE_URL.
GitLab CI allows you to add to `.gitlab-ci.yml` variables that are set in build
environment. The variables are stored in the git repository and are meant to
store non-sensitive project configuration, for example:
```yaml ```yaml
variables: variables:
...@@ -109,18 +129,23 @@ variables: ...@@ -109,18 +129,23 @@ variables:
These variables can be later used in all executed commands and scripts. These variables can be later used in all executed commands and scripts.
The YAML-defined variables are also set to all created service containers, thus allowing to fine tune them. The YAML-defined variables are also set to all created service containers,
thus allowing to fine tune them.
### cache ### cache
`cache` is used to specify list of files and directories which should be cached between builds.
Caches are stored according to the branch/ref and the job name. Caches are not
currently shared between different job names or between branches/refs. This means
caching will benefit you if you push subsequent commits to an existing feature branch.
**The global setting allows to specify default cached files for all jobs.** `cache` is used to specify a list of files and directories which should be
cached between builds. Caches are stored according to the branch/ref and the
job name. They are not currently shared between different job names or between
branches/refs, which means that caching will benefit you if you push subsequent
commits to an existing feature branch.
If `cache` is defined outside the scope of the jobs, it means it is set
globally and all jobs will use its definition.
To cache all git untracked files and files in `binaries`: To cache all git untracked files and files in `binaries`:
```
```yaml
cache: cache:
untracked: true untracked: true
paths: paths:
...@@ -128,9 +153,10 @@ cache: ...@@ -128,9 +153,10 @@ cache:
``` ```
## Jobs ## Jobs
`.gitlab-ci.yml` allows you to specify an unlimited number of jobs.
Each job has to have a unique `job_name`, which is not one of the keywords mentioned above. `.gitlab-ci.yml` allows you to specify an unlimited number of jobs. Each job
A job is defined by a list of parameters that define the build behaviour. must have a unique name, which is not one of the Keywords mentioned above.
A job is defined by a list of parameters that define the build behavior.
```yaml ```yaml
job_name: job_name:
...@@ -148,21 +174,22 @@ job_name: ...@@ -148,21 +174,22 @@ job_name:
allow_failure: true allow_failure: true
``` ```
| keyword | required | description | | Keyword | Required | Description |
|---------------|----------|-------------| |---------------|----------|-------------|
| script | required | Defines a shell script which is executed by runner | | script | yes | Defines a shell script which is executed by runner |
| stage | optional (default: test) | Defines a build stage | | stage | no (default: `test`) | Defines a build stage |
| type | optional | Alias for `stage` | | type | no | Alias for `stage` |
| only | optional | Defines a list of git refs for which build is created | | only | no | Defines a list of git refs for which build is created |
| except | optional | Defines a list of git refs for which build is not created | | except | no | Defines a list of git refs for which build is not created |
| tags | optional | Defines a list of tags which are used to select runner | | tags | no | Defines a list of tags which are used to select runner |
| allow_failure | optional | Allow build to fail. Failed build doesn't contribute to commit status | | allow_failure | no | Allow build to fail. Failed build doesn't contribute to commit status |
| when | optional | Define when to run build. Can be `on_success`, `on_failure` or `always` | | when | no | Define when to run build. Can be `on_success`, `on_failure` or `always` |
| artifacts | optional | Define list build artifacts | | artifacts | no | Define list build artifacts |
| cache | optional | Define list of files that should be cached between subsequent runs | | cache | no | Define list of files that should be cached between subsequent runs |
### script ### script
`script` is a shell script which is executed by runner. The shell script is prepended with `before_script`.
`script` is a shell script which is executed by the runner. For example:
```yaml ```yaml
job: job:
...@@ -170,6 +197,7 @@ job: ...@@ -170,6 +197,7 @@ job:
``` ```
This parameter can also contain several commands using an array: This parameter can also contain several commands using an array:
```yaml ```yaml
job: job:
script: script:
...@@ -178,31 +206,45 @@ job: ...@@ -178,31 +206,45 @@ job:
``` ```
### stage ### stage
`stage` allows to group build into different stages. Builds of the same `stage` are executed in `parallel`.
For more info about the use of `stage` please check the [stages](#stages). `stage` allows to group build into different stages. Builds of the same `stage`
are executed in `parallel`. For more info about the use of `stage` please check
[stages](#stages).
### only and except ### only and except
This are two parameters that allow for setting a refs policy to limit when jobs are built:
1. `only` defines the names of branches and tags for which job will be built.
2. `except` defines the names of branches and tags for which the job wil **not** be built.
There are a few rules that apply to usage of refs policy: `only` and `except` are two parameters that set a refs policy to limit when
jobs are built:
1. `only` and `except` are inclusive. If both `only` and `except` are defined in job specification the ref is filtered by `only` and `except`. 1. `only` defines the names of branches and tags for which the job will be
1. `only` and `except` allow for using the regexp expressions. built.
1. `only` and `except` allow for using special keywords: `branches` and `tags`. 2. `except` defines the names of branches and tags for which the job will
These names can be used for example to exclude all tags and all branches. **not** be built.
There are a few rules that apply to the usage of refs policy:
* `only` and `except` are inclusive. If both `only` and `except` are defined
in a job specification, the ref is filtered by `only` and `except`.
* `only` and `except` allow the use of regular expressions.
* `only` and `except` allow the use of special keywords: `branches` and `tags`.
* `only` and `except` allow to specify a repository path to filter jobs for
forks.
In the example below, `job` will run only for refs that start with `issue-`,
whereas all branches will be skipped.
```yaml ```yaml
job: job:
# use regexp
only: only:
- /^issue-.*$/ # use regexp - /^issue-.*$/
# use special keyword
except: except:
- branches # use special keyword - branches
``` ```
1. `only` and `except` allow for specify repository path to filter jobs for forks. The repository path can be used to have jobs executed only for the parent
The repository path can be used to have jobs executed only for parent repository. repository and not forks:
```yaml ```yaml
job: job:
...@@ -211,33 +253,47 @@ job: ...@@ -211,33 +253,47 @@ job:
except: except:
- master@gitlab-org/gitlab-ce - master@gitlab-org/gitlab-ce
``` ```
The above will run `job` for all branches on `gitlab-org/gitlab-ce`, except master .
The above example will run `job` for all branches on `gitlab-org/gitlab-ce`,
except master.
### tags ### tags
`tags` is used to select specific runners from the list of all runners that are allowed to run this project.
During registration of a runner, you can specify the runner's tags, ie.: `ruby`, `postgres`, `development`. `tags` is used to select specific runners from the list of all runners that are
`tags` allow you to run builds with runners that have the specified tags assigned: allowed to run this project.
``` During the registration of a runner, you can specify the runner's tags, for
example `ruby`, `postgres`, `development`.
`tags` allow you to run builds with runners that have the specified tags
assigned to them:
```yaml
job: job:
tags: tags:
- ruby - ruby
- postgres - postgres
``` ```
The above specification will make sure that `job` is built by a runner that have `ruby` AND `postgres` tags defined. The specification above, will make sure that `job` is built by a runner that
has both `ruby` AND `postgres` tags defined.
### when ### when
`when` is used to implement jobs that are run in case of failure or despite the failure.
`when` is used to implement jobs that are run in case of failure or despite the
failure.
`when` can be set to one of the following values: `when` can be set to one of the following values:
1. `on_success` - execute build only when all builds from prior stages succeeded. This is the default. 1. `on_success` - execute build only when all builds from prior stages
1. `on_failure` - execute build only when at least one build from prior stages failed. succeeded. This is the default.
1. `on_failure` - execute build only when at least one build from prior stages
failed.
1. `always` - execute build despite the status of builds from prior stages. 1. `always` - execute build despite the status of builds from prior stages.
``` For example:
```yaml
stages: stages:
- build - build
- cleanup_build - cleanup_build
...@@ -245,28 +301,28 @@ stages: ...@@ -245,28 +301,28 @@ stages:
- deploy - deploy
- cleanup - cleanup
build: build_job:
stage: build stage: build
script: script:
- make build - make build
cleanup_build: cleanup_build_job:
stage: cleanup_build stage: cleanup_build
script: script:
- cleanup build when failed - cleanup build when failed
when: on_failure when: on_failure
test: test_job:
stage: test stage: test
script: script:
- make test - make test
deploy: deploy_job:
stage: deploy stage: deploy
script: script:
- make deploy - make deploy
cleanup: cleanup_job:
stage: cleanup stage: cleanup
script: script:
- cleanup after builds - cleanup after builds
...@@ -274,84 +330,107 @@ cleanup: ...@@ -274,84 +330,107 @@ cleanup:
``` ```
The above script will: The above script will:
1. Execute `cleanup_build` only when the `build` failed,
2. Always execute `cleanup` as the last step in pipeline. 1. Execute `cleanup_build_job` only when `build_job` fails
2. Always execute `cleanup_job` as the last step in pipeline.
### artifacts ### artifacts
`artifacts` is used to specify list of files and directories which should be attached to build after success.
1. Send all files in `binaries` and `.config`: _**Note:** Introduced in GitLab Runner v0.7.0._
artifacts: `artifacts` is used to specify list of files and directories which should be
paths: attached to build after success. Below are some examples.
- binaries/
- .config
2. Send all git untracked files: Send all files in `binaries` and `.config`:
artifacts: ```yaml
untracked: true artifacts:
paths:
- binaries/
- .config
```
3. Send all git untracked files and files in `binaries`: Send all git untracked files:
artifacts: ```yaml
untracked: true artifacts:
paths: untracked: true
- binaries/ ```
Send all git untracked files and files in `binaries`:
The artifacts will be send after the build success to GitLab and will be accessible in GitLab interface to download. ```yaml
artifacts:
untracked: true
paths:
- binaries/
```
This feature requires GitLab Runner v0.7.0 or higher. The artifacts will be send after a successful build success to GitLab, and will
be accessible in the GitLab UI to download.
### cache ### cache
`cache` is used to specify list of files and directories which should be cached between builds.
1. Cache all files in `binaries` and `.config`: _**Note:** Introduced in GitLab Runner v0.7.0._
rspec: `cache` is used to specify list of files and directories which should be cached
script: test between builds. Below are some examples:
cache:
paths:
- binaries/
- .config
2. Cache all git untracked files: Cache all files in `binaries` and `.config`:
rspec: ```yaml
script: test rspec:
cache: script: test
untracked: true cache:
paths:
3. Cache all git untracked files and files in `binaries`: - binaries/
- .config
```
rspec: Cache all git untracked files:
script: test
cache:
untracked: true
paths:
- binaries/
4. Locally defined cache overwrites globally defined options. This will cache only `binaries/`: ```yaml
rspec:
script: test
cache:
untracked: true
```
Cache all git untracked files and files in `binaries`:
```yaml
rspec:
script: test
cache:
untracked: true
paths:
- binaries/
```
cache: Locally defined cache overwrites globally defined options. This will cache only
paths: `binaries/`:
- my/files
rspec:
script: test
cache:
paths:
- binaries/
The cache is provided on best effort basis, so don't expect that cache will be present. ```yaml
For implementation details please check GitLab Runner. cache:
paths:
- my/files
This feature requires GitLab Runner v0.7.0 or higher. rspec:
script: test
cache:
paths:
- binaries/
```
The cache is provided on best effort basis, so don't expect that cache will be
always present. For implementation details please check GitLab Runner.
## Validate the .gitlab-ci.yml ## Validate the .gitlab-ci.yml
Each instance of GitLab CI has an embedded debug tool called Lint. Each instance of GitLab CI has an embedded debug tool called Lint.
You can find the link to the Lint in the project's settings page or use short url `/lint`. You can find the link under `/ci/lint` of your gitlab instance.
## Skipping builds ## Skipping builds
There is one more way to skip all builds, if your commit message contains tag [ci skip]. In this case, commit will be created but builds will be skipped
If your commit message contains `[ci skip]`, the commit will be created but the
builds will be skipped.
...@@ -348,7 +348,7 @@ GitLab Shell is an SSH access and repository management software developed speci ...@@ -348,7 +348,7 @@ GitLab Shell is an SSH access and repository management software developed speci
cd /home/git cd /home/git
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-workhorse.git sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-workhorse.git
cd gitlab-workhorse cd gitlab-workhorse
sudo -u git -H git checkout 0.5.0 sudo -u git -H git checkout 0.5.1
sudo -u git -H make sudo -u git -H make
### Initialize Database and Activate Advanced Features ### Initialize Database and Activate Advanced Features
......
...@@ -67,7 +67,7 @@ sudo -u git -H git checkout 8-3-stable-ee ...@@ -67,7 +67,7 @@ sudo -u git -H git checkout 8-3-stable-ee
```bash ```bash
cd /home/git/gitlab-shell cd /home/git/gitlab-shell
sudo -u git -H git fetch --all sudo -u git -H git fetch --all
sudo -u git -H git checkout v2.6.8 sudo -u git -H git checkout v2.6.9
``` ```
### 5. Update gitlab-workhorse ### 5. Update gitlab-workhorse
...@@ -78,7 +78,7 @@ which should already be on your system from GitLab 8.1. ...@@ -78,7 +78,7 @@ which should already be on your system from GitLab 8.1.
```bash ```bash
cd /home/git/gitlab-workhorse cd /home/git/gitlab-workhorse
sudo -u git -H git fetch --all sudo -u git -H git fetch --all
sudo -u git -H git checkout 0.5.0 sudo -u git -H git checkout 0.5.1
sudo -u git -H make sudo -u git -H make
``` ```
......
...@@ -41,7 +41,8 @@ class Spinach::Features::ProjectForkedMergeRequests < Spinach::FeatureSteps ...@@ -41,7 +41,8 @@ class Spinach::Features::ProjectForkedMergeRequests < Spinach::FeatureSteps
click_button "Compare branches and continue" click_button "Compare branches and continue"
expect(page).to have_content "New Merge Request" expect(page).to have_css("h3.page-title", text: "New Merge Request")
fill_in "merge_request_title", with: "Merge Request On Forked Project" fill_in "merge_request_title", with: "Merge Request On Forked Project"
end end
......
...@@ -166,7 +166,7 @@ module SharedDiffNote ...@@ -166,7 +166,7 @@ module SharedDiffNote
end end
step 'I should see add a diff comment button' do step 'I should see add a diff comment button' do
expect(page).to have_css('.js-add-diff-note-button', visible: true) expect(page).to have_css('.js-add-diff-note-button')
end end
step 'I should see an empty diff comment form' do step 'I should see an empty diff comment form' do
......
...@@ -70,7 +70,7 @@ module API ...@@ -70,7 +70,7 @@ module API
expose :forked_from_project, using: Entities::ForkedFromProject, if: lambda{ |project, options| project.forked? } expose :forked_from_project, using: Entities::ForkedFromProject, if: lambda{ |project, options| project.forked? }
expose :avatar_url expose :avatar_url
expose :star_count, :forks_count expose :star_count, :forks_count
expose :open_issues_count, if: lambda { | project, options | project.issues_enabled? && project.default_issues_tracker? } expose :open_issues_count, if: lambda { |project, options| project.issues_enabled? && project.default_issues_tracker? }
end end
class ProjectMember < UserBasic class ProjectMember < UserBasic
......
...@@ -39,6 +39,17 @@ module API ...@@ -39,6 +39,17 @@ module API
present @projects, with: Entities::Project present @projects, with: Entities::Project
end end
# Gets starred project for the authenticated user
#
# Example Request:
# GET /projects/starred
get '/starred' do
@projects = current_user.starred_projects
@projects = filter_projects(@projects)
@projects = paginate @projects
present @projects, with: Entities::Project
end
# Get all projects for admin user # Get all projects for admin user
# #
# Example Request: # Example Request:
......
...@@ -21,12 +21,12 @@ feature 'Merge When Build Succeeds', feature: true, js: true do ...@@ -21,12 +21,12 @@ feature 'Merge When Build Succeeds', feature: true, js: true do
end end
it 'displays the Merge When Build Succeeds button' do it 'displays the Merge When Build Succeeds button' do
expect(page).to have_link "Merge When Build Succeeds" expect(page).to have_button "Merge When Build Succeeds"
end end
context "Merge When Build succeeds enabled" do context "Merge When Build succeeds enabled" do
before do before do
click_link "Merge When Build Succeeds" click_button "Merge When Build Succeeds"
end end
it 'activates Merge When Build Succeeds feature' do it 'activates Merge When Build Succeeds feature' do
...@@ -58,7 +58,7 @@ feature 'Merge When Build Succeeds', feature: true, js: true do ...@@ -58,7 +58,7 @@ feature 'Merge When Build Succeeds', feature: true, js: true do
it 'cancels the automatic merge' do it 'cancels the automatic merge' do
click_link "Cancel Automatic Merge" click_link "Cancel Automatic Merge"
expect(page).to have_link "Merge When Build Succeeds" expect(page).to have_button "Merge When Build Succeeds"
visit_merge_request(merge_request) # Needed to refresh the page visit_merge_request(merge_request) # Needed to refresh the page
expect(page).to have_content "Canceled the automatic merge" expect(page).to have_content "Canceled the automatic merge"
......
...@@ -139,6 +139,25 @@ describe API::API, api: true do ...@@ -139,6 +139,25 @@ describe API::API, api: true do
end end
end end
describe 'GET /projects/starred' do
before do
admin.starred_projects << project
admin.save!
end
it 'should return the starred projects' do
get api('/projects/all', admin)
expect(response.status).to eq(200)
expect(json_response).to be_an Array
expect(json_response).to satisfy do |response|
response.one? do |entry|
entry['name'] == project.name
end
end
end
end
describe 'POST /projects' do describe 'POST /projects' do
context 'maximum number of projects reached' do context 'maximum number of projects reached' do
it 'should not create new project and respond with 403' do it 'should not create new project and respond with 403' do
...@@ -471,7 +490,7 @@ describe API::API, api: true do ...@@ -471,7 +490,7 @@ describe API::API, api: true do
end end
end end
describe 'PUT /projects/:id/snippets/:shippet_id' do describe 'PUT /projects/:id/snippets/:snippet_id' do
it 'should update an existing project snippet' do it 'should update an existing project snippet' do
put api("/projects/#{project.id}/snippets/#{snippet.id}", user), put api("/projects/#{project.id}/snippets/#{snippet.id}", user),
code: 'updated code' code: 'updated code'
......
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