sandbox: cli project #1001

Add a new command to the CLI: openfn project

• List the currently checked out project
• Say whether there's a diff from the yaml file
• maybe List the workflows by name
• Maybe if --verbose is passed, show the version hash of each workflow
• List all the domains associated with the project
• For each domain, list the project and its sandboxes by name
• List all the project files, by name and domain, that are available
• Maybe show the last sync date

Some of these bits can be added later - for now we just need the basic project command wired up.

The project logic is closely coupled to the .openfn file, which says "this folder is an openfn Workspace". The .openfn file won't contain much yet, but will come to include:

• options for the repo, like where workflows should live, or the path to the project files
• the name of the original project in Lightning - the basic name for the project
• the name of the currently checked out project (ie, sandbox)
• Any metadata that a) is needed in the CLI, b) isn't contained in the workflow files themselves, and c) is held in the project files

Implementation notes

project

We need to add to the project subpackage a new Workspace class.

With the constructor new Workspace('path/to/some/folder'), a Workspace needs to:

• Look for a .openfn file in the root of the folder, or else error
• Set paths for where workflows live and where project files live
• Load other options from the .openfn file
• For each project file found in the directory substructure, create a new Project instance

A Workspace will have a bunch of utility functions, to be developed as we go. For example to get the list of known projects. The workspace does't do very much, it's just a central lookup for information

There should be a static init function which creates a new .openfn file with some defaults

cli

Once the project stuff is working, we can link the CLI to it

The CLI will need a bunch of subcommands: project init, project merge, project deploy, project pull etc. Some of these will eb shorthanded (ie, openfn merge) and some are already implemented ie, openfn deploy)

But the basic command should describe the Workspace, by listing all the known projects and sandboxes.

We can extend the project command later so right now, it really just needs to display a minimal set of information. Just enough to validate that the Workspace class is working.

The Workspace class does all the heavy lifting here.

What is a project file?

Today, if you run openfn pull on a project, it'll download three artefacts:

• a config.json file, which I think has metadata about the url of the app and stuff
• A project.yaml file, which is an abstract definition of the project and its workflows. Like you get from the workflow source in the app. This is human readable.
• A state.json file, which is all the project data plus app metadata - basically UUIDs. It's not really meant to be human readble and is strutured a bit differently to the project.yaml. This is returned by the provisioner API.

The project file is basically the state file, but it also includes information about the owning app - like the url of the app that the project came from. A project file can be json or yaml. In CLI deploy v2, there is no config file or project.yaml - just the project/state file

Every time you run cli pull in v2, the CLI wll download the state from the provisioner, convert it into a project file, and write it to a folder (probably /projects) in the style name@domain.{yaml|json}. The name of the project is either the sandbox name (if there's a parent id) or something like main if its the primary project.

To know the connected apps for a given repo/folder/workspace, you need to lookup where the project files are stored in .openfn, and read the compatible files in that directory.