- 20 May, 2016 2 commits
-
-
Yorick Peterse authored
-
Robert Speicher authored
Update CE code to include some refactor done in EE to do with import url This is simply updating the code to match EE and avoid further conflicts related to `import_data` and `import_url` changes made on EE only. See merge request !4223
-
- 19 May, 2016 38 commits
-
-
Yorick Peterse authored
-
Robert Speicher authored
Add config for CI Runner that prevents it from picking untagged jobs Closes #3456 See merge request !4039
-
Rémy Coutable authored
Fix creation of Ci::Commit object which can lead to pending, failed in some scenarios ## What does this MR do? If we use a new `project.ci_commits` it will add it to array, and some other services which can do a save on a project can lead to a scenario when `ci_commit` will be saved, where it should not be. ## What are the relevant issue numbers? https://gitlab.com/gitlab-com/support-forum/issues/717 https://gitlab.com/gitlab-com/support-forum/issues/715 https://gitlab.com/gitlab-org/gitlab-ce/issues/17596 https://gitlab.com/gitlab-com/support-forum/issues/714 https://gitlab.com/gitlab-org/gitlab-ce/issues/13402 cc @rymai See merge request !4214
-
Jeroen van Baarsen authored
Move generator templates to generator_templates/ See merge request !4217
-
Douwe Maan authored
Create a todo on failing MR build Implements #14067. I worked on this with @DouweM (any mistakes are mine). When a build fails for a commit, create a todo for the author of the merge request that commit is the HEAD of. If the commit isn't the HEAD commit of any MR, don't do anything. If there already is a todo for that user and MR, don't do anything. Current limitations: - This isn't configurable by project. - The author of a merge request might not be the person who pushed the breaking commit. - I haven't tested this with a working CI setup, just with the unit tests below and by modifying my DB directly. See merge request !3177
-
Douwe Maan authored
Syntax-highlight diffs in push emails ![image](/uploads/8ecbabc65382214b8de63aae24f66cea/image.png) Based on: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/151 See merge request !4147
-
Jeroen van Baarsen authored
Update 'after_script' introduction note Related to gitlab-org/gitlab-ci-multi-runner#1321 See merge request !4205
-
Kamil Trzcinski authored
-
Douwe Maan authored
Add pipeline view This is continuation of https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3653 cc @DouweM @grzesiek Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/17551 Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/15625 See merge request !3703
-
Robert Speicher authored
Removed outdated comment from migration helpers [ci skip] See merge request !4213
-
Yorick Peterse authored
-
Yorick Peterse authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Yorick Peterse authored
Since we eager load everything in lib/ putting ERB code in .rb files will result in syntax errors. By moving the templates to ./generator_templates we can work around this.
-
Rémy Coutable authored
Resolve "Wrong sorting of commit order in MR view?" !4052 fixed this for the most obvious cases, but there were still some problems. Here's my test case: I have a branch where I was suffering from an unfortunate issue. Every other commit I made had its commit date set to one day before it should have been. (Perhaps my system clock was misbehaving.) ```shell for i in {1..10} do echo $i > $i git add $i GIT_COMMITTER_DATE=`date -v -$((i % 2))d` git commit -m $i done ``` The git CLI still gives me the commits in the right order, but I can see that the timestamps alternate between two values: ```shell $ git log --format='%h %ct %p %s' master...HEAD f0c3108 1463646313 3d38a13 10 3d38a13 1463559913 67f419b 9 67f419b 1463646313 74330c0 8 74330c0 1463559913 56361d7 7 56361d7 1463646313 ba1b60c 6 ba1b60c 1463559913 f91497d 5 f91497d 1463646313 79c5e57 4 79c5e57 1463559913 b953cef 3 b953cef 1463646313 12fc411 2 12fc411 1463559913 835715b 1 ``` Unfortunately, GitLab didn't like this _at all_. Here's what the commits on my MR from that branch looked like: ![image](/uploads/fdc38e932eeedcb77de9ec4b50ad1476/image.png) That's because we were sorting the commits by date, which is safe if they are in that order anyway. If they aren't, then because Ruby's sorting isn't stable, we lose even the ordering among the correctly-ordered commits with the same timestamp. After these changes (and reloading the MR's diff), this looks like: ![image](/uploads/b09fb0f51359c1c89484e713e859512b/image.png) The commits view was also wrong, but in a slightly different way. In table form: | View | Before | After | | --- | --- | --- | | Commit list | 10, 8, 6, 4, 2, 9, 7, 5, 3, 1 | 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 | | MR commits | 10, 2, 8, 4, 6, 5, 7, 3, 9, 1 | 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 | Closes #12724 See merge request !4208
-