Rails' "url_helpers" method creates an anonymous Module (which a bunch
of methods) on every call. By caching the output of this method in a
dedicated method we can shave off about 10 seconds of loading time for
an issue with around 200 comments.
This greatly improves the performance of Project#external_issue_tracker
by moving most of the fields queried in Ruby to the database and letting
the database handle all logic. Prior to this change the process of
finding an external issue tracker was along the lines of the following:
1. Load all project services into memory.
2. Reduce the list to only services where "issue_tracker?" returns true
3. Reduce the list from step 2 to service where "default?" returns false
4. Find the first service where "activated?" returns true
This has to two big problems:
1. Loading all services into memory only to reduce the list down to a
single item later on is a waste of memory (and slow timing wise).
2. Calling Array#select followed by Array#reject followed by Array#find
allocates extra objects when this really isn't needed.
To work around this the following service fields have been moved to the
database (instead of being hardcoded):
* category
* default
This in turn means we can get the external issue tracker using the
following query:
SELECT *
FROM services
WHERE active IS TRUE
AND default IS FALSE
AND category = 'issue_tracker'
AND project_id = XXX
LIMIT 1
This coupled with memoizing the result (just as before this commit)
greatly reduces the time it takes for Project#external_issue_tracker to
complete. The exact reduction depends on one's environment, but locally
the execution time is reduced from roughly 230 ms to only 2 ms (= a
reduction of almost 180x).
Fixesgitlab-org/gitlab-ce#10771
Do not call API if there is no API URL
Fixes#5878
CE users may not be interested in the new JIRA features. In this case,
we should detect they haven't set an API URL and fallback to the
behavior pre-8.3. This patch does that very easily.
There are planned improvements to JIRA in future releases such as
gitlab-org/gitlab-ce#5541 which will make this more configurable.
See merge request !2341
Suppress e-mails on failed builds if allow_failure is set
Every time I push to GitLab, I get > 2 emails saying a spec failed when I don't care about the benchmarks and others that have `allow_failure` set to `true`.
@ayufan mentioned creating a summary e-mail to prevent getting one e-mail per build, but the latter might actually be desirable. For example, I do want to know if Rubocop errors fail right away.
See merge request !2178
Every time I push to GitLab, I get > 2 emails saying a spec failed when
I don't care about benchmarks and other specs that have `allow_failure` set to `true`.
* upstream/master: (307 commits)
Update CHANGELOG
spinach fix
Updated allocations Gem to version 1.0.3
Removed various default metrics tags
Update CHANGELOG
Fix "I see current user as the first user" step
Swap Author and Assignee Selectors on issuable index view
Update CHANGELOG
Make sure that is no pending migrations in Gitlab::CurrentSettings
Added additional config environmental variables to help Debian packaging
We don't use whenever anymore. Lets remove the schedule file
Fix project transfer e-mail sending incorrect paths in e-mail notification
Update CHANGELOG
Use Gitlab::CurrentSettings for InfluxDB
Write to InfluxDB directly via UDP
Strip newlines from obfuscated SQL
Add hotfix that allows to access build artifacts created before 8.3
note votes methids implementation
When reCAPTCHA is disabled, allow registrations to go through without a code
Downcased user or email search for avatar_icon.
...
- Fix for Ci::Build state machine, allowing to process builds without the project
- Forcefully update builds that didn't want to update with state machine
- Fix saving GitLabCiService as Admin Template