At the moment the only way to know if your yaml is valid is to run snapcraft or snapcraft cleanbuild. If the yaml isn’t valid, then snapcraft barfs with an error, as expected. If it is valid, then it proceeds to start the build (creating directories), or spinning up a lxd container and compressing the files for transport into that container.
Sometimes I just want to check the yaml, but don’t actually want to start a build at all, just make sure my yaml is valid. At the moment that means running snapcraft or snapcraft cleanbuild and then pressing CTRL+C to abort it, and then snapcraft clean or rm *.bz2 to clean up after the aborted build.
Can we please have a snapcraft check or snapcraft lint or similar which checks the validity of the yaml, without actually building the snap?
In addition, it might also be nice to offer suggestions to improve it if contains common mistakes, like leaving the boilerplate metadata, or a warning if there’s a missing apps section?
Are you currently checking for unique plug and slot names inside a snap? We recently ran into some issues and it would be nice if we did that, and in addition, in the case snapcraft is invoked on the core snap itself, also add the implicit slots (which is double plus hard as those depend on classic or core distribution). I think for safety we could just add them all and ensure the resulting yaml is still valid.
We don’t do semantic parsing currently, only syntax with jsonschema. Not sure if we can leverage jsonschema to do this. That said, it might be better as a review-tools thing.
I might also thing that this might also be better presented as
snapcraft --dry-run
Two reasons:
our cli is currently huge with top level commands.
You might also want to see what it will do with your current `snapcraft.yaml.
Something worth considering that was mentioned on Rocket:
This has checks for (unwanted) includes libraries and copyright files. It may not necessarily the same as what’s being proposed here, but I feel those could also be nice to do automatically.
snaplint could easily be extended to do this kind of check, but it’s really meant to be used on a working snap, which by definition would have a valid snapcraft.yaml
I do like the idea of checking for template content though, so I’ll add a task to do that.
One of the difficulties I’ve seen raised (and hit) is that nothing validates plug/slot syntax until one is installing the snap. It’d be great if snapcraft could validate those, I’m just not sure how. Perhaps the best way is for snapd to have that functionality (since it’s where interfaces live) and have snapcraft utilize it.
Although now that I’m thinking about it, I suppose the review tools do this. Perhaps we just need to make it a more exposed member of the development workflow.
@sergiusens This doesn’t look like a task to be handled by a schema language. The sorts of checks that snapcraft can perform are semantic, and much more easily coded in Python itself in a procedural way.
I’d prefer the snapcraft lint suggestion than --dry-run. This is effectively a different mode of operation, so suitable for a different command. Too many commands is only an issue if we’re not presenting a good organization that allows people to find what they care.
That reminds me that –help needs some love. Who should we send the birthday cake to next month?
This has always been the goal but it gets pushed behind other more pressing items. There is actually a snap in the edge channel (‘review-tools’) with an autoalias (‘snap-review’) that mostly worked using the preload part, but a recent change to that part makes python occasionally segfault (there is a race somewhere).
The plan is once the packaging is solid, we can push to ‘stable’, then the store prod can pull from stable (and maybe staging from beta) and developers can use it. In this manner, people get the same review and don’t have to worry about store vs deb vs git checkout, etc. Perhaps after that, snapcraft itself could use it (though work to be done with snapcraft as a snap calling snap-review).
Note, I’m not saying this should replace a snapcraft internal linter necessarily (the review tools look at other things outside of the snap.yaml), just saying what the plan has been.
Point taken. About snapcraft --help I do have a half branch somewhere. Now that I have snapcraft as a snap I might work on it during my next long flight to the next sprint
@sergiusens I’d put that bug ahead of pretty much anything else. If people can’t tell how to use the tool at a basic level, every other feature becomes less important because they’ll have a hard time even getting there.
It really was my intention until classic confinement peeked in and became a time sink. That said, I intend to pick it up so it makes it into the next snapcraft release.
