-
Notifications
You must be signed in to change notification settings - Fork 7
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
Begin versioning Assigner configs #111
Conversation
13a2d49
to
ce993b6
Compare
"name": "gitlab", | ||
"token": "xxx gitlab token xxx", | ||
"host": "https://git.gitlab.com", | ||
}, |
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.
@brhoades What do you think of this configuration schema? If you like it, I'll update the rest of the code to work with it.
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.
The schema will go something like this: the backend
field is a JSON object with at least one key, name
. The remainder of the data will be something that we can pass to the Backend
class and it will be able to pull what it needs out of that.
So, for the mock
backend, the config would look like
"backend" : { "name" : "mock" }
Seem sensible?
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 want to make sure I understand you right. Are you referring to the schema here, where we double check the functions are properly enforcing schema version differences? Or do you mean in general :D?
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 mean for the newest schema, in preparation for #102 😄
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.
This looks good. Will allow nonbreaking backend additions.
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.
Cool -- in that case I'll propagate the change through BaseRepo
et. al.
ccfbc36
to
7c8fada
Compare
assigner/config/schemas.py
Outdated
@@ -0,0 +1,282 @@ | |||
|
|||
SCHEMAS = [ |
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 worry this would get unruly fast. It's less rigid but would make more sense to define INITIAL_SCHEMA, make that version 0/1, then copy it and modify what changed in two as part of the script. Then you only need to read blocks of code to determine changes rather than hunting for comments.
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.
You've got copy.deepcopy
if you agree ;).
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 fear that writing diff functions rather than schemas will make it harder to write schemas (the proposed version 2 schema required some troubleshooting) and that it'll slow down startup -- if we could constexpr
all of this that would be great...
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.
That's fine with me. I just feel there's a better way to orgfanize this. Maybe different files for each schema version?
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.
Yeah, we can do that!
from assigner.config.upgrades import UPGRADES | ||
|
||
logger = logging.getLogger(__name__) | ||
|
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.
np: 2 spacesssssssssssssssssssssssssss
We need that flake8 linter.
assigner/config/versions.py
Outdated
|
||
|
||
def validate(config, version=(len(SCHEMAS) - 1)): | ||
assert version < len(SCHEMAS) |
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've never seen this. I noticed it was a builtin but this makes sense.
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.
Yeah! I should rename this to _validate
or rewrite this to throw...going to do the former.
assigner/config/versions.py
Outdated
pass | ||
|
||
|
||
def validate(config, version=(len(SCHEMAS) - 1)): |
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.
You can put expressions for parameter defaults?
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.
Apparently so!
def test_validate(self): | ||
for version, config in enumerate(CONFIGS): | ||
try: | ||
validate(config, version) |
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.
Two alternatives:
with self.assertRaises(ValidationError):
validate(config, version)
or
self.assertRaises(validate, config, version)
I prefer the former.
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.
Wait, I want the opposite of assertRaises
. Does such a thing exist?
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.
Oh, yeah, just run the function :DD. If an exception is thrown, BAM. Assuming you're doing try: ... except: ... self.fail, that's fine.
"name": "gitlab", | ||
"token": "xxx gitlab token xxx", | ||
"host": "https://git.gitlab.com", | ||
}, |
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 want to make sure I understand you right. Are you referring to the schema here, where we double check the functions are properly enforcing schema version differences? Or do you mean in general :D?
7c8fada
to
33d832b
Compare
assigner/config/versions.py
Outdated
for version in range(current, latest): | ||
config = UPGRADES[version](config) | ||
assert get_version(config) == version + 1 | ||
_validate(config, version) |
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.
So, validation is a tricky thing here. Ideally we'd like to detect when a config goes from valid -> invalid, but in the case that a config is invalid to begin with, what do we do? The primary case of an invalid config is when assigner is run with no _config.yml
and defaults to an empty config.
I suppose we could require that upgrade functions have to succeed even if they're handed a malformed config (which is what they do right now) and test that upgrading an empty config succeeds (which is what we do right now).
47b36e1
to
75204e9
Compare
@@ -0,0 +1,63 @@ | |||
import logging |
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.
My merge conflict sense is tingling.
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.
???
- Add schemas for versions 0, 1, and 2 - Schema validation - Upgrading configs from one version to the next
bf24a1d
to
60308fd
Compare
TODO:
assigner
to use v2 config