The patch doesn't solve checking if package can send result to it's namespace (only firefox can send results into pkg.firefox etc.) which will be added with dist-git style tasks support.
Details
- Reviewers
kparal tflink jskladan - Maniphest Tasks
- T715: Implement result-naming whitelist checking in libtaskotron
- Commits
- rLTRN94f5bcbd6c46: Add result namespaces whitelist
Use the following header in task formula:
name: checkname namespace: qa desc: download specified Koji build and run rpmlint on it maintainer: jdoe
If namespace is omitted, scratch is used.
Worked for me.
Diff Detail
- Repository
- rLTRN libtaskotron
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Code as is looks OK, from the functional standpoint, but:
- how about just using checkname (i.e. the name key in the task formula's header) for it - qa.depcheck for example - it is in one place, and we can always just .split the text to separate the checkname and namespace
- if we go with separate namespace key, then I'd rather have it in the task's header (i.e. just below name), instead of an argument for resultsdb. I don't thing that it is, or should be resultsdb exclusive, but more of a general concept.
My idea of how this would work was a bit different than current implementation. I thought the namespace would be determined automatically based on the git url, i.e. the user would not need to specify it (neither in checkname nor anywhere else). If we do that automatically, there is no space for user mistakes, and tasks are easier to write. We just need to make sure the final namespace+checkname is printed out visibly during reporting process. Is there a reason why we can't make this automatic?
But thinking more about this, there is definitely a use case for overriding the namespace - when you want to test some changes and submit to scratch or similar namespace. In this case we should make possible to redefine it manually. And in this case adding it as an argument to resultsdb directive makes sense. Or it can be a top-level argument in the formula as @jskladan says, both is fine (something like namespace_override?).
| conf/taskotron.yaml.example | ||
|---|---|---|
| 54–64 ↗ | (On Diff #1949) | I think this would deserve a separate config file, this seems similar to e.g. yumrepoinfo.conf - very specific and likely more and more expanding configuration. Also, maybe we could install the default values into /usr/share, so that we can rely it's always there, and allow overriding this in /etc/, but not install it by default? (Thinking about this, we could do the same for yumrepoinfo.conf, I'd be happy to post a patch). For the moment and keeping this patch simple, we could do the same as the current approach of yumrepoinfo.conf, i.e. /etc/ or nothing, but if people agree with this, I'd then refactor it later. |
| 55–56 ↗ | (On Diff #1949) | So why exactly is pkg in namespaces_safe? Shouldn't it also be in namespaces_whitelist, and only tasks from distgit be able to post into it? |
| libtaskotron/config_defaults.py | ||
| 91–97 ↗ | (On Diff #1949) | If we go the route similar to yumrepoinfo.conf, we can drop this. |
| libtaskotron/directives/resultsdb_directive.py | ||
| 186–187 | It's true that this check is no longer needed. If this patch takes a longer time to fine-tune, maybe you can submit this separately, thanks. | |
| 209 | Now it's just 'task', not 'taskfile'. Sorry :) | |
The approach here seems fine but I'd like to see some more test coverage. Some "happy path" around just the namespace acceptance would be nice but I think that tests around behavior when reporting to an "unauthorized" namespace needs to be in place.
Overall, looks good to me. I don't understand why you removed those yaml formula tests, though.
| libtaskotron/directives/resultsdb_directive.py | ||
|---|---|---|
| 225 | "Skipping posting the results" sounds weird to me. Maybe "Not posting results"? | |
| testing/test_taskformula.py | ||
| 16 | What's the thought process behind removing these tests? | |
| testing/test_taskformula.py | ||
|---|---|---|
| 16 | I wasn't looking closely enough at what the tests were doing, point taken. | |
| libtaskotron/config.py | ||
|---|---|---|
| 288 | If you try to parse : or %, you'll get ParserError and ScannerError. There might be more. We should document the exceptions, and quite possibly even wrap them into TaskotronValueError or TaskotronConfigError. Unit tests for this would be nice here. | |
| 300–306 | For both taskotron.yaml and yumrepoinfo.conf we raise TaskotronConfigError and crash when the config file is missing or invalid. I think we should do the same here, in order to have consistent behavior. (Also, if you detect incorrect values, please print out at least a warning). | |
| libtaskotron/directives/resultsdb_directive.py | ||
| 206–226 | Can we get a comment what this whole block is about? Thanks. | |
| 217 | Can you include the filename you were looking for in the error message? Maybe we could also mention that the remove needs to be named origin. | |
| libtaskotron/executor.py | ||
| 85 | This is nicer: self.formula.get('namespace', 'scratch') | |
| testing/test_resultsdb_directive.py | ||
| 86 | Can you please explain this? The test suite failed when building rpm, but not when run manually? Do you know why? | |
| libtaskotron/config.py | ||
|---|---|---|
| 288 | While true, it's out of scope of this patch. I just moved the method from other file. I'll fix it in different DR. | |
| 300–306 | If the config is missing or is invalid, parse_yaml_from_file will crash. In my mind, this code has the same purpose as config_defaults.py. Point taken on printing a warning though. | |
| libtaskotron/directives/resultsdb_directive.py | ||
| 206–226 | +1 | |
| 217 | +1 | |
| libtaskotron/executor.py | ||
| 85 | Ah, I always forget the get method. :/ | |
| testing/test_resultsdb_directive.py | ||
| 86 | Because it didn't find the config file namespace.conf in the building env. I just realized I should have dealt with this the same way as we do with our main config (not touching files in testing profile). | |
| libtaskotron/config_defaults.py | ||
|---|---|---|
| 83 ↗ | (On Diff #1995) | Hm? |
| libtaskotron/config_defaults.py | ||
|---|---|---|
| 83 ↗ | (On Diff #1995) | Disregard this comment, for some reason I saw it reversed, and now it's not even a part of the diff. /me is confused. |
If you try to parse : or %, you'll get ParserError and ScannerError. There might be more. We should document the exceptions, and quite possibly even wrap them into TaskotronValueError or TaskotronConfigError. Unit tests for this would be nice here.