Skip to content
Snippets Groups Projects
  1. Jan 24, 2018
  2. Jan 18, 2018
  3. Jan 17, 2018
  4. Jan 11, 2018
  5. Jan 05, 2018
  6. Jan 04, 2018
  7. Jan 03, 2018
  8. Dec 27, 2017
  9. Dec 22, 2017
  10. Dec 14, 2017
    • Nick Thomas's avatar
      Import gitlab_projects.rb from gitlab-shell · 4b785df2
      Nick Thomas authored
      By importing this Ruby code into gitlab-rails (and gitaly-ruby), we avoid
      200ms of startup time for each gitlab_projects subprocess we are eliminating.
      
      By not having a gitlab_projects subprocess between gitlab-rails / sidekiq and
      any git subprocesses (e.g. for fork_project, fetch_remote, etc, calls), we can
      also manage these git processes more cleanly, and avoid sending SIGKILL to them
      Verified
      4b785df2
  11. Dec 07, 2017
  12. Dec 06, 2017
  13. Dec 01, 2017
  14. Nov 23, 2017
  15. Nov 20, 2017
  16. Nov 17, 2017
  17. Nov 10, 2017
  18. Nov 07, 2017
    • Yorick Peterse's avatar
      Rewrite the GitHub importer from scratch · 4dfe26cd
      Yorick Peterse authored
      Prior to this MR there were two GitHub related importers:
      
      * Github::Import: the main importer used for GitHub projects
      * Gitlab::GithubImport: importer that's somewhat confusingly used for
        importing Gitea projects (apparently they have a compatible API)
      
      This MR renames the Gitea importer to Gitlab::LegacyGithubImport and
      introduces a new GitHub importer in the Gitlab::GithubImport namespace.
      This new GitHub importer uses Sidekiq for importing multiple resources
      in parallel, though it also has the ability to import data sequentially
      should this be necessary.
      
      The new code is spread across the following directories:
      
      * lib/gitlab/github_import: this directory contains most of the importer
        code such as the classes used for importing resources.
      * app/workers/gitlab/github_import: this directory contains the Sidekiq
        workers, most of which simply use the code from the directory above.
      * app/workers/concerns/gitlab/github_import: this directory provides a
        few modules that are included in every GitHub importer worker.
      
      == Stages
      
      The import work is divided into separate stages, with each stage
      importing a specific set of data. Stages will schedule the work that
      needs to be performed, followed by scheduling a job for the
      "AdvanceStageWorker" worker. This worker will periodically check if all
      work is completed and schedule the next stage if this is the case. If
      work is not yet completed this worker will reschedule itself.
      
      Using this approach we don't have to block threads by calling `sleep()`,
      as doing so for large projects could block the thread from doing any
      work for many hours.
      
      == Retrying Work
      
      Workers will reschedule themselves whenever necessary. For example,
      hitting the GitHub API's rate limit will result in jobs rescheduling
      themselves. These jobs are not processed until the rate limit has been
      reset.
      
      == User Lookups
      
      Part of the importing process involves looking up user details in the
      GitHub API so we can map them to GitLab users. The old importer used
      an in-memory cache, but this obviously doesn't work when the work is
      spread across different threads.
      
      The new importer uses a Redis cache and makes sure we only perform
      API/database calls if absolutely necessary.  Frequently used keys are
      refreshed, and lookup misses are also cached; removing the need for
      performing API/database calls if we know we don't have the data we're
      looking for.
      
      == Performance & Models
      
      The new importer in various places uses raw INSERT statements (as
      generated by `Gitlab::Database.bulk_insert`) instead of using Rails
      models. This allows us to bypass any validations and callbacks,
      drastically reducing the number of SQL queries and Gitaly RPC calls
      necessary to import projects.
      
      To ensure the code produces valid data the corresponding tests check if
      the produced rows are valid according to the model validation rules.
      Verified
      4dfe26cd
  19. Nov 03, 2017
  20. Nov 02, 2017
  21. Nov 01, 2017
  22. Oct 31, 2017
  23. Oct 27, 2017
  24. Oct 24, 2017
  25. Oct 13, 2017
  26. Oct 12, 2017
  27. Oct 11, 2017
  28. Oct 09, 2017
  29. Oct 07, 2017
    • Jacopo's avatar
      Replaces `tag: true` into `:tag` in the specs · 0ce67858
      Jacopo authored
      Replaces all the explicit include metadata syntax in the specs (tag:
      true) into the implicit one (:tag).
      Added a cop to prevent future errors and handle autocorrection.
      0ce67858
  30. Oct 04, 2017
Loading