Fix merge request new view not changing code view rendering style
What does this MR do?
Correctly respects the code view changing when creating a merge request.
Are there points in the code the reviewer needs to double check?
Why was this MR needed?
What are the relevant issue numbers?
Closes #20808 (closed)
Screenshots (if relevant)
Does this MR meet the acceptance criteria?
-
CHANGELOG entry added [ ] Documentation created/updated[ ] API support added- Tests
-
Added for this feature/bug -
All builds are passing
-
-
Conform by the style guides -
Branch has no merge conflicts with master(if you do - rebase it please) -
Squashed related commits together
Merge request reports
Activity
Reassigned to @jschatz1
@rspeicher another for you.
Reassigned to @rspeicher
mentioned in commit a6a45628
mentioned in commit 24f95605
@jschatz1 From what I can tell, merging this with master caused the builds to start failing. The parent commit on master was passing, but all merge commits after this started failing with the same issues.
Related to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5744#note_14030616.
mentioned in issue #21047 (closed)
@deckar01 It doesn't always fail, see https://gitlab.com/gitlab-org/gitlab-ce/issues/21047
@winniehell The build you list as evidence that it passes sometimes is for a MR not a merge commit with master. That MR is probably based on a commit before the broken test had landed. The merge commits are consistently failing on the test in this MR.
-
@deckar01 Now I get it, thanks... commit order at https://gitlab.com/gitlab-org/gitlab-ce/commits/master got me again.
This seems to be an issue with the CI philosophy of running the tests against HEAD of the branch. Travis creates a commit with the changes merged into the requested branch and runs its test against that commit. This has the benefit of not running tests when there are merge conflicts and rerunning the tests on merge with the ability to abort the merge on failure.
-
@deckar01 The build is actually made twice - once at the merge request (before merging) and once for the actual merge commit. But what constantly confuses me is that when I look at https://gitlab.com/gitlab-org/gitlab-ce/commits/master I don't only see builds that ran on the master branch.
This seems to be an issue with the CI philosophy of running the tests against HEAD of the branch. Travis creates a commit with the changes merged into the requested branch and runs its test against that commit. This has the benefit of not running tests when there are merge conflicts and rerunning the tests on merge with the ability to abort the merge on failure.
/cc @ayufan
