Geo Replicables - SSF Resync Action
What does this MR do and why?
Part 1 of 2 for #364727 (closed)
This change adds a Resync Mutation to the Geo Replication views for SSF Replicables. These Replicables are served via GraphQL while the legacy Replicables are served by either RESTful API or Rails/HAML.
This change is behind a feature flag :geo_registries_update_mutation
Important Context
For all the tabs in the Geo Replication View, the breakdown is as follows:
- Projects - Served via HAML/Rails and is unaffected and unchanged by this change.
- Designs - Served via RESTful API and uses shared Vue components. Should be affected but unchanged by this change.
- Every other tab - Served via GraphQL API and uses shared Vue components. Should be affected and changed by this change.
Screenshots or screen recordings
Geo SSF Replicables Tabs, main focus of this change (every tab aside from Projects and Designs)
Screenshot | Usage Video | |
---|---|---|
Before | N/A | |
After | SSF_Usage_-_After |
Designs Tab - Affected but unchanged by this change
Click to see screenshots/videos
Screenshot | Usage Video | |
---|---|---|
Before | Non_SSF_Usage_-_Before | |
After | Non_SSF_Usage_-_After |
How to set up and validate locally
- Fetch and checkout this branch
- Setup Geo by following the 1-line installation in the Easy Installation section (How to setup Geo)
- Enable Feature Flag
Feature.enable(:geo_registries_update_mutation)
- Access your Secondary GDK UI
- Navigate to the Geo Replication View for Designs (ex.
http://127.0.0.1:3001/admin/geo/replication/designs
) - Ensure Designs Tab resync action works as before this change (aside from filters order)
- Navigate to another tab (aside from Projects) and ensure the resync action works as expected
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #411981 (closed)
Edited by Zack Cuddy