Work in progress - initial version of depcheck's per-update reporting.
Details
- Reviewers
kparal tflink - Commits
- rDEPCKd13b035f8a23: T195 - Depcheck reports results per update
rDEPCK277d15e9d4cc: fixed conf file
rDEPCK3b3d01bf6724: typos
rDEPCK6330623ba7c7: Functional tests run and mean something
rDEPCK6e29020af65a: Minor fix
rDEPCKfb9887e72f6f: removed output.py
rDEPCKe831a3498ac9: t195 - grouping results per update
rDEPCK43921c10b920: t195 - minor sanity changes
rDEPCK7f823133359d: Moar Comments
rDEPCK19b94716d8a3: fixed obvious typos
rDEPCK66ba8c9b004f: Moar tests
rDEPCK8cc07032b75e: removed unnecessary run method in depcheck.py
rDEPCKbd797217b7f6: remove self.run_result
rDEPCKf67661fe7212: renamed some methods
rDEPCKbb95550643a4: Changed as per @tflink's requests
rDEPCK3b1e30bfdc83: tflink's catches
None for the new functionality so far, but current tests were altered.
Diff Detail
- Repository
- rDEPCK task-depcheck
- Lint
Lint Skipped - Unit
Unit Tests Skipped
| depcheck/depcheck.py | ||
|---|---|---|
| 45 | According to my information, all RPMs in Fedora should be in the <NVRA>.rpm format, so this is fine for us. Should we ever want to run depcheck for systems with other standards, this would have to be changed. But it is no issue so far, IMHO. | |
| 150 | This here is "just for safety" I do not suppose that there should even be a situation which leads to depcheck having two results for the same rpm file, but in case it happens, I think it's best to let us known. Is there a situation that would yield depcheck running for (let's say) two "same" NVRs just with different Arch, when (on top of that) one of them could fail, and the other pass? | |
| 160 | I am not sure why there is the json option, as we IMHO do not need it. Could you elaborate, @jdulaney? | |
| 162 | Does the comment & code make sense? I tried my best to describe it, but I'm not sure that it is necessarily clear. | |
The code passes both unittests and functional tests, but I have not tried it in any other way.
@tflink could you try and run it via Taskotron?
The code is now changed according to @tflink's request - squashing results from builds to updates is moved to another file, per-build results are returned in json, and per-uptade results in TAP. Per-build or per-update can be configured and handled via console parameter.
I also made some code refactoring. Please comment :)
The code is not tested outside of the unit/funcional-tests.
Overall, looks pretty good to me - just a couple minor change requests. We'll have to test with actual runs once the other bits of depcheck are sorted out but I'm hoping that'll be relatively minor.
| depcheck/__init__.py | ||
|---|---|---|
| 88 | Shouldn't this be for filename in rpms:? | |
| run_depcheck.py | ||
| 43 | I'd prefer to see the args explicitly listed instead of just passing them through, especially since depcheck.run() wants a list for the rpms arg. I can't think of a situation where we wouldn't be passing a single directory in and would rather not require the extra list in the yaml file | |
| depcheck.yml | ||
|---|---|---|
| 19–21 ↗ | (On Diff #380) | How can this work? We changed the variable format to ${foo} a long time ago. |
| depcheck.yml | ||
|---|---|---|
| 19–21 ↗ | (On Diff #380) | It does not ;) (not tested apart of unittests). There is more work needed in order for depocheck to be able to be run through runtask.py |
Shouldn't this be for filename in rpms:?