T217 - Depcheck runs in Taskotron
ClosedPublic

Authored by jskladan on Jun 12 2014, 2:55 PM.

Details

Summary

This code makes it possible to run Depcheck through Taskotron runner.

Test Plan

Unit tests pass, testing runs through runtask.py look ok

Diff Detail

Repository
rDEPCK task-depcheck
Lint
Lint Skipped
Unit
Unit Tests Skipped
jskladan retitled this revision from to T187 - Depcheck runs in Taskotron.Jun 12 2014, 2:55 PM
jskladan updated this object.
jskladan edited the test plan for this revision. (Show Details)
jskladan added reviewers: kparal, tflink.
jskladan added a subscriber: jdulaney.
jskladan retitled this revision from T187 - Depcheck runs in Taskotron to T217 - Depcheck runs in Taskotron.Jun 12 2014, 2:57 PM

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

  1. add multiple-arch handling ability to yumrepoinfo
  2. 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
  3. add code to depcheck's run-code that will
    1. work with multiple arches on input, and run depcheck multiple times if needed
    2. 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).

shisatum updated this object.Jun 16 2014, 3:54 PM

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

  1. work with multiple arches on input, and run depcheck multiple times if needed
  2. 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.

pushed to master, I guess this will autoclose soon :)

jskladan closed this revision.Jun 17 2014, 11:40 AM
jskladan updated this revision to Diff 418.

Closed by commit rDEPCKcfbca34a86ec (authored by @jskladan).