Extend yml syntax for only and except to support specifying repository path
This allows to limit execution of jobs to specific repository.
For example:
```yaml
job:
only:
- branches@gitlab-org/gitlab-ce
except:
- master@gitlab-org/gitlab-ce
```
The above will run `job` for all branches on `gitlab-org/gitlab-ce`, except master.
@dzaporozhets @JobV @vsizov Please review.
See merge request !1720
This further improves performance of User.find_by_any_email and is
roughly twice as fast as the previous UNION setup.
Thanks again to @dlemstra for suggesting this.
This is significantly faster than using a sub-query, at least when run
on the GitLab.com production database. The benchmarks are a lot slower
now with these changes, most likely due to PostgreSQL choosing a
different (and less efficient) plan based on the amount of data present
in the test database.
Thanks to @dlemstra for suggesting the use of a UNION.
This query used to rely on a JOIN, effectively producing the following
SQL:
SELECT users.*
FROM users
LEFT OUTER JOIN emails ON emails.user_id = users.id
WHERE (users.email = X OR emails.email = X)
LIMIT 1;
The use of a JOIN means having to scan over all Emails and users, join
them together and then filter out the rows that don't match the criteria
(though this step may be taken into account already when joining).
In the new setup this query instead uses a sub-query, producing the
following SQL:
SELECT *
FROM users
WHERE id IN (select user_id FROM emails WHERE email = X)
OR email = X
LIMIT 1;
This query has the benefit that it:
1. Doesn't have to JOIN any rows
2. Only has to operate on a relatively small set of rows from the
"emails" table.
Since most users will only have a handful of Emails associated
(certainly not hundreds or even thousands) the size of the set returned
by the sub-query is small enough that it should not become problematic.
Performance of the old versus new version can be measured using the
following benchmark:
# Save this in ./bench.rb
require 'benchmark/ips'
email = 'yorick@gitlab.com'
def User.find_by_any_email_old(email)
user_table = arel_table
email_table = Email.arel_table
query = user_table.
project(user_table[Arel.star]).
join(email_table, Arel::Nodes::OuterJoin).
on(user_table[:id].eq(email_table[:user_id])).
where(user_table[:email].eq(email).or(email_table[:email].eq(email)))
find_by_sql(query.to_sql).first
end
Benchmark.ips do |bench|
bench.report 'original' do
User.find_by_any_email_old(email)
end
bench.report 'optimized' do
User.find_by_any_email(email)
end
bench.compare!
end
Running this locally using "bundle exec rails r bench.rb" produces the
following output:
Calculating -------------------------------------
original 1.000 i/100ms
optimized 93.000 i/100ms
-------------------------------------------------
original 11.103 (± 0.0%) i/s - 56.000
optimized 948.713 (± 5.3%) i/s - 4.743k
Comparison:
optimized: 948.7 i/s
original: 11.1 i/s - 85.45x slower
In other words, the new setup is 85x faster compared to the old setup,
at least when running this benchmark locally.
For GitLab.com these improvements result in User.find_by_any_email
taking only ~170 ms to run, instead of around 800 ms. While this is
"only" an improvement of about 4.5 times (instead of 85x) it's still
significantly better than before.
Fixes#3242
Include the log messages of recent commits in project-level search
results, providing functionality similar to 'git log --grep'.
Update repository model rspec tests to validate the output of
Repository#commits_with_log_matching.
Use git follow flag for commits page when retrieve history for file or directory
This can be really helpful when you want commit history for file that was moved recently
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
See merge request !1680
Fix CI regressions
This MR fixes a couple of small CI regressions
- Allow developer to manage builds
- On CI Admin page show only projects that are present in GitLab
- On Runner CI Admin page show only projects that are present in GitLab
- Refresh build log only when status changes
- Show the oldest builds on top when viewing Builds - it most cases it shows running builds on top
- Fix Lint rendering
- Fix number of other builds in build widget
Fixes#3164Fixes#3161Fixesgitlab-org/gitlab-ci#343
See merge request !1679
Correctly find last known blob for file deleted in MR.
Fixes#3092.
When building a new MR, `@merge_request.commits.last` would fail because this delegates to `merge_request_diff` which is still `nil` at that point. I fixed that, and changed some of the logic because showing deleted blob contents didn't previously work for the Compare page, and the UI would show the wrong commit sha for "View File @...".
See merge request !1647
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
Add ability to remove the fork relationship from project settings
Replaces !1579.
Fixes#2578.
See merge request !1636
Allow users to select the Files view as default project view
Also shows the readme at the very bottom, like on the regular Files page.
Replaces !1489.
Closes#2655.
See merge request !1632
Fix nonatomic database update potentially causing project star counts to go negative
The `counter_cache` decrement function is called when a project star is deleted,
but there was no guarantee multiple workers would not attempt to delete the
same item simultaneously. Use an atomic update to prevent the count from going negative.
Note: I was only able to duplicate the issue on GitLab.com, but I haven't been able to replicate it anywhere else. Presumably this bug happens when the `WHERE` clause takes some time to search for the right entry and multiple requests get sent simultaneously. Need to verify whether this fix truly solves the issue.
Closes#3067
See merge request !1628
Separate rendering of Markdown reference links from redacting those the user doesn't have access to and extracting referenced objects
Related: !1014
See merge request !1090
The counter_cache decrement function is called when a project star is deleted,
but there was no guarantee multiple workers would not attempt to delete the
same item simultaneously. Use an atomic update to prevent the count from going negative.
Closes#3067
Kamil Trzciński
Dmitriy Zaporozhets
Yorick Peterse
Michael Chmielewski
Jonathan SchoefflingandMichael Chmielewski
Stan Hu
Robert Speicher
Douwe Maan
Valery Sizov
Dirceu Pereira Tiegs
Artem V. Navrotskiy
Jacob Vosmaer
Han Loong Liauw
Zeger-Jan van de Weg
