-
Notifications
You must be signed in to change notification settings - Fork 129
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
Fixes to augur export #1218
Fixes to augur export #1218
Conversation
The logic for creating colorings involves many steps, and when adding a coloring we had neglected to check if it had already been added. For instance, colorings explicitly defined in the auspice-config which were provided via node-data files (rather than the metadata tsv) would be added twice. In our current nCoV build there are 7 such duplicates! There were also a few duplicates that were present in our tests. Whoops! These weren't a problem for auspice (the first was used), but added unnecessary complexity and bytes to the JSON. Closes #719
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #1218 +/- ##
==========================================
+ Coverage 68.81% 68.88% +0.07%
==========================================
Files 64 64
Lines 6936 6939 +3
Branches 1692 1693 +1
==========================================
+ Hits 4773 4780 +7
+ Misses 1856 1854 -2
+ Partials 307 305 -2
☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a minor non-blocking comment, but otherwise this looks good to me.
The intention of the coloring logic is that if an auspice-config provides the clade_membership key then it is exported at that position in the colorings list. If clade_membership is not explicitly set in the config (but is present in a node-data file) then we have (for a very long time) added it as the very first entry in the colorings list. PR #728 (augur v22.0.0) erroneously modified the behavior of the second case described above, which has now been restored by this commit.
a8f1451
to
9e9d4a4
Compare
See commit messages for details.
I suggest we fast-track review & merge of this PR and then make an augur release to include these changes as well as #1214
Checklist