This code makes it possible to run Depcheck through Taskotron runner.
Details
- Reviewers
kparal tflink - Maniphest Tasks
- T217: Make Depcheck runable in Taskotron
- Commits
- rDEPCKcfbca34a86ec: T187 - Depcheck runs in Taskotron
Unit tests pass, testing runs through runtask.py look ok
Diff Detail
- Repository
- rDEPCK task-depcheck
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Overall, it seems to be working as expected when I run it locally. My concern is that this check is not capable of doing multilib for x86_64 (which is why we added the mash directive instead of just createrepo).
My initial attempt to get multilib working is:
It's ugly and it's hacky but something like that should work for now until we start adding stuff like arm. I'm not sure how to handle the multilib case in a cleaner way but I don't think that delaying depcheck until we get that figured out is a good idea.
@tflink - out of curiosity - if the check requires to be run with both archs on command line, would it not be better (meaning less error-prone) to just pre-fill the arches on all spots in the yml file, and disregard the -a option completely?
The "cleaner" solution might IMHO be not that difficult (if I'm not misunderstanding something):
- add multiple-arch handling ability to yumrepoinfo
- add something like "check-multilib" directive, that would add the other arches properly for now it would just handle x86, but we can then add arm rules easily
- add code to depcheck's run-code that will
- work with multiple arches on input, and run depcheck multiple times if needed
- collect all "squashed" per-update results, and provide a complete list of results in TAP format
What do you think about that? I'm fine with using your patch (ideally with the changes mentiones at the beginning of this comment, if it makes any sense) for now though.
Thinking more about the depcheck.yml you provided - there is one more catch here - the i386 run of depcheck will fail for all x86_64 packages present in the repo
- name: run i386depcheck python: file: run_depcheck.py callable: taskotron_run arch: ['i386'] rpms: ["${workdir}/downloaded_tag/"] repos: - ${i386_yumrepos} - "workdir_repo": "${workdir}/downloaded_tag/" report_format: "rpms" export: i386_depcheck_output
So we should probably then sort the rpms, so x86_64 is not on the depcheck-i386 input. But the more I think about it, the more I see layers of hacks... So maybe we really should just do it the "simple" way - add directive which produces list of arches properly according to multilib and the main arch, make the relevant directives multi-arch aware, and just run depcheck for the main arch.
That means separate runs for i386 and x86_64, but IMHO dodges many hacks and stretches we'd need to do otherwise.
Thoughts?
Also - I'd like to push the current Differential to master, if nobody protests - the current state in master is next-to non-working, and making it multilib-aware will imho take some time (and deserves its own ticket/diff).
out of curiosity - if the check requires to be run with both archs on command line, would it not be better (meaning less error-prone) to just pre-fill the arches on all spots in the yml file, and disregard the -a option completely?
Yeah, we're already hard-coding stuff so I don't see any additional harm in hard-coding the rest
So we should probably then sort the rpms, so x86_64 is not on the depcheck-i386 input. But the more I think about it, the more I see layers of hacks... So maybe we really should just do it the "simple" way - add directive which produces list of arches properly according to multilib and the main arch, make the relevant directives multi-arch aware, and just run depcheck for the main arch.
When I first saw your suggestion, I thought "no, that sounds terrible" but as I read and think more, I'm starting to agree with you. I'd like to not rely on that long term but I don't see a cleaner option for the short term.
That means separate runs for i386 and x86_64, but IMHO dodges many hacks and stretches we'd need to do otherwise.
Yeah, let's keep it as simple as we can for now - depcheck is complicated enough by itself without adding to the complexity. If that means extra downloads and extra runs, so be it. We can make it better and/or more efficient once we're certain that the core depcheck code is working.
Also - I'd like to push the current Differential to master, if nobody protests - the current state in master is next-to non-working, and making it multilib-aware will imho take some time (and deserves its own ticket/diff).
Sounds good to me. Let's deal with multilib in another ticket/review
add code to depcheck's run-code that will
- work with multiple arches on input, and run depcheck multiple times if needed
- collect all "squashed" per-update results, and provide a complete list of results in TAP format
Assuming that you're talking about putting it in the run_depcheck.py, that makes sense to me. It might even help us work around the check-multilib directive since I'm not aware of any other tasks which would require it - we could do some file glob checking before passing the input into actual depcheck.