move rpmlint-tests here and add CI?

[aspiers]

I'm new to this rpmlint code, but I'm wondering why the tests are in a separate repo? If they were in this repo, then we could add CI (e.g. via Travis or similar) to ensure that any changes to code have the necessary corresponding changes to the test suite. It would also make it possible to automate local runs of the test suite. Am I missing something? Thanks!

[dirkmueller]

rpmlint-tests predates the times when there was no proper testing upstream. It's​ purpose in my view is mostly obsolete except for integration testing which gives you the reason why it is separate: it is supposed to test the actual effective tool

[aspiers]

Not disagreeing but I don't quite understand this, since AFAICS this repo contains checks which are not upstream. If the checks need to be upstreamed or ditched then we need an issue to track that. Otherwise we need downstream tests for the additional downstream checks, in which case my question still stands. Either way there is still work to be done -> reopening until it's clearer what the way forward is.

[aspiers]

FTR Dirk provided this list of rpmlint bugs which IIUC relates to what he said about the obsolescence issue.

[dirkmueller]

That's what I tried to explain before. The rpmlint-tests are supposed to test the actual effective (e.g. the version that is used during building) tool, so thats why it is separate from this one (which is just containing checks that noone bothered doing properly upstream).

[mgerstner]

I can see the purpose of testing rpmlint-mini, the final integration of all components. But it would also be helpful to get a more direct feedback when performing changes on the tests. Currently the rpmlint-tests in OBS often fail and nobody notices or cares, the original commiters often don't even realize it.

So we could additionally add GitHub CI or something similar that improves on this situation. What do you think @maltek, @jsegitz ?

[lnussel]

OBS can integrate with github pull requests and automatically fork and build the package based on that AFAIK. That might be the easiest way as OBS is the target anyways. May want to talk to Adrian about that.

[jsegitz]

That sounds nice. I added it to our minutes for the next meeting so we can discuss it there