BigW Consortium Gitlab

  1. 05 Nov, 2015 2 commits
    • CI details cleanup · ba68facf
      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.
  2. 03 Nov, 2015 7 commits
  3. 02 Nov, 2015 3 commits
  4. 30 Oct, 2015 2 commits
    • Adjusted ips/sec for find_by_any_email benchmarks · 6d3068be
      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).
    • Improve performance of User.find_by_any_email · 49c081b9
      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
  5. 29 Oct, 2015 7 commits
  6. 28 Oct, 2015 1 commit
  7. 26 Oct, 2015 1 commit
    • Fix CI badge · 271ad4e3
      Kamil Trzcinski authored
      The previous code relied on having on ref stored in commit, however the ref was moved to the build.
  8. 23 Oct, 2015 1 commit
  9. 22 Oct, 2015 4 commits
  10. 21 Oct, 2015 3 commits
  11. 20 Oct, 2015 4 commits
  12. 19 Oct, 2015 2 commits
  13. 18 Oct, 2015 3 commits