BigW Consortium Gitlab

  1. 19 Aug, 2016 1 commit
  2. 09 Aug, 2016 1 commit
  3. 21 Jul, 2016 5 commits
  4. 12 Jul, 2016 2 commits
  5. 07 Jul, 2016 2 commits
  6. 04 Jul, 2016 1 commit
  7. 30 Jun, 2016 1 commit
  8. 08 Jun, 2016 1 commit
  9. 07 Jun, 2016 1 commit
  10. 03 Jun, 2016 3 commits
  11. 16 May, 2016 1 commit
  12. 05 May, 2016 1 commit
  13. 04 May, 2016 1 commit
  14. 01 May, 2016 1 commit
  15. 30 Mar, 2016 1 commit
  16. 29 Mar, 2016 1 commit
  17. 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.
  18. 10 Mar, 2016 1 commit
  19. 09 Mar, 2016 1 commit
  20. 25 Jan, 2016 1 commit
  21. 30 Nov, 2015 1 commit
  22. 05 Oct, 2015 1 commit
  23. 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.
  24. 09 Sep, 2015 1 commit
  25. 06 Sep, 2015 1 commit
  26. 14 Jul, 2015 1 commit
  27. 30 Jun, 2015 2 commits
    • Fix ApplicationHelper specs · 42b643f0
      Robert Speicher authored
      There were several specs that were failing when run by themselves.
      
      - Use the `helper` object, as per RSpec 3 standards
      - Use `assign` to assign instance variables that helpers expect
      - Add `StubConfiguration` support module
    • Add spec/support/factory_girl · 366799bb
      Robert Speicher authored
      Just for consistency with our Capybara, DatabaseCleaner, WebMock, etc.
      setups.
  28. 22 Jun, 2015 1 commit
  29. 10 Jun, 2015 2 commits
  30. 26 Apr, 2015 1 commit