Folders and files
| Name | Name | Last commit date | ||
|---|---|---|---|---|
Repository files navigation
ifacetool provides tooling to work with snap interfaces, in particular their policies as realized via snap-declarations. One central feature of ifacetool is simulating what snapd will do in terms of auto-connections for a group of snaps given snap metadata and snap-declaration content. Installation ============= snap install --beta ifacetool To operate ifacetool needs to retrieve information from the store, it can do so using `snapcraft login` credentials. These can be made available by: * snap connect ifacetool:password-manager-service OR * setting SNAPCRAFT_STORE_CREDENTIALS as per https://forum.snapcraft.io/t/snapcraft-authentication-options Snapd candidate updates ======================= The Update snapd candidate GitHub Actions workflow checks the snapd candidate channel every Monday and Thursday and can also be run manually. When the candidate differs from SNAPD_VERSION, it updates the Go dependencies, builds and installs the snap, and compares the output of minimal-test with testdata/minimal-test.expected before opening a pull request. After that pull request is reviewed and merged, the workflow tags the merged commit and dispatches the Build and Publish ifacetool workflow for the tag. That run pauses for a deployment approval before it uploads to the store. The setup this expects: * GitHub Actions is allowed to create pull requests * SNAPCRAFT_RO_STORE_CREDENTIALS is set as a repository secret, exported with --acls package_access, and is used by the smoke test to run minimal-test * a "publish" environment exists with required reviewers, is limited to tags matching [0-9]*.[0-9]*.[0-9]*-snapd*, and holds SNAPCRAFT_STORE_CREDENTIALS as an environment secret, exported with --acls package_access,package_push,package_release and --channels edge SNAPCRAFT_STORE_CREDENTIALS must not also exist as a repository secret, otherwise every job can read it and the environment gates nothing. Commands ========= fetch ------ ifacetool fetch [--no-decls] [--no-meta] <snap-name>[@rev]... fetch fetches snap metadata (at the given optional revisions) and snap declaration content for a set of snaps. For each snap it creates directories in the current working dir that look like this: <snap-name>/ .snap.json revision snap.yaml plugs.json slots.json snap.yaml is the snap metadata, while plugs/slots.json are the content of the snap declaration interface rule stanzas. These directories named after the snaps are the input for all other commands, they also allow to apply tentative modifications to the metadata or the snap-declaration rules to test. For convenience <snap-name> can also be a path pointing to a .snap file or directly to a local snap.yaml file. The file extension is used to detect this usage. Snap metadata will then come from those local sources. The snap overall still needs to exist in the store for its snap-id etc. auto-connections ----------------- ifacetool auto-connections [--classic] [--store <store-id>] [--model <brand>/<model>] [-i|--interface <interface>] [--candidates] <target-snap> [<context snap>...] auto-connections using the input from the corresponding snap directories (see fetch) does two things: * checks whether all snaps mentioned on the command line can be installed according to the rules * simulates which auto-connections would be established when installing target-snap, assuming the presence of the listed context snaps, and prints the auto-connecting slot/plug pairs The output report has two corresponding parts: * installation report * auto-connections reported with lines of the form: other-snap:plug < target-snap-slot other-snap:slot > target-snap-plug : target-snap-plug for any plug that is still left unconnected this part can be filtered to only show connections and plugs for a given interface using -i|--interface <interface> --candidates enables listing of candidates that were considered in the case were there was auto-connections but multiple candidates were in play or in the case that no auto-connection was established. For each candidate the result of checking whether it is allowed is displayed: * `=> ok` allowed * `=> ok slots-per-plug:*` allowed with `slots-per-plug: *` * `=> <error>` not allowed with error * `=> //` same error as the previous candidate The notation `{<label>: <value>}` displays the label attribute usually considered to allow auto-connection of interfaces like content, etc... --store and --model values are used when processing on-store/on-model/on-brand constraints in the rules. --classic requests to simulate the behavior as on a classic system, the default is an Ubuntu Core system. Changelog ========== 0.6.7 ------ * use snapd 2.77.1 and fixes for it 0.6.6 ------ * fixes for snapd 2.76+ 0.6.5 ------ * check snap name * switch to core22 as base * some other modernizing for development 0.6 --- * support --candidates for further debugging * based/for snapd 2.57.5+ 0.5.1 ------ * switch to craft-store 2.3.0 to enable final snapcraft v7 exported auth 0.5 ---- * support filtering by interface with -i|--interface * support --classic 0.4 ---- * refined auto-connections output * fetch now supports taking metadata from local .snap/.yaml files * clarify license Ideas ====== review-tools at tag for snap.yaml can-install snap can-connect snap-plug snap-slot allow-installation slot-or-plug allow-auto-connection plugs and/or slot allow-connection plug and/or slot explain snap-name explain/lint snap-name [attr matching code]