- 13 Oct, 2016 40 commits
-
-
Alfredo Sumaran authored
-
Sean McGivern authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
- Use a store base object to manage application state. - Add a service to handle ajax requests. - Load code only when needed
-
Sean McGivern authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Alfredo Sumaran authored
-
Douwe Maan authored
-
Sean McGivern authored
-
Sean McGivern authored
-
Sean McGivern authored
-
Sean McGivern authored
-
Sean McGivern authored
-
Sean McGivern authored
-
Sean McGivern authored
When reading conflicts: 1. Add a `type` field. `text` works as before, and has `sections`; `text-editor` is a file with ambiguous conflict markers that can only be resolved in an editor. 2. Add a `content_path` field pointing to a JSON representation of the file's content for a single file. 3. Hitting `content_path` returns a similar datastructure to the `file`, but without the `content_path` and `sections` fields, and with a `content` field containing the full contents of the file (with conflict markers). When writing conflicts: 1. Instead of `sections` being at the top level, they are now in a `files` array. This matches the read format better. 2. The `files` array contains file hashes, each of which must contain: a. `new_path` b. `old_path` c. EITHER `sections` (which works as before) or `content` (with the full content of the resolved file).
-
Sean McGivern authored
-
Annabel Dunstone Gray authored
Replace unique keyframes mixin with specific keyframe animation names ## What does this MR do? Replaces `unique-keyframes` mixin with `include-keyframes` mixin ## Are there points in the code the reviewer needs to double check? Shouldn't be
👍🏻 ## Why was this MR needed? Some users had GitLab hosted in a distributed environment that makes `unique-keyframes` a non-viable implementation. The randomized animation names from `unique-keyframes` was not being picked up by the different servers which resulted in 404 errors. ## Screenshots (if relevant) None ## Does this MR meet the acceptance criteria? - [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added - Tests - [x] All builds are passing - [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html) - [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides) - [x] Branch has no merge conflicts with `master` (if you do - rebase it please) - [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits) ## What are the relevant issue numbers? Closes #22629 See merge request !6603 -
Robert Speicher authored
CE to EE merge check rake task ## What does this MR do? This merge request adds a Rake task that checks whether the current branch can be merged cleanly to EE/master. If not, it checks if a `<ce_branch>-ee` branch exists in EE, tries to merge it to EE/master and then tries to merge `ce_branch` to EE/master. If the result of the check is that the current branch cannot be merged cleanly to EE/master, the job will fail, display troubleshooting steps, and a warning will be shown in the merge request. ## Are there points in the code the reviewer needs to double check? Probably the steps I used to do the various checks, and also the steps I suggest to create an EE-specific branch. ## Why was this MR needed? The goal is to catch as early as possible the possible conflicts a CE MR will cause when CE/master will be merged to EE/master. This way, the developer is warned that he/she should open a MR against EE before or as soon as the CE is merged. In the end, this should lower the work of the CE->EE merger. ## What are the relevant issue numbers? Part of gitlab-org/gitlab-ee#715, hopefully. See merge request !6746
-
Rémy Coutable authored
Handle case where deployment ref no longer exists ## What does this MR do? In 8.9, we didn't create keep-around refs for deployments. So it's possible that someone created a deployment (say, for testing), and then deleted the branch and all other references to that commit. That commit could then get GCed, and trying to view MRs on 8.11+ will show a 500. See https://gitlab.com/gitlab-org/gitlab-ce/issues/22655#note_16575020 for more details. ## Why was this MR needed? If someone created a deployment on 8.9, then deleted all references to the commit for that deployment, we will throw an exception when checking if the deployment includes a commit. Closes #22655. See merge request !6855
-
Rémy Coutable authored
Sort API mounts ## What does this MR do? Sort the API mounts. ## Why was this MR needed? The API mounts are unsorted. See merge request !6831
-
Rémy Coutable authored
Convert unicode emojis to images. ## Why was this MR needed? For better cross platform interoperability with emojis. Closes #22591 See merge request !6829
-
Rémy Coutable authored
Also add a safeguard for non-CI env. Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Clement Ho authored
-
Sean McGivern authored
Use defined colour for a language when available ## What does this MR do? This MR changes the colours of the different languages in the language graph. It now uses the colour set in Linguist instead of the first six characters of the SHA256'd language name where possible. If Linguist has no colour defined for a given language, it falls back to the old method of finding a colour. I talked with @connorshea about creating this MR [on Twitter](https://twitter.com/connorjshea/status/784390886222286849) a few hours earlier. Here's also an older [tweet from May](https://twitter.com/nilsding/status/737018807223496708) where we discussed some possible improvements to the graph. ## Are there points in the code the reviewer needs to double check? Hopefully none ;) ## Why was this MR needed? Aesthetics. ## Screenshots (if relevant) Before: ![language_colours_before](/uploads/6b4bac784860da746d58708bdd6bba39/language_colours_before.png) After: ![language_colours_after](/uploads/98818ebf48ffb47e6b785120e69b0b6c/language_colours_after.png) ## Does this MR meet the acceptance criteria? - [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added - [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md) - [ ] API support added - Tests - [ ] Added for this feature/bug - [ ] All builds are passing - [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html) - [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides) - [ ] Branch has no merge conflicts with `master` (if it does - rebase it please) - [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits) ## What are the relevant issue numbers? - #12455 See merge request !6748
-