-
Notifications
You must be signed in to change notification settings - Fork 15
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
[WIP] make pipeline cleaner (Cont. #33) #36
base: master
Are you sure you want to change the base?
Conversation
src/core.jl
Outdated
GLOBAL_TESTMODE = _get_testmode() | ||
end | ||
return GLOBAL_TESTMODE | ||
end |
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.
TestMode()
generates a runtime singleton flag.
Please enlighten me if there's a best-practice as an alternative to this usage.
The coverage decreases because CI can't capture codes for |
d87fd0b
to
6b3e903
Compare
I'm not satisfied with the current codes in this PR, but I don't have better ideas now. One key question is: what advantages it brings to us if it doesn't only rely on |
I like this concept overall. I think
In all of them you get at least a warning and a display of the differences. And those behavours can be applied in 2 circumstances:
We can handle the combination via multiple dispatch. There is a case to be made for making the default setting be: Or if you expect everything to be invalidated you just switch to Create on Both. Having used this inpractice a bit, this is fine, |
Cont. #33
In this PR, a "constant" global runtime flag
TestMode
is introduced so that it's easier to handle environment variables mentioned in #8This may have many use cases, for example, in this PR I dispatch
_create_new_reference
and_update_reference
onTestMode
.The first commit doesn't change the behavior of
reference_test
. I'd love to hear advice about what you'd like to have in further commits.