Thoughts on snapcraft.yaml in project or separate repository?

I wanted to know everyone’s thoughts on having snapcraft.yaml located in the same repository as the project it is for or in a separate repository created just for the snap.

Hugo for example is an example of a project who keeps the snap within its main repo.

Nextcloud however has an entirely separate repository for snapcraft.yaml and everything else it needs.

Pros and cons for each approach? Would it be going too far to say one is the “suggested” approach?

I think it depends on your workflow. My preference would be to have snap/snapcraft.yaml the same repository as the upstream source because you can easily build a snap from the same local copy for development purposes and you can update it to keep up with changes in the build system, even for feature branches. You can do all of that with separate branches, but it’s more maintenance overhead.

I’d say it depends on the project/snap.

Having snapcraft.yaml in the main repo:

  • Advantages:
    • You can trigger builds upon merge, e.g. when you merge to master you can get that new feature in edge immediately
    • Easy to integrate it into CI for testing purposes (e.g. so the snap doesn’t break as you add new features)
  • Disadvantages:
    • If you have a lot of snap-specific features (nextcloud is a great example as its so complex) as well as a lively project maintaining the snap and project in the same tree gets quite busy indeed as it’s essentially two projects in one tree.

Having snapcraft.yaml in a separate project:

  • Advantages:
    • Nice for complicated snaps as it allows you to have collaborators on the snap but not the main project (and vice-versa), and is easier to keep track of development of a single project.
  • Disadvantages:
    • A looser coupling with the upstream code makes tying into CI harder. For example, the best the Nextcloud snap can do is build daily, and that’s just because Nextcloud publishes daily tarballs. It can only catch errors after they happen.
2 Likes