Common BB CLI abstraction (draft proposal)
This draft was presented to the TC at a meeting for inspirational input.
(original text copied from a Google Presentation)
A CLI - command line interface
setup and verification of local environment
building containers
running/deploying container environment
unified parameters for ALL building blocks
unified parameters for ALL implementations a specific building block
A CLI is an API. It’s an abstraction layer and a contract of how to interface with an application layer.
Abstraction layer
Local development vs. deployment
Technological stack (terraform/docker-compose etc)
Packaging
Large-scale test “readiness”
Quicker bootstrapping for everyone
Ability for TAC to standardize when needed
bb-util <bb-dir> <command> <arguments...> [options...]
bb-util <bb-dir> setup
- Sets up local environment, docker containersbb-util <bb-dir> build
- Builds the building blockbb-util <bb-dir> run
- Runs the service locallybb-dir
: Directory containing an implementation readable tobb-util
bb-util is an interface, it is implemented by each building block!
This could be for
Core modules (E.g. Consent BB)
Test setup
Demo setup
# All deployments must supply a ./bb-util script accepting a variation of the
# following parameters. A deployment may add arguments and parameters, but should
# document these. If a BB specifies its own set of parameters and arguments, they
# should be UNIVERSAL to all deployments.
#
# ./bb-util <command> <arguments...> [options...]
Level 1: GovStack Building Block-level specification, an interface that’s universal to all building blocks. Could for instance be about basic commands: setup, build, run, test, version + universal options “--verbose” etc.
Level 2: Building Block specification: All commands, arguments and options specified for all implementations to follow. This could be for instance if Consent BB wishes to have a flag “--allow-superuser-role”
# Currently, the repo structure specifies to have "/examples" as a layout of
# implementations of the BB and its API spec
# We could propose to rename it /deploy or similar
cd ./examples
# We get bb-util from somewhere
package-manage install bb-util
# We use the general Building Block util to launch an implementation that lives
# in /examples/demo-app/
bb-util ./demo-app run
# Our abstract layout in ./examples contains definitions for bb-util to
# understand the set of commands, arguments and options
# Running show-args reads and outputs these definitions.
bb-util . show-args