As for now, we keep this class inside a oryginal config processor class.
We will move implementation to this class and delegate to it from
current config processor.
After original gitlab ci yaml processor not longer has relevant
impelemntation we will replace it with new configuration class.
Nokogiri's `node.replace` was being unnecessarily called for every text node in
the document due to a comparison bug. The code previously was comparing the
HTML representation of the full document against the text node, which would
always fail. Fix the comparison to just compare the modified text.
Closes#18011
Separate reference gathering from rendering
This is a required step to allow batch processing when gathering references. This in turn would allow grabbing (for example) all mentioned users of an issue/merge request using a single query.
cc @rspeicher @DouweM
See merge request !3969
Fix 404 page when viewing TODOs that contain milestones or labels in different projects
A user viewing the TODOs page will see a 404 if there are mentioned milestones or labels in multiple different projects. This is likely a caching bug and only occurs
when Markdown rendering occurs across multiple projects, which is why it's so tricky to reproduce. This is what I think is happening:
1. LabelReferenceFilter#references_in encounters label ~X for ProjectA and finds the label in the DB as id = 1.
2. LabelReferenceFilter.references_in yields [1, 'X', nil, ...]
3. Since project_ref is nil, AbstractReferenceFilter#project_from_ref_cache caches nil => ProjectA.
4. LabelReferenceFilter#references_in encounters label ~Y for ProjectB and finds the label in the DB as id = 2.
5. LabelReferenceFilter.references_in yields [2, 'Y', nil, ...]
6. AbstractReferenceFilter#project_from_ref_cache lookups nil and returns ProjectA. It was supposed to be ProjectB.
7. A is the wrong project, so the label lookup fails.
This MR expands the `project_ref` to the right value as soon as we have it to avoid this caching bug.
Closes#17898
See merge request !4312
A user viewing the TODOs page will see a 404 if there are mentioned labels
in multiple different projects. This is likely a caching bug and only occurs
when Markdown rendering occurs across multiple projects, which is why it's so
tricky to reproduce. This is what I think is happening:
1. LabelReferenceFilter#references_in encounters label ~X for ProjectA and finds the label in the DB as id = 1.
2. LabelReferenceFilter.references_in yields [1, 'X', nil, ...]
3. Since project_ref is nil, AbstractReferenceFilter#project_from_ref_cache caches nil => ProjectA.
4. LabelReferenceFilter#references_in encounters label ~Y for ProjectB and finds the label in the DB as id = 2.
5. LabelReferenceFilter.references_in yields [2, 'Y', nil, ...]
6. AbstractReferenceFilter#project_from_ref_cache lookups nil and returns ProjectA. It was supposed to be ProjectB.
7. A is the wrong project, so the label lookup fails.
This MR caches Markdown references if the key is present.
Closes#17898
Enable Style/NegatedIf Rubocop cop
Favor `unless` over `if` for negative conditions (or control flow ||).
```ruby
# bad
do_something if !some_condition
# bad
do_something if not some_condition
# good
do_something unless some_condition
# good
some_condition || do_something
```
See #17478
See merge request !4355
Enable Style/IndentAssignment Rubocop style cop
Checks the indentation of the first line of the right-hand-side of a multi-line assignment.
See #17478
See merge request !4348
This fixes an issue where the RequestStore was being populated with the settings in the unicorn master
during the rails initializers. Each forked worker would then start their first request with an uncleaned RequestStore.
This splits the Markdown rendering and reference extraction phases into
two distinct code bases. The reference extraction phase no longer relies
on the html-pipeline Gem (and any related code) and allows for
extracting of references from multiple HTML nodes in a single pass. This
means that if you want to extract user references from 200 comments you
no longer need to run 200 times N number of queries, instead only a
handful of queries may be needed.
This class can be used to lazy-evaluate blocks of code the first time
they're called. This can be useful when a method performs a certain
heavy operation (e.g. a SQL query) that you only want to perform
whenever the result is used for the first time.
POC: Updated contrib calendar
In an effort to cut down the JS file size - i've removed the heatmap calendar used for the contributing calendar on users profiles. We already have d3 on the page so why not use it instead of using a library which uses it?
cc. @jschatz1
See merge request !3944
Grzegorz Bizon
Stan Hu
Robert Speicher
Douwe Maan
Douwe Maan
Rémy Coutable
Dmitriy Zaporozhets
Felipe Artur
Valery Sizov
Robert Speicher
Kamil Trzcinski
DJ Mountney
Yorick Peterse
Jacob Vosmaer
James Lopez
Jacob Schatz