Exploration: how to write and test snaps?

[DnPlas]

Why it needs to get done

We need to explore how snaps are written and tested before we can start creating one on our own. We need to gather enough information to start writing a snap for DSS.

Estimate 1D

What needs to get done

Explore the following:

• How is a snapcraft.yaml constructed?
• How is a fully built snap tested?
• What tools can be leveraged. For instance https://snapcraft.io/build.
• What is the repository structure of a snap?

When is the task considered done

When we have enough information to answer the questions presented above to get started with writing our first snap.

[syncronize-issues-to-jira[bot]]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-5331.

This message was autogenerated

[DnPlas]

From the Snapcraft overview guide, here are my findings:

1. snapcraft (similar to rockcraft and charmcraft) allows you to build, publish, debug, test and version control snaps
2. According to the snapcraft quickstart tour, a snap is a bundle of one or more applications that works without dependencies or modification across many Linux distributions; a containerised application if you will. [1]
3. Snaps are built in three steps: (1) Identify all sw modules, libraries and packages that make up an application. This is written down in a yaml file. (2) Build the application using snapcraft. (3) Publish the application to the Snap Store (public).

For more details on how to actually write a snap, we can follow this guide.

4. Snaps are built using plugins, parts, and interfaces that are defined in a snapcraft.yaml file. The snapcraft.yaml schema can be found here.

5. Building a snap (the project) requires us to define top-level metadata with things like the base os, supported architechtures, etc; then a parts metadata where the application is built and its dependencies imported or added; and finally we can define interface metadata to connect external system resources to the application.

6. Building the actual application is as easy as running snapcraft --debug in the same dir where the snap was initialised.

7. For local testing, the snap install <snap file> can be used

8. This guide provides better information about creating a snap step by step.

9. There are confinement levels for snaps: a strict snap is a snap that runs in complete isolation with a minimum access level that can be considered safe; on the other hand classic snaps allow access to the system’s resources in much the same way traditional packages do. For the latter, manual reviews are needed.

10. juju-wait is a familiar example.

References: [1] snaps intro [2] snapcraft overview [3] quickstart tour [4] creating a snap

[DnPlas]

More information:

• Github actions we can leverage:
  • https://github.com/snapcore/action-publish
  • https://github.com/snapcore/action-build
• For writing snaps, we have some environment-variables that could be useful, for instance, to access directories in the host system
• The build automated tool is something we can leverage for the continuous delivery of the snap. The way we can leverage this is by using it after merging changes in the dss repository.
• Automated testing can be divided in two: testing the python code and testing the snap, which is done by building, installing, and ensuring the CLI works as expected w/o actually having to run workloads.
• Another snap example

From here I think we have enough information to start moving on with the first draft of the dss snap.

[DnPlas]

Closing this issue as we have captured all necessary information and we have a path to get us started.