Re-implement page-specific JS in a better way.
## What does this MR do?
This rebuilds the way we do page-specific JavaScript assets for a few reasons:
- The current implementation does not work with Subresource Integrity (!4808)
- The current implementation doesn't allow caching of libraries because each page we hook up with this system will have a separate application.js. Meaning that for every page that uses Ace Editor, we'd have to load Ace Editor plus any GitLab-specific scripts in the same file, making local caching of just Ace Editor impossible.
- The current implementation is rather hacky.
## Are there points in the code the reviewer needs to double check?
That Sprockets doesn't choke on this when we use precompiled assets.
## What are the relevant issue numbers?
#14372
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [x] API support added
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [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)
cc: @jschatz1 @pavelloz
Thanks to @pavelloz for his example implementation which was very useful.
See merge request !4883
Add SMTP as default delivery method to match gitlab-org/omnibus-gitlab!826
Something happened after upgrading to 8.9RC5 that caused mail settings to be set to sendmail by default. gitlab-com/infrastructure#128 describes the issue in more detail. This MR mirrors the change in omnibus with gitlab-org/omnibus-gitlab!826.
Closes#19132
See merge request !4915
Fix a wrong MR status when merge_when_build_succeeds & project.only_allow_merge_if_build_succeeds are true
## What does this MR do?
Fix a wrong MR status when merge_when_build_succeeds & project.only_allow_merge_if_build_succeeds are true.
## Are there points in the code the reviewer needs to double check?
@stanhu I reused your proposal from the issue, I think it's a good enough solution.
## What are the relevant issue numbers?
Fixes#19035.
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- Tests
- [x] Added for this feature/bug
- [ ] All builds are passing
- [ ] 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)
See merge request !4912
The issue was that `MergeRequest#mergeable?` returns false when the CI
state is not success and project.only_allow_merge_if_build_succeeds is
true. In this case `Projects::MergeRequestsController#merge` would
return the `:failed` status when enabling `merge_when_build_succeeds`,
thus leading to a weird state and the MR never automatically merged.
The fix is to disable the CI state check in the controller safeguard
that early return the `:failed` status.
Signed-off-by: Rémy Coutable <remy@rymai.me>
The email check used in the Heath Check doesn't properly make use of enough of the SMTP config options
to be able to properly test the STMP connection, and as a result could cause a failure.
In order to fix it we have overwritten the email_configured? method in the health check
so that it does not check email status during the standard health check.
Fix temp file being deleted after the request while importing a GitLab project
Fixes https://gitlab.com/gitlab-com/infrastructure/issues/151
In production, the temporary uploaded file is getting deleted straight after the request so the Sidekiq worker is unable to find it in `/tmp`
Also, improved erroring/logging of this situation.
See merge request !4894
This commit changes the way certain documents are rendered (currently
only Notes) and how documents are redacted. Previously both rendering
and redacting would run on a per document basis. The result of this was
that for every document we'd have to run countless queries just to
figure out if we could display a set of links or not.
This commit changes things around so that redacting Markdown documents
is no longer tied into the html-pipeline Gem. This in turn allows it to
redact multiple documents in a single pass, thus reducing the number of
queries needed.
In turn rendering issue/merge request notes has been adjusted to take
advantage of this new setup. Instead of rendering Markdown somewhere
deep down in a view the Markdown is rendered and redacted in the
controller (taking the current user and all that into account). This has
been done in such a way that the "markdown()" helper method can still be
used on its own.
This particular commit also paves the way for caching rendered HTML on
object level. Right now there's an accessor method Note#note_html which
is used for setting/getting the rendered HTML. Once we cache HTML on row
level we can simply change this field to be a column and call a "save"
whenever needed and we're pretty much done.
Fix settings_spec so that it can that run by itself
Running `spec/settings_spec.rb` would fail because it would attempt to load `1_settings.rb`, which would reference `Rails`. This constant was not loaded without `spec_helper.rb`.
See merge request !4893
Replace Haml with Hamlit
What this change does:
- It replaces HAML with [Hamlit](https://github.com/k0kubun/hamlit), a much more efficient implementation of HAML.
- It removes `haml-rails`.
- It adds `hamlit.rb` and removes `haml.rb`.
- It makes things faster and less memory-hungry!
See also #13201.
See merge request !3666
Resolve "Scrolling horz on iOS for the secondary nav is broken"
## What does this MR do?
Moves absolutely positioned `div`s outside of the scrolling container because mobile safari causes those elements to jump around on scroll.
## Are there points in the code the reviewer needs to double check?
Check on a real iPhone (was only able to check in iOS simulator)
## Why was this MR needed?
Mobile Safari.
## What are the relevant issue numbers?
Closes#18438
## Screenshots (if relevant)

See merge request !4869
Fix unwanted label unassignment
## What does this MR do?
- When updating the milestone
- [x] Do not remove labels when assigning a milestone
- [x] Do not remove labels when unassigning a milestone
- [x] Do not remove labels when assigning a milestone and adding another label
- When toggling selected issues labels should be kept
- [x] Select an issue with an assigned label -> pick another label from dropdown-> unselect the issue -> select the issue again -> submit the form: Existing label should not be removed.
## Are there points in the code the reviewer needs to double check?
Labels should not be added or removed to issues when doing bulk actions unless we explicitly select a label from the dropdown
## Does this MR meet the acceptance criteria?
- [x] [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
- [x] Added for this feature/bug
- [x] All builds are passing
- [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)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !4863
Use jQuery objects in ref dropdown
## What does this MR do?
Keeps the behaviour the same as the ref dropdown, however it now uses jQuery objects to handle the HTML creation instead of passing strings around. It pretty much worked out the box so not much was changed in the dropdowns themselves. Will be easy to transfer this over to other dropdown menus as well.
cc. @jschatz1 @rspeicher @DouweM
Do we want this to go into a patch release?
See merge request !4850