-
Notifications
You must be signed in to change notification settings - Fork 111
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
Improve uptodateness of config reports across manager instances #7301
Conversation
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.
Seems to be kosher to me. Left only one ignorable suggestion
Crippled FS has a rerun test failure that looks unrelated: Click to expand
The failure on MacOS is #7286, and two of the Travis errors are installation failures. However, there is one Travis error that seems relevant to this change set:
Edit: I can reproduce this failure locally on this branch, and not on |
I've looked into the failure, and at the time in the test where we expect an unset Git identity, the Git identity is already set and keeps being set after a config manager reload:
I suppose this is not a bug, but rather a side effect of the bug this PR fixes. Since the dataset is fresh and doesn't have a config manager yet, this PR makes the config manager return the global one - which already has a Git identity set. |
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.
Thx, @mih.
Suggestions by @adswa and @yarikoptic make sense to me, otherwise I think this right and ready.
I think the trouble in that test is two-fold:
Edit: Will shortly push accordingly. (Done. I hope) |
Also ping datalad#7300 re diversity of exception behavior for one and the same issue.
This has seemlingly no purpose or use case. It only complicates the synchronization between, here needlessly, many manager instances. This addressed half of datalad#7299
...whenever the 'global' configuration scope was modified. Theoretically, this should also cover a 'system' scope, but presently `ConfigManager` does not recognize or support that. Closes datalad#7299
Use an independent `ConfigManager` instance to test the desire behavior, instead of one that is bound to a `Dataset` instance and thereby indirectly to `datalad.cfg`.
Co-authored-by: Yaroslav Halchenko <debian@onerussian.com>
Co-authored-by: Adina Wagner <adina.wagner@t-online.de>
approved so let's merge. I just rebased on top of current maint to get a fresh run since prior one was plagued with redness. will merge if all good |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## maint #7301 +/- ##
==========================================
+ Coverage 88.08% 90.68% +2.60%
==========================================
Files 327 327
Lines 44592 44609 +17
Branches 5906 5907 +1
==========================================
+ Hits 39278 40453 +1175
+ Misses 5299 4141 -1158
Partials 15 15
... and 48 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
travis and appveyor green -- some flukes on OSX I will not even look into... |
PR released in |
The issue is described in #7299. This change set contains three commits
ConfigManager
instances forDataset
s without a repositorydatalad.cfg
instance, whenever anyConfigManager
updated theglobal
configuration scopeCloses #7299