- 05 Nov, 2015 2 commits
-
-
Kamil Trzcinski authored
- Add page titles to CI settings. - Fix CI admin navigation. - Remove duplicated scope. - Use monospace font for commit sha. - Add page title and header title to build page. - Proper authorization for cancel/retry builds. - Use gitlab pagination theme for builds and group members. - Don't paginate builds widget on build page. - Add badges to commit page Changes/Builds tabs. - Add "Builds" to commit Builds tab page title. - Add and use Ci::Build#retryable? method. - Add CI::Build#retried? method. - Allow all failed commit builds to be retried. - Proper authorization for cancel/retry all builds. - Remove unused param. - Use time_ago_with_tooltip where appropriate. - Tweak builds index text - Remove duplication between builds/build and commit_statuses/commit_status. - Use POST rather than GET for canceling and retrying builds. - Remove redundant URL helpers. - Add build ID to build page. - Link branch name on build page. - Move commit/:sha/ci to commit/:sha/builds.
-
Valery Sizov authored
-
- 03 Nov, 2015 7 commits
-
-
Robert Speicher authored
Closes #3311
-
Kamil Trzcinski authored
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
Yorick Peterse authored
The descriptions were not accurate and one particular spec seemingly expected the wrong User row to be returned.
-
Yorick Peterse authored
This benchmark exists to test if ordering has any noticeable impact in the test environment.
-
Valery Sizov authored
-
Kamil Trzcinski authored
-
- 02 Nov, 2015 3 commits
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
Valery Sizov authored
-
Kamil Trzcinski authored
-
- 30 Oct, 2015 2 commits
-
-
Yorick Peterse authored
While these benchmarks run at roughly 1500 i/sec setting the threshold to 1000 leaves some room for deviations (e.g. due to different DB setups).
-
Yorick Peterse authored
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
-
- 29 Oct, 2015 7 commits
-
-
Yorick Peterse authored
This benchmark currently runs at ~0.6 iterations per second and is unlikely to perform any better any time soon.
-
Michael Chmielewski authored
-
Michael Chmielewski authored
Fixed method to use git log via Popen as recommended, and made output match test (and thus system) expectations.
-
Michael Chmielewski authored
-
Michael Chmielewski authored
-
Mike Chmielewski authored
-
Jonathan Schoeffling authored
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.
-
- 28 Oct, 2015 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 26 Oct, 2015 1 commit
-
-
Kamil Trzcinski authored
The previous code relied on having on ref stored in commit, however the ref was moved to the build.
-
- 23 Oct, 2015 1 commit
-
-
Jason Lee authored
Rails Autoload find file to require is use , APIHelpers -> api_helpers.rb, not helpers.rb;
-
- 22 Oct, 2015 4 commits
-
-
Stan Hu authored
-
Valery Sizov authored
-
Kamil Trzcinski authored
-
Douwe Maan authored
-
- 21 Oct, 2015 3 commits
-
-
Dirceu Pereira Tiegs authored
-
Douwe Maan authored
-
Douwe Maan authored
-
- 20 Oct, 2015 4 commits
-
-
Jacob Vosmaer authored
-
Stan Hu authored
Safari 9.0 does not yet honor the HTML5 `origin-when-cross-origin` mode, and it's possible load balancers/proxies strip the HTTP_REFERER from the request header. In these cases, default to some default path. Closes #3122 Closes https://github.com/gitlabhq/gitlabhq/issues/9731
-
Douwe Maan authored
-
Yorick Peterse authored
-
- 19 Oct, 2015 2 commits
-
-
Stan Hu authored
By default, all the current user's repositories are accessible via the /users endpoint. There's no need to traverse all the organization repositories as well. See: * http://www.rubydoc.info/github/pengwynn/octokit/Octokit/Client/Repositories#repositories-instance_method * https://developer.github.com/v3/repos/#list-your-repositories Closes #2523
-
Yorick Peterse authored
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
-
- 18 Oct, 2015 3 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
-