Open minrk opened 8 years ago
It is a good idea. However you are correct in assuming the linter doesn't use git
at all. So the linter ATM just does conda smithy recipe-lint recipe
or similar.
Where's the CI linter running? The github hooks presumably are sending the relevant refs, so it shouldn't be too complicated.
# git checkout head
new_meta = parse('meta.yaml')
# git checkout target
old_meta = parse('meta.yaml')
if new_meta['package']['version'] != old_meta['package']['version']:
...
It's running on Heroku. Yeah, I'm not saying this is impossible. It is a bit of a change of scope for the linter. It's initial intent was something one could run locally. So maybe these changes live in conda smithy recipe-lint-service recipe
or some other newly envisioned tool that wraps the existing linter.
Yeah, it seems like specifically a feature of the linter service, not necessarily a feature of the linter itself. Although I suppose it's conceivable that it could compare with master even when run locally.
Anyway, I'll call it a low-priority maybe-when-someone-feels-like-a-diversion kind of project.
Although I suppose it's conceivable that it could compare with master even when run locally.
True. Though would add it is particularly targeted at feedstocks and not staged-recipes.
FWIW I do like the idea. Just trying to think of where it lives relative to other things.
Where is the code for the Heroku app?
I ask because it seems logical to me that this check should go there, not in the linter.
That's an option. It all lives here. The linting code itself is mainly contained in conda_forge_webservices/linting.py.
Would it be possible for the linter CI service to perform a check on the build number?
i.e.
I see this as a common first comment on feedstock PRs, which seems like the kind of thing lint-as-ci can help with. But I imagine the linter service doesn't take the diff into account at the moment, so maybe it's not worth the effort to add.