BigW Consortium Gitlab

  1. 17 Nov, 2016 1 commit
  2. 16 Nov, 2016 1 commit
  3. 26 Oct, 2016 2 commits
  4. 21 Oct, 2016 1 commit
  5. 18 Oct, 2016 1 commit
    • Use bcc for pipeline emails because: · 045c6715
      Lin Jen-Shin authored
      We use bcc here because we don't want to generate this emails for a
      thousand times. This could be potentially expensive in a loop, and
      recipients would contain all project watchers so it could be a lot.
  6. 17 Oct, 2016 9 commits
  7. 14 Oct, 2016 2 commits
  8. 20 Sep, 2016 2 commits
  9. 19 Sep, 2016 2 commits
    • Fix spec failures · 748dd35c
      Kamil Trzcinski authored
    • Test all cycle analytics pre-calculation code. · 8f620851
      Timothy Andrew authored
      All the code that pre-calculates metrics for use in the cycle analytics
      page.
      
      - Ci::Pipeline -> build start/finish
      - Ci::Pipeline#merge_requests
      - Issue -> record default metrics after save
      - MergeRequest -> record default metrics after save
      - Deployment -> Update "first_deployed_to_production_at" for MR metrics
      - Git Push -> Update "first commit mention" for issue metrics
      - Merge request create/update/refresh -> Update "merge requests closing issues"
  10. 13 Sep, 2016 2 commits
    • Fix English · 05faeec7
      Lin Jen-Shin authored
    • Add a test for #22010 · 18d7ae43
      Lin Jen-Shin authored
      The observed faulty state transition is probably hard to test,
      because we need to hook into internal states to observe them.
      Namely this:
      
          07:30:16 | Build#ruby-2.2 enqueue: created -> pending
          07:30:16 | Pipeline#32    enqueue: created -> pending
          07:30:16 | Build#ruby-2.3 enqueue: created -> pending
          07:30:16 | Build#ruby-2.2     run: pending -> running
          07:30:16 | Pipeline#32        run: pending -> running
          07:30:29 | Build#ruby-2.2    drop: running -> failed
          07:30:29 | Pipeline#32        run: running -> running
          07:30:29 | Build#ruby-2.3     run: pending -> running
          07:30:30 | Pipeline#32        run: running -> running
          07:30:57 | Build#gem:build   skip: created -> skipped
          07:30:57 | Pipeline#32       drop: running -> failed
          07:30:57 | Build#gem:release skip: created -> skipped
          07:30:57 | Pipeline#32       drop:  failed -> failed
          07:30:57 | Build#ruby-2.3    drop: running -> failed
          07:30:57 | Pipeline#32       drop: running -> failed
                                             ^^^ Should be failed -> failed
      
      However, the consequence of this, executing hooks twice would be
      easy enough to observe. So we could at least test against this.
      Keep in mind that if we ever changed how we execute the hooks
      this won't be testing against faulty state transition.
  11. 05 Sep, 2016 1 commit
  12. 02 Sep, 2016 4 commits
  13. 01 Sep, 2016 2 commits
  14. 29 Aug, 2016 1 commit
  15. 19 Aug, 2016 1 commit
  16. 15 Aug, 2016 2 commits
  17. 12 Aug, 2016 5 commits
  18. 11 Aug, 2016 1 commit