diff options
Diffstat (limited to 'doc')
-rw-r--r-- | doc/development/diffs.md | 3 | ||||
-rw-r--r-- | doc/development/gitaly.md | 57 | ||||
-rw-r--r-- | doc/development/instrumentation.md | 4 |
3 files changed, 3 insertions, 61 deletions
diff --git a/doc/development/diffs.md b/doc/development/diffs.md index 5e8e8cc7541..c8ced445027 100644 --- a/doc/development/diffs.md +++ b/doc/development/diffs.md @@ -2,13 +2,10 @@ Currently we rely on different sources to present diffs, these include: -- Rugged gem - Gitaly service - Database (through `merge_request_diff_files`) - Redis (cached highlighted diffs) -We're constantly moving Rugged calls to Gitaly and the progress can be followed through [Gitaly repo](https://gitlab.com/gitlab-org/gitaly). - ## Architecture overview ### Merge request diffs diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md index f4784c19359..32beafad307 100644 --- a/doc/development/gitaly.md +++ b/doc/development/gitaly.md @@ -1,11 +1,7 @@ # GitLab Developers Guide to Working with Gitaly [Gitaly](https://gitlab.com/gitlab-org/gitaly) is a high-level Git RPC service used by GitLab CE/EE, -Workhorse and GitLab-Shell. All Rugged operations in GitLab CE/EE are currently being phased out to -be replaced by Gitaly API calls. - -Visit the [Gitaly Migration Board](https://gitlab.com/gitlab-org/gitaly/boards/331341) for current -status of the migration. +Workhorse and GitLab-Shell. ## Developing new Git features @@ -52,57 +48,6 @@ comfortable writing Go code. There is documentation for this approach in [the Gitaly repo](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/ruby_endpoint.md). -## Modifying existing Git features - -If you modify existing Git features in `lib/gitlab/git` you need to make -sure the changes also work in Gitaly. Because we are still in the -migration process there are a number of subtle pitfalls. Features that -have been migrated have dual implementations (Gitaly and local). The -Gitaly implementation may or may not use a vendored (and therefore -possibly outdated) copy of the local implementation in `lib/gitlab/git`. - -To avoid unexpected problems and conflicts, all changes to -`lib/gitlab/git` need to be approved by a member of the Gitaly team. - -For the time being, while the Gitaly migration is still in progress, -there should be no Enterprise Edition-only Git code in -`lib/gitlab/git`. Also no mixins. - -## Feature Flags - -Gitaly makes heavy use of [feature flags](feature_flags.md). - -Each Rugged-to-Gitaly migration goes through a [series of phases](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/MIGRATION_PROCESS.md): - -* **Opt-In**: by default the Rugged implementation is used. - * Production instances can choose to enable the Gitaly endpoint by enabling the feature flag. - * For testing purposes, you may wish to enable all feature flags by default. This can be done by exporting the following - environment variable: `GITALY_FEATURE_DEFAULT_ON=1`. - * On developer instances (ie, when `Rails.env.development?` is true), the Gitaly endpoint - is enabled by default, but can be _disabled_ using feature flags. -* **Opt-Out**: by default, the Gitaly endpoint is used, but the feature can be explicitly disabled using the feature flag. -* **Mandatory**: The migration is complete and cannot be disabled. The old codepath is removed. - -### Enabling and Disabling Feature - -In the Rails console, type: - -```ruby -Feature.enable(:gitaly_feature_name) -Feature.disable(:gitaly_feature_name) -``` - -Where `gitaly_feature_name` is the name of the Gitaly feature. This can be determined by finding the appropriate -`gitaly_migrate` code block, for example: - -```ruby -gitaly_migrate(:tag_names) do -... -end -``` - -Since Gitaly features are always prefixed with `gitaly_`, the name of the feature flag in this case would be `gitaly_tag_names`. - ## Gitaly-Related Test Failures If your test-suite is failing with Gitaly issues, as a first step, try running: diff --git a/doc/development/instrumentation.md b/doc/development/instrumentation.md index a14c0752366..7761f65d78a 100644 --- a/doc/development/instrumentation.md +++ b/doc/development/instrumentation.md @@ -69,7 +69,7 @@ The easiest way to check if a method has been instrumented is to check its source location. For example: ```ruby -method = Rugged::TagCollection.instance_method(:[]) +method = Banzai::Renderer.method(:render) method.source_location ``` @@ -82,7 +82,7 @@ method (along with its source location), this is easier than running the above Ruby code. In case of the above snippet you'd run the following: ``` -$ Rugged::TagCollection#[] +$ Banzai::Renderer.render ``` This will print out something along the lines of: |