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