An error occurred fetching the project authors.
- 31 May, 2018 1 commit
-
-
Dylan Griffith authored
-
- 03 May, 2018 2 commits
-
-
Dylan Griffith authored
-
Dylan Griffith authored
-
- 01 May, 2018 1 commit
-
-
Dylan Griffith authored
-
- 30 Apr, 2018 3 commits
-
-
Dylan Griffith authored
-
Dylan Griffith authored
-
Dylan Griffith authored
Per discussion in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9646#note_65730532 this logic is being optimized elsewhere and it will simplify things if we make less changes to this code right now.
-
- 23 Apr, 2018 2 commits
-
-
Alexis Reigel authored
don't differentiate between the different runner types, instead we rely on the Runner model to provide the available projects. scheduling is now applied to all runners equally.
-
Alexis Reigel authored
-
- 18 Apr, 2018 2 commits
-
-
Yorick Peterse authored
This reverts the addition of the "goldiloader" Gem and all use of it. While this Gem is very promising it's causing a variety of problems on GitLab.com due to it eager-loading too much data in places where we don't expect/can handle this. At least for the time being this means we have to go back to manually fixing N+1 query problems, but at least those should not cause a negative impact on availability.
-
🙈 jacopo beschi 🙉 authored
-
- 17 Apr, 2018 1 commit
-
-
Tomasz Maczukin authored
-
- 10 Apr, 2018 3 commits
-
-
Tomasz Maczukin authored
-
Tomasz Maczukin authored
-
Kamil Trzciński authored
This reverts merge request !17730
-
- 05 Apr, 2018 1 commit
-
-
Tomasz Maczukin authored
-
- 02 Feb, 2018 1 commit
-
-
Mario de la Ossa authored
-
- 12 Dec, 2017 1 commit
-
-
Shinya Maeda authored
-
- 06 Dec, 2017 2 commits
-
-
Shinya Maeda authored
Use Class.new(StandardError) instead of custom extended error class. Bring back specified_dependencies?.
-
Shinya Maeda authored
-
- 05 Dec, 2017 1 commit
-
-
Kamil Trzcinski authored
-
- 03 Sep, 2017 4 commits
-
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
Solution 1. Persists protected(ref) flag on ci_pipelines table. builds_for_shared_runner and builds_for_specific_runner read the flag instead of executing protected_for? one by one.
-
- 10 Aug, 2017 1 commit
-
-
Z.J. van de Weg authored
-
- 31 Jul, 2017 1 commit
-
-
Z.J. van de Weg authored
As its hard right now to determine what is a good metric and whats not, these two are not listed in the docs, nor will they get a CHANGELOG entry.
-
- 28 Jun, 2017 2 commits
-
-
Tiago Botelho authored
-
Tiago Botelho authored
-
- 21 Jun, 2017 1 commit
-
-
Grzegorz Bizon authored
-
- 17 Mar, 2017 1 commit
-
-
Kamil Trzciński authored
-
- 02 Mar, 2017 1 commit
-
-
Tomasz Maczukin authored
-
- 01 Mar, 2017 1 commit
-
-
Kamil Trzcinski authored
-
- 23 Feb, 2017 2 commits
-
-
Douwe Maan authored
This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.
-
Douwe Maan authored
-
- 25 Jan, 2017 2 commits
-
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
The conflict happens when we try to update a build, but fail to do so due to fact that we update the same build concurrently for two different runners.
-
- 20 Jan, 2017 1 commit
-
-
- 26 Oct, 2016 2 commits
-
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
-