| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This solves transient failures when a text contains HTML-escapable
characters such as `'`.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
- gl_emoji for falling back to image/css-sprite when the browser
doesn't support an emoji
- Markdown rendering (Banzai filter)
- Autocomplete
- Award emoji menu
- Perceived perf
- Immediate response because we now build client-side
- Update `digests.json` generation in gemojione rake task to be more
useful and include `unicodeVersion`
MR: !9437
See issues
- #26371
- #27250
- #22474
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Resolve "User-generated permalink IDs collide with GitLab interface"
## What does this MR do?
Prevents ID values automatically generated by headers in [GitLab Flavored Markdown](https://github.com/gitlabhq/gitlabhq/blob/master/doc/user/markdown.md#header-ids-and-links) from colliding with IDs used elsewhere in the GitLab interface. This can cause confusion when, for instance, a selector looks for a merge request tab with `id="pipelines"` and there is a header with the same ID earlier in the DOM.
How this works:
* All header IDs generated with GitLab Flavored Markdown are namespaced with `id="user-content_foo"`
* All anchor links which point to these IDs continue to use the non-namespaced hash `<a href="#foo">...</a>`
* When a page is loaded or when the `hashchange` event is triggered, javascript will automatically search for `#user-content_foo` if `#foo` cannot be found, and scroll to that position instead.
## Before
## After:
## Does this MR meet the acceptance criteria?
- [x] [Changelog entry](https://docs.gitlab.com/ce/development/changelog.html) added
- Tests
- [x] Added for this feature/bug
- [ ] 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 it does - 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 #22781
See also prior attempts to address this issue:
#3908, !2023, !2024
See merge request !7631
|
|
|
|
|
|
|
|
This is the Group equivalent of 13ad9a745a392e0bf0cedd0e1f318c1acee9b969
|
|
Prior, every single test was creating four `ProjectMember` objects, each
of which created one `User` record, even though each test only used
_one_ of those Users, if any.
Now each test only creates the single user record it needs, if it needs
one. This shaves minutes off of each spec file changed here.
|
|
|
|
The amount of precision times have in databases is variable, so we need
tolerances when comparing in specs. It's better to have the tolerance defined
in one place than several.
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Handle videos in:
- MD preview in notes: commit, issue/MR, MR diff
- New notes in: commit, issue/MR, MR diff
- Persisted notes in: commit, issue/MR, MR diff
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
# Conflicts:
# app/services/system_note_service.rb
|
|
Gitlab::Diff::InlineDiff
|
|
|
|
Using the syntax proposed in #13829 [project_reference]%(milestone_id | milestone_name)
to get a link to the referred milestone.
|
|
|
|
|
|
The user has the rights of a public user execpt it can never create a project,
group, or team. Also it cant view internal projects.
|
|
The rationale for this can be found in
https://gitlab.com/gitlab-org/gitlab-ce/issues/13718 but in short the
benchmark suite no longer serves a good purpose now that we have proper
production monitoring in place.
Fixes gitlab-org/gitlab-ce#13718
|
|
|
|
|
|
|
|
|
|
This ensures that blocks defines using "benchmark_subject" have access
to methods defined using let/subject & friends.
|
|
This class method can be used in "describe" blocks to specify the
subject of a benchmark. This lets you write:
benchmark_subject { Foo }
instead of:
benchmark_subject { -> { Foo } }
|
|
This benchmark suite uses benchmark-ips
(https://github.com/evanphx/benchmark-ips) behind the scenes. Specs can
be turned into benchmark specs by setting "benchmark" to "true" in the
top-level describe block like so:
describe SomeClass, benchmark: true do
end
Writing benchmarks can be done using custom RSpec matchers, for example:
describe MaruTheCat, benchmark: true do
describe '#jump_in_box' do
it 'should run 1000 iterations per second' do
maru = described_class.new
expect { maru.jump_in_box }.to iterate_per_second(1000)
end
end
end
By default the "iterate_per_second" expectation requires a standard
deviation under 30% (this is just an arbitrary default for now). You can
change this by chaining "with_maximum_stddev" on the expectation:
expect { maru.jump_in_box }.to iterate_per_second(1000)
.with_maximum_stddev(10)
This will change the expectation to require a maximum deviation of 10%.
Alternatively you can use the it block style to write specs:
describe MaruTheCat, benchmark: true do
describe '#jump_in_box' do
subject { -> { described_class.new } }
it { is_expected.to iterate_per_second(1000) }
end
end
Because "iterate_per_second" operates on a block, opposed to a static
value, the "subject" method must return a Proc. This looks a bit goofy
but I have been unable to find a nice way around this.
|
|
Also adds the ability to run rspecs with relative_url_defined on the enviornment. For example:
RELATIVE_URL_ROOT=/gitlab rspec
Closes #1728
|
|
|
|
|
|
|
