0395c47193
This commit migrates events data in such a way that push events are stored much more efficiently. This is done by creating a shadow table called "events_for_migration", and a table called "push_event_payloads" which is used for storing push data of push events. The background migration in this commit will copy events from the "events" table into the "events_for_migration" table, push events in will also have a row created in "push_event_payloads". This approach allows us to reclaim space in the next release by simply swapping the "events" and "events_for_migration" tables, then dropping the old events (now "events_for_migration") table. The new table structure is also optimised for storage space, and does not include the unused "title" column nor the "data" column (since this data is moved to "push_event_payloads"). == Newly Created Events Newly created events are inserted into both "events" and "events_for_migration", both using the exact same primary key value. The table "push_event_payloads" in turn has a foreign key to the _shadow_ table. This removes the need for recreating and validating the foreign key after swapping the tables. Since the shadow table also has a foreign key to "projects.id" we also don't have to worry about orphaned rows. This approach however does require some additional storage as we're duplicating a portion of the events data for at least 1 release. The exact amount is hard to estimate, but for GitLab.com this is expected to be between 10 and 20 GB at most. The background migration in this commit deliberately does _not_ update the "events" table as doing so would put a lot of pressure on PostgreSQL's auto vacuuming system. == Supporting Both Old And New Events Application code has also been adjusted to support push events using both the old and new data formats. This is done by creating a PushEvent class which extends the regular Event class. Using Rails' Single Table Inheritance system we can ensure the right class is used for the right data, which in this case is based on the value of `events.action`. To support displaying old and new data at the same time the PushEvent class re-defines a few methods of the Event class, falling back to their original implementations for push events in the old format. Once all existing events have been migrated the various push event related methods can be removed from the Event model, and the calls to `super` can be removed from the methods in the PushEvent model. The UI and event atom feed have also been slightly changed to better handle this new setup, fortunately only a few changes were necessary to make this work. == API Changes The API only displays push data of events in the new format. Supporting both formats in the API is a bit more difficult compared to the UI. Since the old push data was not really well documented (apart from one example that used an incorrect "action" nmae) I decided that supporting both was not worth the effort, especially since events will be migrated in a few days _and_ new events are created in the correct format. |
||
|---|---|---|
| .github | ||
| .gitlab | ||
| app | ||
| bin | ||
| builds | ||
| changelogs | ||
| config | ||
| db | ||
| doc | ||
| docker | ||
| features | ||
| fixtures/emojis | ||
| generator_templates | ||
| lib | ||
| locale | ||
| log | ||
| public | ||
| qa | ||
| rubocop | ||
| scripts | ||
| shared | ||
| spec | ||
| 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.