-
Georges Racinet authored
Following the examples from https://docs.gitlab.com/ce/development/feature_flags/index.html, we are introducing two feature flags: - `hg_fully_native` will be used to switch the whole instance to the fully native mode to be developped (HGitaly2 milestone). - `hgitaly1_fallback` will be used to get back for a specific project to the partial native mode of HGitaly1 The evaluation is done relative to the whole instance or the project. Setting these feature flags for a group does nothing. This should be good enough for our progressive testing strategy. The documentation also warns against using several actors for one feature flag, hence we would need a third one to introduce group-level control. The convenience method `hgitaly1?` on the Project model provides a uniform way to know if the project is a Mercurial native one, running in HGitaly1 mode. To that end, it combines the `vcs_type` field and the feature flag, so that the result is meaningful for all kinds of projects. Because the code controlled by the feature flags will typically be one of the `GitalyClient` classes, it won't have direct access to the relevant project. Hence we are also providing the `hgitaly1?` method, on the three raw repository classes, that should in practice be the one to use from most code, notably classes within the `GitalyClient` module. Finally, we introduce new RSpec example files for the Project and Repository models in the Mercurial cases. That will help minimize useless conflicts when merging upstream GitLab. Because we don't have much specifics, it didn't seem useful to make separate files for the Repository model: we're testing the Repository (its `raw_repository` factory method notably), together with `Project#hgitaly1?`.
25538af903cb