-
Notifications
You must be signed in to change notification settings - Fork 429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Improve versioned change requests to handle multiple open CRs for single feature #4245
feat: Improve versioned change requests to handle multiple open CRs for single feature #4245
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 3 Skipped Deployments
|
Uffizzi Preview |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4245 +/- ##
==========================================
+ Coverage 96.79% 96.81% +0.02%
==========================================
Files 1162 1165 +3
Lines 38248 38508 +260
==========================================
+ Hits 37021 37281 +260
Misses 1227 1227 ☔ View full report in Codecov by Sentry. |
…change-requests-for-single-feature
|
|
17cabe9
to
dc23c92
Compare
dc23c92
to
c74be59
Compare
…change-requests-for-single-feature
…change-requests-for-single-feature
6300a7f
to
f17678b
Compare
Changes
This PR is the 'Core' part of the resolution to #4145.
In this PR, I've added most of the business logic which hinges on the
VersionChangeSet
model. This model is created alongside a change request (as per the code in this workflows PR) and holds the information about the changes that should be applied when the change request is published (or goes live if it's scheduled).The reason for this is to remove the need to duplicate the version when a change request is created, resulting in conflicts / clobbering of changes that happen between PR creation and publish.
As part of this work, however, we need to account for the fact that there could still be conflicts, they're just less likely and less destructive. The conflict behaviour here checks if changes have been made to the same component of a feature in a given environment (e.g. a specific segment override, or the environment default value). These conflicts are then surfaced by the FE to provide visibility.
How did you test this code?
I've added enough tests in this repository to satisfy the coverage requirements, but a lot of the testing has been done via full integration tests in the flagsmith-workflows PR here.