BigW Consortium Gitlab

  1. 01 Dec, 2016 2 commits
  2. 09 Nov, 2016 1 commit
  3. 08 Nov, 2016 1 commit
  4. 28 Oct, 2016 1 commit
  5. 25 Oct, 2016 1 commit
    • Don't schedule ProjectCacheWorker unless needed · 3b4af59a
      Yorick Peterse authored
      This changes ProjectCacheWorker.perform_async so it only schedules a job
      when no lease for the given project is present. This ensures we don't
      end up scheduling hundreds of jobs when they won't be executed anyway.
  6. 12 Oct, 2016 1 commit
  7. 06 Oct, 2016 1 commit
  8. 28 Sep, 2016 1 commit
  9. 19 Aug, 2016 1 commit
  10. 09 Aug, 2016 1 commit
  11. 21 Jul, 2016 5 commits
  12. 12 Jul, 2016 2 commits
  13. 07 Jul, 2016 2 commits
  14. 04 Jul, 2016 1 commit
  15. 30 Jun, 2016 1 commit
  16. 08 Jun, 2016 1 commit
  17. 07 Jun, 2016 1 commit
  18. 03 Jun, 2016 3 commits
  19. 16 May, 2016 1 commit
  20. 05 May, 2016 1 commit
  21. 04 May, 2016 1 commit
  22. 01 May, 2016 1 commit
  23. 30 Mar, 2016 1 commit
  24. 29 Mar, 2016 1 commit
  25. 15 Mar, 2016 1 commit
    • Original implementation to allow users to subscribe to labels · 0444fa56
      Timothy Andrew authored
      1. Allow subscribing (the current user) to a label
      
      - Refactor the `Subscription` coffeescript class
        - The main change is that it accepts a container, and conducts all
          DOM queries within its scope. We need this because the labels
          page has multiple instances of `Subscription` on the same page.
      
      2. Creating an issue or MR with labels notifies users subscribed to those labels
      
      - Label `has_many` subscribers through subscriptions.
      
      3. Adding a label to an issue or MR notifies users subscribed to those labels
      
      - This only applies to subscribers of the label that has just been
        added, not all labels for the issue.
  26. 10 Mar, 2016 1 commit
  27. 09 Mar, 2016 1 commit
  28. 25 Jan, 2016 1 commit
  29. 30 Nov, 2015 1 commit
  30. 05 Oct, 2015 1 commit
  31. 02 Oct, 2015 1 commit
    • Basic setup for an RSpec based benchmark suite · 19893a1c
      Yorick Peterse authored
      This benchmark suite uses benchmark-ips
      (https://github.com/evanphx/benchmark-ips) behind the scenes. Specs can
      be turned into benchmark specs by setting "benchmark" to "true" in the
      top-level describe block like so:
      
          describe SomeClass, benchmark: true do
      
          end
      
      Writing benchmarks can be done using custom RSpec matchers, for example:
      
          describe MaruTheCat, benchmark: true do
            describe '#jump_in_box' do
              it 'should run 1000 iterations per second' do
                maru = described_class.new
      
                expect { maru.jump_in_box }.to iterate_per_second(1000)
              end
            end
          end
      
      By default the "iterate_per_second" expectation requires a standard
      deviation under 30% (this is just an arbitrary default for now). You can
      change this by chaining "with_maximum_stddev" on the expectation:
      
          expect { maru.jump_in_box }.to iterate_per_second(1000)
            .with_maximum_stddev(10)
      
      This will change the expectation to require a maximum deviation of 10%.
      
      Alternatively you can use the it block style to write specs:
      
          describe MaruTheCat, benchmark: true do
            describe '#jump_in_box' do
              subject { -> { described_class.new } }
      
              it { is_expected.to iterate_per_second(1000) }
            end
          end
      
      Because "iterate_per_second" operates on a block, opposed to a static
      value, the "subject" method must return a Proc. This looks a bit goofy
      but I have been unable to find a nice way around this.