Skip to content
Snippets Groups Projects
  1. Feb 18, 2020
  2. Feb 14, 2020
  3. Feb 05, 2020
  4. Jan 29, 2020
  5. Jan 23, 2020
  6. Jan 22, 2020
  7. Jan 21, 2020
  8. Jan 16, 2020
  9. Jan 13, 2020
  10. Jan 08, 2020
  11. Dec 20, 2019
  12. Dec 19, 2019
  13. Dec 18, 2019
  14. Dec 11, 2019
  15. Dec 10, 2019
  16. Nov 29, 2019
  17. Nov 28, 2019
  18. Nov 27, 2019
  19. Nov 22, 2019
  20. Nov 20, 2019
  21. Nov 19, 2019
  22. Nov 15, 2019
  23. Nov 14, 2019
  24. Nov 13, 2019
  25. Nov 12, 2019
  26. Nov 07, 2019
  27. Oct 29, 2019
  28. Oct 23, 2019
  29. Oct 22, 2019
  30. Oct 21, 2019
  31. Oct 18, 2019
  32. Oct 15, 2019
  33. Oct 10, 2019
  34. Oct 07, 2019
  35. Sep 16, 2019
  36. Sep 13, 2019
  37. Sep 03, 2019
  38. Aug 15, 2019
    • Nick Thomas's avatar
      Only read rebase status from the model · d31b733f
      Nick Thomas authored and Mayra Cabrera's avatar Mayra Cabrera committed
      Prior to 12.1, rebase status was looked up directly from Gitaly. In
      https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14417 , a DB
      column was added to track the status instead. However, we couldn't stop
      looking at the gitaly status immediately, since some rebases may been
      running across the upgrade.
      
      Now that we're in 12.3, it is safe to remove the direct-to-gitaly
      lookup. This also happens to fix a 500 error that is seen when viewing
      an MR for a fork where the source project has been removed.
      
      We still look at the Gitaly status in the service, just in case Gitaly
      and Sidekiq get out of sync - I assume this is possible, and it's a
      relatively cheap check.
      
      Since we atomically check and set `merge_requests.rebase_jid`, we
      should never enqueue two `RebaseWorker` jobs in parallel.
      d31b733f
  39. Aug 09, 2019
Loading