2.0.0

v2.0.0 — Massdriver v2 API

This release rebuilds the CLI on top of the new Massdriver v2 API. The command surface has changed slightly. The summary below highlights every top-level command that was added, removed, or renamed so you can update your scripts and CI pipelines.

Top-level command changes at a glance

v1 command	v2 equivalent	Notes
mass application ...	mass instance ...	The application alias is gone; everything deploys via instance.
mass infrastructure ...	mass instance ...	The infrastructure alias is gone; everything deploys via instance.
mass package ...	mass instance ...	Renamed. See subcommand changes below.
mass artifact ...	mass resource ...	Renamed to match v2 terminology.
mass definition ...	mass resource-type ...	Renamed to match v2 terminology.
mass logs <deployment-id>	mass deployment logs <deployment-id>	Moved under the new deployment command.
mass credential list	—	Removed.
mass image push ...	—	Removed.
mass preview ...	—	Removed. Use the new component/instance workflow.
mass server	—	Bundle dev server removed.

New commands

• mass whoami — Show the currently authenticated user or service account.
• mass component — Manage components in a project's blueprint.
  • component add <project-id> <bundle-oci-repo-name>
  • component update <component-id>
  • component remove <component-id>
  • component link <from-component>.<from-field> <to-component>.<to-field>
  • component unlink <from-component>.<from-field> <to-component>.<to-field>
• mass deployment — Inspect deployments directly.
  • deployment get <deployment-id>
  • deployment list <instance-id>
  • deployment logs <deployment-id> (replaces mass logs)
• mass repository — Manage OCI repositories for bundles (and, in future, resource types and provisioners).
  • repository list
  • repository get <name>
  • repository create <name>
  • repository update <name>
  • repository delete <name>

Renamed commands

package → instance

instance replaces package (and the application/infrastructure aliases) for managing IaC deployed into environments.

v1	v2
mass package deploy <project>-<env>-<manifest>	mass instance deploy <project>-<env>-<manifest>
mass package get <project>-<env>-<manifest>	mass instance get <project>-<env>-<manifest>
mass package export <project>-<env>-<manifest>	mass instance export <project>-<env>-<manifest>
mass package version <package-id>@<version>	mass instance version <instance-id>@<version>
mass package destroy <project>-<env>-<manifest>	mass instance destroy <project>-<env>-<manifest>
mass package list <project>-<env>	mass instance list <project>-<env>

The following package subcommands are no longer available: configure, patch, create, and reset. Adding a bundle to a project is now done via mass component add against the project blueprint. See the deployment model section below for what replaces configure and patch.

artifact → resource

v1	v2
mass artifact import	mass resource create
mass artifact get [artifact-id]	mass resource get [resource-id]
mass artifact download [artifact-id]	mass resource download [resource-id]
mass artifact update [artifact-id]	mass resource update [resource-id]

definition → resource-type

v1	v2
mass definition get [definition]	mass resource-type get [resource-type]
mass definition list	mass resource-type list
mass definition publish [file]	mass resource-type publish [file]
mass definition delete [definition]	mass resource-type delete [resource-type]

Changes to existing commands

• mass project — Added mass project update [project] for updating a project's name, description, or attributes.
• mass environment — Added mass environment update [environment]. The create positional argument is now [ID] (was [slug]), and the second arg to environment default is now
  [resource-id] (was [artifact-id]).
• mass bundle — build, import, lint, and publish now accept an optional [path] argument so you can run them against a bundle directory other than the current working directory.

Removed commands

• mass application / mass app (use mass instance)
• mass infrastructure (use mass instance)
• mass credential list
• mass image push
• mass logs (use mass deployment logs)
• mass preview (init, deploy, decommission)
• mass server

Deployment model changes

The way configuration changes flow into a deployment has changed in v2:

• v1 workflow: mass package configure or mass package patch updated the package's saved configuration as a separate step, and then mass package deploy triggered a deployment using whatever was currently saved.
• v2 workflow: Configuration changes are applied at deploy time. mass instance deploy now accepts the configuration/patch inputs directly, so updating params and creating a deployment happen in a single command — there is no separate "configure" or "patch" step to keep in sync with the deploy.

We've also replaced the v1 idea of a single "saved" configuration on a package with a proposed → approved/rejected model: changes to an instance's configuration land as proposed changes that must be explicitly approved (or rejected) before they take effect. Today this approval workflow is available in the web UI; CLI support for proposing, approving, and rejecting changes is coming soon.

Migration tips

• Replace any mass application …, mass infrastructure …, or mass package … invocations with mass instance ….
• Replace mass logs <id> with mass deployment logs <id>.
• Replace mass artifact … with mass resource … and mass definition … with mass resource-type ….
• If you relied on mass package create, switch to mass component add to attach a bundle to a project's blueprint.
• If you previously ran mass package configure or mass package patch before mass package deploy, fold those inputs into a single mass instance deploy call. The standalone configure /
  patch / reset subcommands are gone.
• For workflows that depended on the approve/reject step (currently UI-only), keep an eye on upcoming CLI releases.

Changelog

• 2520e06 Swap to the v2 API (#225)