Skip to content

Clean up legacy Gitaly Wiki RPCs in Rails

What does this MR do and why?

For gitaly#4512 (closed)

In &2381 (closed), we attempted to migrate all Gitaly Wiki-specific RPCs to normal repository RPCs. To manage the risk, we control the replacement codes behind two feature flags. The main code changes and feature flags were introduced in two major MRs:

Both of the feature flags were rolled out globally on production for a while (find_page, list_pages). We also enabled those flags by default in !100560 (merged).

Therefore, it's time to wipe out relevant code paths leading to the legacy Wiki-specific RPC calls and of course two feature flags. Although the size of this MR is a bit huge, moist of the code changes are code deletions and update tests. It's tricky to split this into smaller MRs because the legacy codes don't have enough code coverage. So, in this MR, I'm trying to remove the most significant code paths and leave some others untouched. In details:

  • Remove feature flag checks, and code paths to legacy RPCs of list_pages and find_page in app/models/wiki.rb. I'm keeping the structure to reduce the complexity.
  • Remove lib/gitlab/git/wiki.rb. It acts as a data transformation from Gitaly. This class contains some utility methods. So, I moved those methods to app/modles/wiki.rb.
    • Remove ::Wiki.wiki. This method creates an instance of Gitlab::Git::Wiki mentioned above. We don't need it anymore. Afterward, I added some create_wiki_repository calls to guard the cases where wiki repository is not initialized.
  • Remove lib/gitlab/gitaly_client/wiki_service.rb. This class contains a wrapper to trigger Wiki* RPCs. Obviously, they are not needed anymore.
  • Update corresponding tests. The prior MRs used shared examples to replicate the tests when the flags are on/off. I intentionally keep the shared examples to reduce the code changes. In the next MR, I'll continue to flatten them out.

Screenshots or screen recordings

This MR does not introduce any changes.

How to set up and validate locally

I performed the full flows of how a user interacts with Wiki feature on local environment, including create/update/delete/list/filter actions on the UI and via git repository. The tests are repeated for group and project wikis.

  • Create a page
  • Create a page with special character
  • Update a page
  • View page versions
  • View a historical page
  • Compare page versions
  • Delete a page
  • Normal sidebar
  • Sidebar having "View more" button
  • View all pages, sorted ascending and descending, combine with pagination
  • Wiki activities shown up in Project Activity page
  • Wiki pages are searchable by both title and content
  • APIs work

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Quang-Minh Nguyen

Merge request reports