This cuts down the time it takes to sort issues of a milestone by about
10x. In the previous setup the code would run a SQL query for every
issue that had to be sorted. The new setup instead runs a single SQL
query to update all the given issues at once.
The attached benchmark used to run at around 60 iterations per second,
using the new setup this hovers around 600 iterations per second. Timing
wise a request to update a milestone with 40-something issues would take
about 760 ms, in the new setup this only takes about 130 ms.
Fixes#3066
Improve invalidation of stored service password if the endpoint URL is changed (V2)
New version of !1583, using the same failproof logic but this time mirroring the name and behaviour of the change-tracking methods of ActiveModel::Dirty in order to make it clearer and more natural.
Added more tests to clarify the expected behaviour.
This is an alternative to !1594
/cc @vsizov @rspeicher
See merge request !1600
Implement Commit Status API
This is preliminary implementation of Commit Status API, pretty much compatible with GitHub.
1. The Commit Statuses are stored in separate table: ci_commit_status.
2. The POST inserts a new row.
3. To POST execute GitLab API `post :id/repository/commits/:sha/status`. This accepts dual authorization:
- Using authorized user
- Using ci-token to allow easy posting from CI Services
4. This adds predefined variable to GitLab CI build environment: CI_BUILD_STATUS_URL, allowing to easy post status from within build (ex. with code coverage or other metrics).
5. This adds statuses to commit's builds view.
6. The commit's status is calculated taking into account status of all builds and all posted statuses.
7. The commit statuses doesn't trigger notifications.
8. The commit status API introduces two new privileges: `read_commit_statuses` and `create_commit_status`.
9. We still miss a few tests and documentation updates for API and CI.
@dzaporozhets @sytses What do you think?
See merge request !1530
By using a JOIN we can remove the need for using 2 separate queries to
find a project by its namespace. Combined with an index (only needed for
PostgreSQL) this reduces the query time from ~245 ms (~520 ms for the
first call) down to roughly 10 ms (~15 ms for the first call).
This changes the query to use a COUNT nested in an INNER JOIN, instead
of a COUNT plus a GROUP BY. There are two reasons for this:
1. Using a COUNT in an INNER JOIN can be quite a bit faster.
2. The use of a GROUP BY means that method calls such as "any?"
(and everything else that calls "count") operate on a Hash that
counts the amount of notes on a per project basis, instead of just
counting the total amount of projects.
The query has been moved into Project.trending as its logic is simple
enough. As a result of this testing the TrendingProjectsFinder class
simply involves testing if the right methods are called, removing the
need for setting up database records.
Valery Sizov
Yorick Peterse
Zeger-Jan van de Weg
Robert Speicher
Kamil Trzcinski
Alex Lossent
Robert Speicher
Stan Hu
Douwe Maan
Valery Sizov
Ben Boeckel
Dmitriy Zaporozhets
Guilherme Garnier
