Veritone Developer CLI
⚠️ WARNING: This is under active development and not yet considered stable for production use!
veritone-developer-cli is a command line interface (CLI) for deploying aiWARE applications to an aiWARE instance directly from their source code.
The tool analyzes a specially-formatted
manifest.yaml file in the base of a project directory,
looks at the difference between the configuration specified there and the live deployment of the application in aiWARE,
and calls the aiWARE API to make changes to bring the deployed version of the application inline with the manifest file.
⚠️ WARNING: This means it will CHANGE THINGS IN YOUR ACCOUNT! USE WITH CAUTION!
In the root directory for your application, create a
manifest.yamlthat looks like
Retrieve an aiWARE token somehow (probably by logging in and pulling it out of your cookies)
Run this to create your application in the production environment:veritone-developer-cli deploy
Or for deploying to another environment, you can override the API URL with
-u.veritone-developer-cli deploy -e "<the URL for your environment (e.g. uk.veritone.com)>"
For full usage information, run
The Manifest File
The script works against a manifest file, which can be written in either
You optionally specify the path to the manifest file as the argument to the
veritone-developer-cli deploy my-manifest.yaml
If you don't specify, the script will look in the current directory for
manifest.json (prefers yaml).
TODO: Need to document the format of the actual contents. For now, just look at
test/manifest.yamland copy it.
For now, there's just one command:
npx veritone-developer-cli or
../bin/veritone-developer deploy all do the same thing for the moment.
To help protect secrets and ease integration into build systems, some command line arguments can also be provided via environment variables. The command line arguments take precedence over environment variables if both are present.
yarnyarn link # to mimic a global install so you can use it easily on the command line in other projects
See the src directory.
See the test directory.
Publishing New Versions
- Follow semver.
- You'll need to be on the veritone npm team.
- Always publish from master and always commit and tag immediately after publishing.
git checkout mastergit pullyarn publish # and answer prompts. This will add a commit and tag to your branch.git push
Feel as magical as now.
Allow developers to do everything Veritone Developer provides without ever having to touch the UI.
Our sketches for the manifest can be seen in our CodeSandbox. See @SteveShaffer for access if you don't have it.
Following Twilio's guide on how to build a node CLI.
yargs instead of
Known Assumptions and Limitations
- Does NOT present a plan or ask for consent before making API calls.
- Redeploys all engine metadata and publishes a new build every time the deploy script is run.
- Does NOT handle by-reference engines. Assumes the engine is "owned" by the application and defined completely inline.
- Does NOT handle by-reference schemas. Assumes the schema is "owned" by the application and defined completely inline.
- Does NOT de-link schemas if a schema is already linked to the application but it's not in the manifest or was removed from the manifest.
- Does NOT handle auto-generation of IDs for schemas. Schemas are required to have a GUID created by the author.
- Does NOT support breaking changes to schemas.
If you manually publish a new breaking version through Developer App and then update the
majorVersionnumber in the manifest, it should be able to push updates to the new major version though.
- Actually write tests in buildPlan.test-TODO.js
- Move the "Developing Locally" section into a CONTRIBUTING guide and the "Roadmap" section into a ROADMAP document so the main README is more geared toward the public API and npm-friendly.
- Figure out proper name (veritone-developer vs. veri vs. aiware vs. aiware-developer-cli or something like that)
- See TODOs inline in source code
- Get more formal automated tests in place
- Find a better default name of the manifest like
- Have a mode where, instead of interactively calling the API, bundles up an immutable install "package" that can then be uploaded to any environment.
- Reorganize scripts folder to move all deploy scripts to
- Provide a way to "diff" engine build contents to determine if a new build should be pushed. This would probably leverage some sort of checking of hashes or docker image layers or something.
We'd like to be intentional about the dependencies we bring in. There's always lots of technologies to pick from on these projects.
Here's what we'd like to explore using for various things. If there's a better alternative, we might change our minds, but here's where our minds are at right now.
yargsfor parsing CLI args
pkgfor bundling a binary
listrfor progress meters
chalkfor colored STDOUT
inquirerfor interactive inputs
- Integrate into GitHub Actions for CI/CD and publishing to npm
Planned Deploy Targets
Should have a command line synonym shorter than
Should be able to run via
npxnpx veritone-developer-cli deploy
Should be able to run as a standalone binary (not exact URL)curl https://scripts.veritone.com/veritone-developer | bash