-
Notifications
You must be signed in to change notification settings - Fork 11
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
Add validation for paths in config #166
Conversation
I should be clear that this is only very lightly tested. I aimed to spend no more time on it than the image builder spent on a doomed image build overnight :) |
So lightly tested that it fails its tests! |
47d111e
to
0775b73
Compare
Oh I guess I can't use @dbnicholson I'm curious what you think about this approach, before I mess with going back to Of course this wouldn't catch the error at PR time – I think the way to do that would be to have a list of known combinations of fields and have a GitHub Actions job which validates the config for all those. (And a similar job in the private config repo which is where the error occurred.) My old idea there is to again abuse the schema. Add the following to the config: [build]
configtuple = ${product}-${arch}-${platform}-${personality} and then add to the schema:
|
Sorry, I meant to reply to this long ago. I think it's a nice idea, and I would switch away from
Generally I like this idea, but we'd only be able to manage the allowed values in our private config repo. It would be artificially limiting to 3rd parties to constrain those fields in this repo. Oh, it does look like I added the ability to read the schema from the local directory in 3e03f8a, so that's good. Unfortunately, it doesn't merge values, so any schema value we put in this repo would have to be duplicated. It might be nice to be able to use wildcards to you could have an allowed value like |
I think wildcards would be useful even in the private repo. We have often made an identical copy of an existing personality with a project-specific suffix just to give it a distinctive name for our activation/metrics data. With the changes on #169 we'd no longer need to change anything in the repo to build an identical-in-all-but-name derived image. It would be sad to have to update the schema each time... I'll see if I can find time this week to revive this one. |
2e470f3
to
ec72cbb
Compare
Previously, if a filename referred to in the configuration does not exist, that would only be discovered when the hook which uses that key runs, which may be minutes or hours into the build. Add a way to specify in the schema that certain keys must be set to a single path to an extant file, or a list of paths to extant files. https://phabricator.endlessm.com/T35517
Based on a quick review of the hooks in this repo, I think this covers all the likely candidates. https://phabricator.endlessm.com/T35517
ec72cbb
to
8f8d720
Compare
Revised this to use more traditional Python syntax and add a test. I didn't add any of the config tuple validation stuff described above. |
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.
👍
Previously, if a filename referred to in the configuration does not exist, that would only be discovered when the hook which uses that key runs, which may be minutes or hours into the build.
Add a way to specify in the schema that certain keys must be set to a single path to an extant file, or a list of paths to extant files.
Add
key_type = path(s)
annotations to the schema for all (I think) of the file-likekey
s used by hooks in this repo.https://phabricator.endlessm.com/T35517