BigW Consortium Gitlab

  1. 08 Jun, 2016 1 commit
  2. 07 Jun, 2016 1 commit
  3. 03 Jun, 2016 3 commits
  4. 16 May, 2016 1 commit
  5. 05 May, 2016 1 commit
  6. 04 May, 2016 1 commit
  7. 01 May, 2016 1 commit
  8. 30 Mar, 2016 1 commit
  9. 29 Mar, 2016 1 commit
  10. 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.
  11. 10 Mar, 2016 1 commit
  12. 09 Mar, 2016 1 commit
  13. 25 Jan, 2016 1 commit
  14. 30 Nov, 2015 1 commit
  15. 05 Oct, 2015 1 commit
  16. 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.
  17. 09 Sep, 2015 1 commit
  18. 06 Sep, 2015 1 commit
  19. 14 Jul, 2015 1 commit
  20. 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.
  21. 22 Jun, 2015 1 commit
  22. 10 Jun, 2015 2 commits
  23. 26 Apr, 2015 1 commit
  24. 27 Mar, 2015 1 commit
  25. 12 Feb, 2015 2 commits
  26. 01 Oct, 2014 1 commit
  27. 19 Sep, 2014 2 commits
  28. 31 Jul, 2014 1 commit
  29. 17 Jun, 2014 1 commit
  30. 06 Jun, 2014 1 commit
  31. 24 Mar, 2014 1 commit
  32. 18 Jul, 2013 1 commit
    • Merge Request on forked projects · 3d7194f0
      Izaak Alpert authored
      The good:
      
       - You can do a merge request for a forked commit and it will merge properly (i.e. it does work).
       - Push events take into account merge requests on forked projects
       - Tests around merge_actions now present, spinach, and other rspec tests
       - Satellites now clean themselves up rather then recreate
      
      The questionable:
      
       - Events only know about target projects
       - Project's merge requests only hold on to MR's where they are the target
       - All operations performed in the satellite
      
      The bad:
      
        -  Duplication between project's repositories and satellites (e.g. commits_between)
      
      (for reference: http://feedback.gitlab.com/forums/176466-general/suggestions/3456722-merge-requests-between-projects-repos)
      
      Fixes:
      
      Make test repos/satellites only create when needed
      -Spinach/Rspec now only initialize test directory, and setup stubs (things that are relatively cheap)
      -project_with_code, source_project_with_code, and target_project_with_code now create/destroy their repos individually
      -fixed remote removal
      -How to merge renders properly
      -Update emails to show project/branches
      -Edit MR doesn't set target branch
      -Fix some failures on editing/creating merge requests, added a test
      -Added back a test around merge request observer
      -Clean up project_transfer_spec, Remove duplicate enable/disable observers
      -Ensure satellite lock files are cleaned up, Attempted to add some testing around these as well
      -Signifant speed ups for tests
      -Update formatting ordering in notes_on_merge_requests
      -Remove wiki schema update
      Fixes for search/search results
      -Search results was using by_project for a list of projects, updated this to use in_projects
      -updated search results to reference the correct (target) project
      -udpated search results to print both sides of the merge request
      
      Change-Id: I19407990a0950945cc95d62089cbcc6262dab1a8
  33. 10 Apr, 2013 1 commit
  34. 01 Apr, 2013 1 commit