Classic confinement for `goss`

[sed-i]

• name: goss-org
• description: Quick and Easy server testing/validation
• snapcraft: goss-org-snap/snap/snapcraft.yaml at main · sed-i/goss-org-snap · GitHub
• upstream: GitHub - goss-org/goss: Quick and Easy server testing/validation
• upstream-relation: no relation; just an enthusiastic user we use goss in our CI
• supported-category: debug tool.
• reasoning: goss is a server validation tool with various “resource types”, such as package, port, dns, mount, process, … as well as support for arbitrary commands. In addition, together with goss, the snap contains goss “extras” - dcgoss, dgoss, kgoss - which interact directly with docker and kubernetes.

I understand that strict confinement is generally preferred over classic.

I’ve tried the existing interfaces to make the snap to work under strict confinement.

Note that snappy-debug can be used to identify possible required interfaces. See https://snapcraft.io/docs/debug-snaps for more information.

[sed-i]

May I also have automatic aliases assigned to:

• goss-org.goss → goss
• goss-org.dcgoss → dcgoss
• goss-org.dgoss → dgoss
• goss-org.kgoss → kgoss

[yomonokio]

Hello @sed-i, and Happy New Year!

A key step in the classic granting process is Publisher Vetting. To successfully vet a publisher, we need to verify their connection to the upstream. Since you’re not currently part of the upstream, could you clarify whether the upstream is willing to adopt the snap, or if they are open to having you, as the snap publisher, join the upstream (if you’re willing to do so)?