test: overhaul lint testing with one yaml per test - #1085
Conversation
This reverts commit 354bc7a.
…, properly handling testing of multiple recipes in one YAML file and simplifying the linting tests setup
|
Do we want each test case to be fully materialized? Personally, I'm not sure about this, as it makes spotting the differences among the boiler plate hard. At least for me, but then I think I'm the one who started the old way. When planning this out, did you consider changes we would/will need if we were to add support for |
|
Hey @epruesse , thanks for having a look. These two points are basically where this pull request comes from. The motivation was a first step towards And the decision to fully materialize each recipe case was that I actually found it hard to always mentally puzzle together each test case by adding and subtracting stuff to a main recipe that I had to refer back to all the time. That might be easier when generating lots of test cases, but is hard when modifying just a single one. |
|
It might be one of those where the grass is always greener on the other side - the angle of view changes. All of the options have their downsides. You've been doing great work, so make it your house. The code was due for an overhaul, and if you feel it'll be better this way, go for it! :-) |
|
Yeah, I'll probably see the downside of this any minute, now... 🙈 |
|
Nah. It'll take longer than that to curse your younger self. It's like writing comments. FWIW - I think you are right to materialize these. Simpler is almost always better even if it doesn't look as elegant when you write it. I know the dude who found a use for meta classes somewhere in this code base... |
|
Feel free to merge, BTW. I don't have the permissions on |
|
Done. Didn't realize you didn't have that power once approval was given. |
This pull request is basically `git cherry-picking` all the previous work in pull request #1073 , as that one's diff has gotten too confusing with a failed `rebase --onto master` attempt (I realized too late, that I am working on a fork, here...). In addition, this pull request is a bit more generic, trying to get a consistent linting and comprehensive linting tests for recipes with multiple outputs in general. The aim is to work towards supporting the new `rattler-build` driven `recipe.yaml` format that has been accepted as Conda Enhancement Proposals (CEPs) 13 and 14, by implementing [the `outputs:` specification](https://conda.org/learn/ceps/cep-0014/#outputs-section) in the linting over here. So, this is a fresh start after the overhaul of the linting test suite setup in #1085 has been merged. And to also link more previous work, this is the follow-up to pull request #1057, which did a first step towards better linting of multiple outputs. Please note, that this will require updating all of the 7 recipes with multiple outputs so that they pass the new lints, also see here: #1057 (comment) The plan is to open a separate pull request for each of them on `bioconda-recipes`. --------- Co-authored-by: Elmar Pruesse <epruesse@users.noreply.github.com>
3 participants
This pull request switches to a linting testsuite with one YAML file per linting test, to have all the info needed to evaluated a single linting test in one place.
This also simplifie the linting tests setup a bit, as some keywords from the testing suite (like
remove:) are not needed any more.Also, this pull requests ensures that in YAML files with multiple recipes, more than just one of them actually gets tested. Previously, only one of them would run, as any subsequent recipes would have an empty list of checks (I guess they were being consumed in some way and not reloaded).