4dfe26cd8b
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. |
||
|---|---|---|
| .github | ||
| .gitlab | ||
| app | ||
| bin | ||
| builds | ||
| changelogs | ||
| config | ||
| db | ||
| doc | ||
| docker | ||
| features | ||
| fixtures/emojis | ||
| generator_templates | ||
| lib | ||
| locale | ||
| log | ||
| public | ||
| qa | ||
| rubocop | ||
| scripts | ||
| shared | ||
| spec | ||
| symbol | ||
| tmp | ||
| vendor | ||
| .babelrc | ||
| .codeclimate.yml | ||
| .csscomb.json | ||
| .eslintignore | ||
| .eslintrc | ||
| .flayignore | ||
| .foreman | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .haml-lint.yml | ||
| .mailmap | ||
| .nvmrc | ||
| .pkgr.yml | ||
| .rubocop.yml | ||
| .rubocop_todo.yml | ||
| .ruby-version | ||
| .scss-lint.yml | ||
| CHANGELOG.md | ||
| CONTRIBUTING.md | ||
| GITALY_SERVER_VERSION | ||
| GITLAB_PAGES_VERSION | ||
| GITLAB_SHELL_VERSION | ||
| GITLAB_WORKHORSE_VERSION | ||
| Gemfile | ||
| Gemfile.lock | ||
| LICENSE | ||
| MAINTENANCE.md | ||
| PROCESS.md | ||
| Procfile | ||
| README.md | ||
| Rakefile | ||
| VERSION | ||
| config.ru | ||
| doc_styleguide.md | ||
| docker-compose.yml | ||
| package.json | ||
| yarn.lock | ||
README.md
GitLab
Test coverage
Ruby
JavaScript
Canonical source
The canonical source of GitLab Community Edition is hosted on GitLab.com.
Open source software to collaborate on code
To see how GitLab looks please see the features page on our website.
- Manage Git repositories with fine grained access controls that keep your code secure
- Perform code reviews and enhance collaboration with merge requests
- Complete continuous integration (CI) and CD pipelines to builds, test, and deploy your applications
- Each project can also have an issue tracker, issue board, and a wiki
- Used by more than 100,000 organizations, GitLab is the most popular solution to manage Git repositories on-premises
- Completely free and open source (MIT Expat license)
Hiring
We're hiring developers, support people, and production engineers all the time, please see our jobs page.
Editions
There are two editions of GitLab:
- GitLab Community Edition (CE) is available freely under the MIT Expat license.
- GitLab Enterprise Edition (EE) includes extra features that are more useful for organizations with more than 100 users. To use EE and get official support please become a subscriber.
Website
On about.gitlab.com you can find more information about:
- Subscriptions
- Consultancy
- Community
- Hosted GitLab.com use GitLab as a free service
- GitLab Enterprise Edition with additional features aimed at larger organizations.
- GitLab CI a continuous integration (CI) server that is easy to integrate with GitLab.
Requirements
Please see the requirements documentation for system requirements and more information about the supported operating systems.
Installation
The recommended way to install GitLab is with the Omnibus packages on our package server. Compared to an installation from source, this is faster and less error prone. Just select your operating system, download the respective package (Debian or RPM) and install it using the system's package manager.
There are various other options to install GitLab, please refer to the installation page on the GitLab website for more information.
You can access a new installation with the login root and password 5iveL!fe, after login you are required to set a unique password.
Contributing
GitLab is an open source project and we are very happy to accept community contributions. Please refer to CONTRIBUTING.md for details.
Install a development environment
To work on GitLab itself, we recommend setting up your development environment with the GitLab Development Kit. If you do not use the GitLab Development Kit you need to install and setup all the dependencies yourself, this is a lot of work and error prone. One small thing you also have to do when installing it yourself is to copy the example development unicorn configuration file:
cp config/unicorn.rb.example.development config/unicorn.rb
Instructions on how to start GitLab and how to run the tests can be found in the getting started section of the GitLab Development Kit.
Software stack
GitLab is a Ruby on Rails application that runs on the following software:
- Ubuntu/Debian/CentOS/RHEL/OpenSUSE
- Ruby (MRI) 2.3
- Git 2.8.4+
- Redis 2.8+
- PostgreSQL (preferred) or MySQL
For more information please see the architecture documentation.
UX design
Please adhere to the UX Guide when creating designs and implementing code.
Third-party applications
There are a lot of third-party applications integrating with GitLab. These include GUI Git clients, mobile applications and API wrappers for various languages.
GitLab release cycle
For more information about the release process see the release documentation.
Upgrading
For upgrading information please see our update page.
Documentation
All documentation can be found on docs.gitlab.com/ce/.
Getting help
Please see Getting help for GitLab on our website for the many options to get help.
Is it any good?
Is it awesome?
Thanks for asking this question Joshua. These people seem to like it.