An error occurred fetching the project authors.
- 29 Apr, 2019 1 commit
-
-
Bob Van Landuyt authored
This ports the changes from https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10462/ to CE
-
- 10 Apr, 2019 1 commit
-
-
Kamil Trzciński authored
This adds a limitation that we will try to create pipeline for at most 4 first changes (branches and tags). This does not affect processing of Pipelines for Merge Requests, as each updated MR will have associated pipeline created.
-
- 08 Apr, 2019 1 commit
-
-
Luke Duncalfe authored
Previously the raw push option Array was sent to Pipeline::Chain::Skip. This commit updates this class (and the chain of classes that pass the push option parameters from the API internal `post_receive` endpoint to that class) to treat push options as a Hash of options parsed by GitLab::PushOptions. The GitLab::PushOptions class takes options like this: -o ci.skip -o merge_request.create -o merge_request.target=branch and turns them into a Hash like this: { ci: { skip: true }, merge_request: { create: true, target: 'branch' } } This now how Pipeline::Chain::Skip is determining if the `ci.skip` push option was used.
-
- 26 Mar, 2019 1 commit
-
-
Bob Van Landuyt authored
This changes the repository type from a binary `wiki?` to a type. So we can have more than 2 repository types. Now everywhere we called `.wiki?` and expected a boolean, we check that type.
-
- 25 Mar, 2019 2 commits
-
-
Nick Thomas authored
-
Nick Thomas authored
-
- 31 Dec, 2018 1 commit
-
-
Jonathon Reinhart authored
gitlab-org/gitlab-shell!166 added support for collecting push options from the environment, and passing them along to the /internal/post_receive API endpoint. This change handles the new push_options JSON element in the payload, and passes them on through to the GitPushService and GitTagPushService services. Futhermore, it adds support for the first push option, ci.skip. With this change, one can use 'git push -o ci.skip' to skip CI pipe execution. Note that the pipeline is still created, but in the "skipped" state, just like with the 'ci skip' commit message text. Implements #18667
-
- 25 Oct, 2018 2 commits
-
-
Tiago Botelho authored
Before we would need to identify a user when pushing through the GitLab UI. Since this is no longer the case we can remove the identification by commit and instead, use the identify_using_user
-
Tiago Botelho authored
When Gitlab::GitPostReceive#changes_refs is empty user would not get defined and nil would be passed to PostReceive#after_project_changes_hooks which would then throw an error.
-
- 27 Jun, 2018 1 commit
-
-
gfyoung authored
-
- 18 Apr, 2018 1 commit
-
-
🙈 jacopo beschi 🙉 authored
-
- 07 Mar, 2018 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 05 Dec, 2017 1 commit
-
-
Douwe Maan authored
-
- 27 Jun, 2017 1 commit
-
-
Alejandro Rodríguez authored
-
- 05 Jun, 2017 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 12 May, 2017 1 commit
-
-
Gabriel Mazetto authored
-
- 05 May, 2017 2 commits
-
-
Alejandro Rodríguez authored
-
Alejandro Rodríguez authored
-
- 29 Mar, 2017 1 commit
-
-
Jacob Vosmaer authored
-
- 03 Mar, 2017 1 commit
-
-
Alejandro Rodríguez authored
This will be necessary when adding gitaly settings. This version doesn't make any functional changes, but allows us to include this breaking change in 9.0 and add the needed extra settings in the future with backwards compatibility
-
- 01 Nov, 2016 1 commit
-
-
Elan Ruusamäe authored
-
- 21 Oct, 2016 1 commit
-
-
Yorick Peterse authored
Dumping too many jobs in the same queue (e.g. the "default" queue) is a dangerous setup. Jobs that take a long time to process can effectively block any other work from being performed given there are enough of these jobs. Furthermore it becomes harder to monitor the jobs as a single queue could contain jobs for different workers. In such a setup the only reliable way of getting counts per job is to iterate over all jobs in a queue, which is a rather time consuming process. By using separate queues for various workers we have better control over throughput, we can add weight to queues, and we can monitor queues better. Some workers still use the same queue whenever their work is related. For example, the various CI pipeline workers use the same "pipeline" queue. This commit includes a Rails migration that moves Sidekiq jobs from the old queues to the new ones. This migration also takes care of doing the inverse if ever needed. This does require downtime as otherwise new jobs could be scheduled in the old queues after this migration completes. This commit also includes an RSpec test that blacklists the use of the "default" queue and ensures cron workers use the "cronjob" queue. Fixes gitlab-org/gitlab-ce#23370
-
- 05 Aug, 2016 1 commit
-
-
Jacob Vosmaer authored
The change to base64-encoding the third argument to PostReceive in gitlab-shell made our Sidekiq ArgumentsLogger a little less useful. This change adds a log statement for the decoded data. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/20381
-
- 30 Jun, 2016 1 commit
-
-
Alejandro Rodríguez authored
-
- 19 Apr, 2016 1 commit
-
-
Gabriel Mazetto authored
-
- 11 Apr, 2016 1 commit
-
-
Kamil Trzcinski authored
-
- 17 Mar, 2016 1 commit
-
-
Gabriel Mazetto authored
-
- 17 Feb, 2016 1 commit
-
-
James Lopez authored
-
- 15 Feb, 2016 1 commit
-
-
James Lopez authored
-
- 11 Feb, 2016 1 commit
-
-
James Lopez authored
-
- 10 Aug, 2015 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 10 Apr, 2015 1 commit
-
-
Douwe Maan authored
-
- 15 Mar, 2015 1 commit
-
-
Douwe Maan authored
-
- 10 Mar, 2015 1 commit
-
-
Douwe Maan authored
-
- 02 Sep, 2014 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 13 Aug, 2014 1 commit
-
-
Dmitriy Zaporozhets authored
-
- 06 Mar, 2014 1 commit
-
-
Jeroen van Baarsen authored
-
- 05 Mar, 2014 1 commit
-
-
Jeroen van Baarsen authored
-
- 29 Apr, 2013 1 commit
-
-
Dmitriy Zaporozhets authored
-
- 03 Apr, 2013 1 commit
-
-
Dmitriy Zaporozhets authored
-