Background process note logic for #3948
Quick and dirty way to get *most* of the note processing out of band and into the background. Seeing some pretty nice speed bumps. Keep in mind that doing this in process results in slower and slower responses as more notes are added and more participants exist.
```
without background processing
Completed 200 OK in 627ms (Views: 0.5ms | ActiveRecord: 32.3ms)
Completed 200 OK in 478ms (Views: 0.8ms | ActiveRecord: 28.3ms)
Completed 200 OK in 1107ms (Views: 0.6ms | ActiveRecord: 36.6ms)
with background processing
Completed 200 OK in 108ms (Views: 0.6ms | ActiveRecord: 4.7ms)
Completed 200 OK in 78ms (Views: 0.5ms | ActiveRecord: 4.5ms)
Completed 200 OK in 164ms (Views: 0.5ms | ActiveRecord: 8.3ms)
```
As you can see, speeds are consistent when doing the harder work out of process. I'm not sure the number of sql queries we're saving, but based on the logs alone it's a pretty good amount.
@dzaporozhets @yorickpeterse I would love some input on this.
See merge request !2631
Partially revert "Add IP check against DNSBLs at account sign-up"
This partially reverts 6a5cd3ca - we keep the migration and add a new
migration that reverts it in order to keep migration history intact.
See merge request !2643
Prevent transient Capybara timeouts during feature tests
The problem occurred because asset compilation takes a long time, so
when the asset cache didn't exist and the first test ran, it would often
(randomly) time out during the generation before the actual test even
had a chance to run.
Now we check if the cache exists before the suite runs, and if not, we
manually fire a request to the root URL in order to generate it. This
should allow subsequent tests to use the cached assets.
See merge request !2646
fix syntax error on 2.1 and rubocop on 2.2
Background:
Hashes `{:'key': 'value'}` are not valid in 2.1 but are recommended by Rubocop on 2.2. We only use those when we have a key such as `weird-key`, `weird.key`, etc...
We could disable Rubocop but it wouldn't warn us about the recommended syntax since `Ruby 1.9`: `{key: 'value'}`, which is valid for `Ruby 1.9+`.
Workaround 1 could be disabling `Style/HashSyntax:` in `rubocop.yml`.
Workaround 2 (tried in this MR) is to trick Rubocop using `.to_sym` which is effectively the same as adding the `:`. This would allow to keep the warning in place.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/12801
See merge request !2637
The problem occurred because asset compilation takes a long time, so
when the asset cache didn't exist and the first test ran, it would often
(randomly) time out during the generation before the actual test even
had a chance to run.
Now we check if the cache exists before the suite runs, and if not, we
manually fire a request to the root URL in order to generate it. This
should allow subsequent tests to use the cached assets.
Fix CI runner version not being properly updated when asked for a build
Due to broken implementation of attribute_for_keys the runner information was not updated correctly.
This MR adds test to check that such scenario will never happen again.
See merge request !2618
Due to broken implementation of attribute_for_keys the runner information was not updated correctly.
This MR adds test to check that such scenario will never happen again.
By simply loading the first event from the already sorted set we save
ourselves extra (slow) queries just to get the latest update timestamp.
This removes the need for Event.latest_update_time and significantly
reduces the time needed to build an Atom feed.
Fixesgitlab-org/gitlab-ce#12415
The pattern in the `::reference_pattern` class method in the
ExternalIssue model does not match all valid forms of JIRA project
names. I have updated the regex to match JIRA project names with numbers
and underscores. More information on valid JIRA project names can be
found here:
https://confluence.atlassian.com/jira/changing-the-project-key-format-192534.html
* The first character must be a letter,
* All letters used in the project key must be from the Modern Roman Alphabet and upper case, and
* Only letters, numbers or the underscore character can be used.
Track project import failure
Fixes#12512
This also help us on identify why the import process is returning the wrong status when the project was successfully imported. Like mentioned in the issue #12450
See merge request !2538
Make the `/groups` route behave as expected
The route is supposed to redirect the Groups#index request based on
whether or not a user was logged in. If they are, we redirect them to
their groups dashboard; if they're not, we redirect them to the public
Explore page.
But due to overly aggressive `before_action`s that weren't excluding (or including) the
`index` action, the request always resulted in a 404, whether a user was
logged in or not.
Closes#12660
See merge request !2580
This ensures that an instrumented method that doesn't take arguments
reports an arity of 0, instead of -1.
If Ruby had a proper method for finding out the required arguments of a
method (e.g. Method#required_arguments) this would not have been an
issue. Sadly the only two methods we have are Method#parameters and
Method#arity, and both are equally painful to use.
Fixesgitlab-org/gitlab-ce#12450
The route is supposed to redirect the Groups#index request based on
whether or not a user was logged in. If they are, we redirect them to
their groups dashboard; if they're not, we redirect them to the public
Explore page.
But due to overly aggressive `before_action`s that weren't excluding the
`index` action, the request always resulted in a 404, whether a user was
logged in or not.
Closes#12660