Request for classic confinement: gherkinator

store-requests classic-confinement
1

  • name: gherkinator

  • description: A CLI tool for managing centralized YAML test plans. It validates, transpiles, and serves test plans as Gherkin feature files or Sphinx-powered Markdown documentation.

  • snapcraft: gherkinator snapcraft.yaml

  • upstream: GitHub - canonical/gherkinator: A CLI tool for managing centralised YAML test plans. It validates, transpiles, and serves test plans as Gherkin feature files or Sphinx-powered Markdown documentation. · GitHub

  • upstream-relation: I’m the author

  • supported-category: IDEs, tools for local, non-root user driven configuration of/switching to development workspaces/environments

  • reasoning:

    gherkinator functions like a CLI-based IDE for drafting and editing test plans for artifacts such as charms, and it provides compilation/dev environment management capabilities by transpiling YAML documents into multiple Markdown or Gherkin documents.

    For a demonstration of gherkinator’s IDE-like capabilities, the gherkinator edit … command opens the targeted test plan file using either the users’ default text editor or the current value of the EDITOR environment variable (similar to lxc config edit ...). Once the user closes the editor session they started with gherkinator edit …, gherkinator will validate the users’ test plan against the preconfigured schema to ensure they provided valid test metadata like implementation status or targeted risk level. These test plans are then compiled to Gherkin feature files for use in testing pipelines for various artifacts such as charms, snaps, and rocks.

    However, this feature does not work well in strict confinement since the user’s preferred EDITOR is usually not available in a strictly confined snap’s namespace. I tried strictly confining gherkinator by making nano the only available editor, but this didn’t work because nano could not access information about the current terminal session from inside the snap’s namespace:

    ➜ gherkinator edit plans/lifecycle.yaml

E558: Terminal entry not found in terminfo
'alacritty' not known. Available builtin terminals are:
    builtin_ansi
    builtin_vt320
    builtin_vt52
    builtin_xterm
    builtin_iris-ansi
    builtin_pcansi
    builtin_win32
    builtin_amiga
    builtin_dumb
    builtin_debug
defaulting to 'ansi'

    I could get around this issue with nano by binding the /usr/share/terminfo directory into the gherkinator snap using the system-files interface, but that felt a bit heavy, and this approach still comes with the trade-off that a user still cannot use their preferred EDITOR for editing test plans.

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.

Let me know if you have additional questions about the purpose or expected usages of gherkinator. I created it to help with writing consistent BDD tests for Charmed HPC! I’ve also published several classically confined snaps before for vetting purposes.

2

This request has been added to the queue for review by the @reviewers team.

1 Like
3

hey @nuccitheboss

Please note that classic confinement is a sensitive matter and it is reserved for mature, well-known applications published by mature, well-known entities. As of today, I believe that gherkinator should meet these criteria:

  • There should be a technical reason

  • It must be a mature, well-known application published by a mature, well-known entity.

  • It must fit in the supported categories

The reviewers’ team is still working on more concrete expectations. Considering the above factors, I think (b) does not clearly meet. Thus, I think this snap should not get classic confinement as of now.