| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
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
|
| | |
|
| | |
|
| |
|
