Skip to content
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

Merged
merged 7 commits into from
Feb 11, 2018
Merged

Conversation

LinuxMercedes
Copy link
Member

@LinuxMercedes LinuxMercedes commented Feb 2, 2018

TODO:

  • Changelog
  • Upgrade assigner to use v2 config

@LinuxMercedes LinuxMercedes changed the title Begin versioning Assigner configs [WIP] Begin versioning Assigner configs Feb 2, 2018
@LinuxMercedes LinuxMercedes force-pushed the pr/versioned-config branch 2 times, most recently from 13a2d49 to ce993b6 Compare February 2, 2018 04:55
"name": "gitlab",
"token": "xxx gitlab token xxx",
"host": "https://git.gitlab.com",
},
Copy link
Member Author

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.

Copy link
Member Author

@LinuxMercedes LinuxMercedes Feb 4, 2018

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?

Copy link
Member

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?

Copy link
Member Author

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 😄

Copy link
Member

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.

Copy link
Member Author

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.

@@ -0,0 +1,282 @@

SCHEMAS = [
Copy link
Member

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.

Copy link
Member

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 ;).

Copy link
Member Author

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...

Copy link
Member

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?

Copy link
Member Author

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__)

Copy link
Member

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.



def validate(config, version=(len(SCHEMAS) - 1)):
assert version < len(SCHEMAS)
Copy link
Member

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.

Copy link
Member Author

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.

pass


def validate(config, version=(len(SCHEMAS) - 1)):
Copy link
Member

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?

Copy link
Member Author

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)
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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",
},
Copy link
Member

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?

for version in range(current, latest):
config = UPGRADES[version](config)
assert get_version(config) == version + 1
_validate(config, version)
Copy link
Member Author

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).

@LinuxMercedes LinuxMercedes force-pushed the pr/versioned-config branch 7 times, most recently from 47b36e1 to 75204e9 Compare February 9, 2018 05:24
@LinuxMercedes LinuxMercedes changed the title [WIP] Begin versioning Assigner configs Begin versioning Assigner configs Feb 9, 2018
@@ -0,0 +1,63 @@
import logging
Copy link
Member

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

???

brhoades
brhoades previously approved these changes Feb 9, 2018
brhoades
brhoades previously approved these changes Feb 9, 2018
@LinuxMercedes LinuxMercedes merged commit 1338df9 into master Feb 11, 2018
@LinuxMercedes LinuxMercedes deleted the pr/versioned-config branch February 11, 2018 00:19
@LinuxMercedes LinuxMercedes added this to the v2.0 milestone Dec 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

PackingType of packed-Refs not understood: '# pack-refs with: peeled fully-peeled sorted'
2 participants