Commit 7e375506 authored by GitLab Bot's avatar GitLab Bot

Automatic merge of gitlab-org/gitlab-ce master

parents 055ae8bf 87f665e8
...@@ -21,6 +21,7 @@ module MergeRequests ...@@ -21,6 +21,7 @@ module MergeRequests
post_merge_manually_merged post_merge_manually_merged
reload_merge_requests reload_merge_requests
outdate_suggestions outdate_suggestions
refresh_pipelines_on_merge_requests
reset_merge_when_pipeline_succeeds reset_merge_when_pipeline_succeeds
mark_pending_todos_done mark_pending_todos_done
cache_merge_requests_closing_issues cache_merge_requests_closing_issues
...@@ -107,8 +108,6 @@ module MergeRequests ...@@ -107,8 +108,6 @@ module MergeRequests
end end
merge_request.mark_as_unchecked merge_request.mark_as_unchecked
create_pipeline_for(merge_request, current_user)
UpdateHeadPipelineForMergeRequestWorker.perform_async(merge_request.id)
end end
# Upcoming method calls need the refreshed version of # Upcoming method calls need the refreshed version of
...@@ -134,6 +133,13 @@ module MergeRequests ...@@ -134,6 +133,13 @@ module MergeRequests
end end
end end
def refresh_pipelines_on_merge_requests
merge_requests_for_source_branch.each do |merge_request|
create_pipeline_for(merge_request, current_user)
UpdateHeadPipelineForMergeRequestWorker.perform_async(merge_request.id)
end
end
def reset_merge_when_pipeline_succeeds def reset_merge_when_pipeline_succeeds
merge_requests_for_source_branch.each(&:reset_merge_when_pipeline_succeeds) merge_requests_for_source_branch.each(&:reset_merge_when_pipeline_succeeds)
end end
......
---
title: Create pipelines for merge requests only when source branch is updated
merge_request: 26921
author:
type: fixed
...@@ -303,20 +303,19 @@ services: ...@@ -303,20 +303,19 @@ services:
- docker:dind - docker:dind
variables: variables:
CONTAINER_IMAGE: registry.gitlab.com/$CI_PROJECT_PATH
DOCKER_HOST: tcp://docker:2375 DOCKER_HOST: tcp://docker:2375
DOCKER_DRIVER: overlay2 DOCKER_DRIVER: overlay2
before_script: before_script:
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN registry.gitlab.com - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
build: build:
stage: build stage: build
script: script:
- docker pull $CONTAINER_IMAGE:latest || true - docker pull $CI_REGISTRY_IMAGE:latest || true
- docker build --cache-from $CONTAINER_IMAGE:latest --tag $CONTAINER_IMAGE:$CI_COMMIT_SHA --tag $CONTAINER_IMAGE:latest . - docker build --cache-from $CI_REGISTRY_IMAGE:latest --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --tag $CI_REGISTRY_IMAGE:latest .
- docker push $CONTAINER_IMAGE:$CI_COMMIT_SHA - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
- docker push $CONTAINER_IMAGE:latest - docker push $CI_REGISTRY_IMAGE:latest
``` ```
The steps in the `script` section for the `build` stage can be summed up to: The steps in the `script` section for the `build` stage can be summed up to:
...@@ -324,7 +323,7 @@ The steps in the `script` section for the `build` stage can be summed up to: ...@@ -324,7 +323,7 @@ The steps in the `script` section for the `build` stage can be summed up to:
1. The first command tries to pull the image from the registry so that it can be 1. The first command tries to pull the image from the registry so that it can be
used as a cache for the `docker build` command. used as a cache for the `docker build` command.
1. The second command builds a Docker image using the pulled image as a 1. The second command builds a Docker image using the pulled image as a
cache (notice the `--cache-from $CONTAINER_IMAGE:latest` argument) if cache (notice the `--cache-from $CI_REGISTRY_IMAGE:latest` argument) if
available, and tags it. available, and tags it.
1. The last two commands push the tagged Docker images to the container registry 1. The last two commands push the tagged Docker images to the container registry
so that they may also be used as cache for subsequent builds. so that they may also be used as cache for subsequent builds.
...@@ -421,14 +420,14 @@ and depend on the visibility of your project. ...@@ -421,14 +420,14 @@ and depend on the visibility of your project.
For all projects, mostly suitable for public ones: For all projects, mostly suitable for public ones:
- **Using the special `gitlab-ci-token` user**: This user is created for you in order to - **Using the special `$CI_REGISTRY_USER` variable**: The user specified by this variable is created for you in order to
push to the Registry connected to your project. Its password is automatically push to the Registry connected to your project. Its password is automatically
set with the `$CI_JOB_TOKEN` variable. This allows you to automate building and deploying set with the `$CI_REGISTRY_PASSWORD` variable. This allows you to automate building and deploying
your Docker images and has read/write access to the Registry. This is ephemeral, your Docker images and has read/write access to the Registry. This is ephemeral,
so it's only valid for one job. You can use the following example as-is: so it's only valid for one job. You can use the following example as-is:
```sh ```sh
docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
``` ```
For private and internal projects: For private and internal projects:
...@@ -436,8 +435,10 @@ For private and internal projects: ...@@ -436,8 +435,10 @@ For private and internal projects:
- **Using a personal access token**: You can create and use a - **Using a personal access token**: You can create and use a
[personal access token](../../user/profile/personal_access_tokens.md) [personal access token](../../user/profile/personal_access_tokens.md)
in case your project is private: in case your project is private:
- For read (pull) access, the scope should be `read_registry`.
- For read/write (pull/push) access, use `api`. - For read (pull) access, the scope should be `read_registry`.
- For read/write (pull/push) access, use `api`.
Replace the `<username>` and `<access_token>` in the following example: Replace the `<username>` and `<access_token>` in the following example:
```sh ```sh
...@@ -469,9 +470,9 @@ could look like: ...@@ -469,9 +470,9 @@ could look like:
DOCKER_DRIVER: overlay2 DOCKER_DRIVER: overlay2
stage: build stage: build
script: script:
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN registry.example.com - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t registry.example.com/group/project/image:latest . - docker build -t $CI_REGISTRY/group/project/image:latest .
- docker push registry.example.com/group/project/image:latest - docker push $CI_REGISTRY/group/project/image:latest
``` ```
You can also make use of [other variables](../variables/README.md) to avoid hardcoding: You can also make use of [other variables](../variables/README.md) to avoid hardcoding:
...@@ -486,7 +487,7 @@ variables: ...@@ -486,7 +487,7 @@ variables:
IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
before_script: before_script:
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
build: build:
stage: build stage: build
...@@ -526,7 +527,7 @@ variables: ...@@ -526,7 +527,7 @@ variables:
CONTAINER_RELEASE_IMAGE: $CI_REGISTRY_IMAGE:latest CONTAINER_RELEASE_IMAGE: $CI_REGISTRY_IMAGE:latest
before_script: before_script:
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
build: build:
stage: build stage: build
......
...@@ -38,7 +38,7 @@ _For consistency purposes, we recommend you to follow the same structure._ ...@@ -38,7 +38,7 @@ _For consistency purposes, we recommend you to follow the same structure._
Let's look into each of them: Let's look into each of them:
### A `index.js` file ### An `index.js` file
This is the index file of your new feature. This is where the root Vue instance This is the index file of your new feature. This is where the root Vue instance
of the new feature should be. of the new feature should be.
...@@ -46,7 +46,7 @@ of the new feature should be. ...@@ -46,7 +46,7 @@ of the new feature should be.
The Store and the Service should be imported and initialized in this file and The Store and the Service should be imported and initialized in this file and
provided as a prop to the main component. provided as a prop to the main component.
Don't forget to follow [these steps][page_specific_javascript]. Be sure to read about [page-specific JavaScript][page_specific_javascript].
### Bootstrapping Gotchas ### Bootstrapping Gotchas
#### Providing data from HAML to JavaScript #### Providing data from HAML to JavaScript
...@@ -240,7 +240,7 @@ One should apply to be a Vue.js expert by opening an MR when the Merge Request's ...@@ -240,7 +240,7 @@ One should apply to be a Vue.js expert by opening an MR when the Merge Request's
[vue-docs]: http://vuejs.org/guide/index.html [vue-docs]: http://vuejs.org/guide/index.html
[issue-boards]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/assets/javascripts/boards [issue-boards]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/assets/javascripts/boards
[environments-table]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/assets/javascripts/environments [environments-table]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/assets/javascripts/environments
[page_specific_javascript]: https://docs.gitlab.com/ce/development/frontend.html#page-specific-javascript [page_specific_javascript]: ./performance.md#page-specific-javascript
[component-system]: https://vuejs.org/v2/guide/#Composing-with-Components [component-system]: https://vuejs.org/v2/guide/#Composing-with-Components
[state-management]: https://vuejs.org/v2/guide/state-management.html#Simple-State-Management-from-Scratch [state-management]: https://vuejs.org/v2/guide/state-management.html#Simple-State-Management-from-Scratch
[one-way-data-flow]: https://vuejs.org/v2/guide/components.html#One-Way-Data-Flow [one-way-data-flow]: https://vuejs.org/v2/guide/components.html#One-Way-Data-Flow
......
...@@ -36,10 +36,12 @@ module Gitlab ...@@ -36,10 +36,12 @@ module Gitlab
validates :config, allowed_keys: ALLOWED_KEYS validates :config, allowed_keys: ALLOWED_KEYS
validates :url, validates :url,
type: String,
length: { maximum: 255 }, length: { maximum: 255 },
allow_nil: true allow_nil: true
validates :action, validates :action,
type: String,
inclusion: { in: %w[start stop], message: 'should be start or stop' }, inclusion: { in: %w[start stop], message: 'should be start or stop' },
allow_nil: true allow_nil: true
......
...@@ -100,6 +100,26 @@ describe Gitlab::Ci::Config::Entry::Environment do ...@@ -100,6 +100,26 @@ describe Gitlab::Ci::Config::Entry::Environment do
end end
end end
context 'when wrong action type is used' do
let(:config) do
{ name: 'production',
action: ['stop'] }
end
describe '#valid?' do
it 'is not valid' do
expect(entry).not_to be_valid
end
end
describe '#errors' do
it 'contains error about wrong action type' do
expect(entry.errors)
.to include 'environment action should be a string'
end
end
end
context 'when invalid action is used' do context 'when invalid action is used' do
let(:config) do let(:config) do
{ name: 'production', { name: 'production',
...@@ -151,6 +171,26 @@ describe Gitlab::Ci::Config::Entry::Environment do ...@@ -151,6 +171,26 @@ describe Gitlab::Ci::Config::Entry::Environment do
end end
end end
context 'when wrong url type is used' do
let(:config) do
{ name: 'production',
url: ['https://meow.meow'] }
end
describe '#valid?' do
it 'is not valid' do
expect(entry).not_to be_valid
end
end
describe '#errors' do
it 'contains error about wrong url type' do
expect(entry.errors)
.to include 'environment url should be a string'
end
end
end
context 'when variables are used for environment' do context 'when variables are used for environment' do
let(:config) do let(:config) do
{ name: 'review/$CI_COMMIT_REF_NAME', { name: 'review/$CI_COMMIT_REF_NAME',
......
...@@ -152,7 +152,10 @@ describe MergeRequests::RefreshService do ...@@ -152,7 +152,10 @@ describe MergeRequests::RefreshService do
stub_ci_pipeline_yaml_file(YAML.dump(config)) stub_ci_pipeline_yaml_file(YAML.dump(config))
end end
subject { service.new(@project, @user).execute(@oldrev, @newrev, 'refs/heads/master') } subject { service.new(project, @user).execute(@oldrev, @newrev, ref) }
let(:ref) { 'refs/heads/master' }
let(:project) { @project }
context "when .gitlab-ci.yml has merge_requests keywords" do context "when .gitlab-ci.yml has merge_requests keywords" do
let(:config) do let(:config) do
...@@ -168,14 +171,17 @@ describe MergeRequests::RefreshService do ...@@ -168,14 +171,17 @@ describe MergeRequests::RefreshService do
it 'create detached merge request pipeline with commits' do it 'create detached merge request pipeline with commits' do
expect { subject } expect { subject }
.to change { @merge_request.merge_request_pipelines.count }.by(1) .to change { @merge_request.merge_request_pipelines.count }.by(1)
.and change { @fork_merge_request.merge_request_pipelines.count }.by(1)
.and change { @another_merge_request.merge_request_pipelines.count }.by(0) .and change { @another_merge_request.merge_request_pipelines.count }.by(0)
expect(@merge_request.has_commits?).to be_truthy expect(@merge_request.has_commits?).to be_truthy
expect(@fork_merge_request.has_commits?).to be_truthy
expect(@another_merge_request.has_commits?).to be_falsy expect(@another_merge_request.has_commits?).to be_falsy
end end
it 'does not create detached merge request pipeline for forked project' do
expect { subject }
.not_to change { @fork_merge_request.merge_request_pipelines.count }
end
it 'create detached merge request pipeline for non-fork merge request' do it 'create detached merge request pipeline for non-fork merge request' do
subject subject
...@@ -183,11 +189,25 @@ describe MergeRequests::RefreshService do ...@@ -183,11 +189,25 @@ describe MergeRequests::RefreshService do
.to be_detached_merge_request_pipeline .to be_detached_merge_request_pipeline
end end
it 'create legacy detached merge request pipeline for fork merge request' do context 'when service is hooked by target branch' do
subject let(:ref) { 'refs/heads/feature' }
expect(@fork_merge_request.merge_request_pipelines.first) it 'does not create detached merge request pipeline' do
.to be_legacy_detached_merge_request_pipeline expect { subject }
.not_to change { @merge_request.merge_request_pipelines.count }
end
end
context 'when service runs on forked project' do
let(:project) { @fork_project }
it 'creates legacy detached merge request pipeline for fork merge request' do
expect { subject }
.to change { @fork_merge_request.merge_request_pipelines.count }.by(1)
expect(@fork_merge_request.merge_request_pipelines.first)
.to be_legacy_detached_merge_request_pipeline
end
end end
context 'when ci_use_merge_request_ref feature flag is false' do context 'when ci_use_merge_request_ref feature flag is false' do
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment