Check your file

Goal

For feature teams. In this task you check a joomiz.yaml file with joomiz validate. The command lists every problem at once, and it changes nothing.

Before you start

• Register your application once. Deploy your first service shows how. validate needs a registered application.
• Sign in, or set a token. Sign in and get access explains both.
• Tell the CLI where the control plane is. The variable JOOMIZ_SERVER_URL holds the address.

Steps

Run the command

Run joomiz validate in the folder of your file. Add -f to name another file.

joomiz validate

You see:

joomiz.yaml is valid (checked by https://joomiz.example.com/validate)
  application:   no problems
  tooling:       no problems
  environments:  no problems in 1 environment (1 target, 1 deployment, 1 managed-resource, 0 consumed-resources)

The command exits with 0. The three lines say that each part of the file passed:

• application is the application block.
• tooling is the tooling list.
• environments counts the entries of your environments.

Read a report with problems

When the file has problems, the command lists all of them and exits with 1. This file has three kinds of problems. Its artifact has a type that the deployment cannot use. A reference names an output that does not exist. A spec has a setting that the type does not know.

error: the control plane found 3 problems in joomiz.yaml (checked by https://joomiz.example.com/validate)
  environments:
    test:
      shop-test-deployment (cloud-foundry-app): shop-jar -> test-foundation
        artifact: 'shop-jar' is of type 'kong-oas', which a deployment of type 'cloud-foundry-app' may not use
        spec: '${{managed-resources.shop-db.outputs.host}}' — 'managed-resources.shop-db.outputs.host' does not name a value; declared here: password
      shop-db (postgres):
        spec: property 'size' is not defined in the schema and the schema does not allow additional properties

Read the report from the top:

• Each problem sits under the environment, and under the entry that has it.
• The line of an entry shows its id, its type, and for a deployment the artifact and the target.
• Each problem line starts with the part of the entry: artifact, target, spec or id.
• The text after it says what is wrong, and often lists what is allowed.

Fix an error explains the messages that people meet most often.

Use the JSON form

Add --json to get the answer of the control plane as JSON. A script can read it. The exit code stays the same.

joomiz validate --json

You see the start of one long line:

{"applicationId":"f86f491d-2073-42d1-8166-17ab5d0eb093","errors":[],"application":{"errors":[],"valid":true},"tooling":{"errors":[],"valid":true},"environments":[{"name":"test","errors":[],"targets":[{"id":"test-foundation","type":"cloud-foundry-space","errors
...

The line ... marks the rest, which this page cuts.

Read the exit code

The CLI reference lists the codes of every command.

Check

Fix the problems and run joomiz validate again. The first line must say that the file is valid, and the exit code must be 0.

What validate does not check

validate is a dry run. It reads your file and the catalog. It does not call a provisioner, and it does not look at what exists. For example, it passes a file that uses a type that no provisioner handles. plan stops such a file. Preview a change explains plan.

Troubleshooting

This is the answer for an application that is not registered:

error: the control plane could not validate joomiz.yaml (HTTP 404)
  Application not found
  application 'f86f491d-2073-42d1-8166-17ab5d0eb093' is not registered; run "joomiz register" first
  hint: joomiz register -f joomiz.yaml

Next

Preview the change that your file would make in Preview a change.