ckan_config test mark works with request context#6868
Merged
Conversation
Member
|
@smotornyuk this makes sense, but it would be nice to get rid of all that app_globals weird logic eventually |
alexandru-m-g
added a commit
to OCHA-DAP/hdx-ckan
that referenced
this pull request
Nov 3, 2022
This is related to the CKAN 2.9.7 upgrade, because of this change in CKAN core: ckan/ckan#6868
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #6841
app_globalsmodule caches a set of the config options with their values when test execution started(just like it does every time web-server is launched). After that, every time the application object is created or the list of plugins is reloaded, the mentioned config options restore their original value, even if they were modified(via theckan_configmark, for example)It can be fixed by the clearing
app_globalscache whenever a config object is required inside the test. But it creates another issue. Without the "initial" cached state, every change to the config object that is done directly(not viackan_configmark ormonkeypatchfixture), will affect all consequent tests. For example, code that tests overriding configuration via admin interface can set site title and all the other tests will reuse the updated title, not the original value defined by the configuration file.That's why I'm creating a copy of the config object that was used before any test execution and resetting
ckan.common.configstate before each test using this snapshot.