sqitch-verify(3pm)

📦
version 1.6.1 · 6 versions
, in ubuntu stonking

sqitch-verify 💖

ok bestie, gather round, because this is sqitch-verify, a page from the sqitch user-contributed Perl docs, and it's literally just here to make sure your database isn't lying to you. 🫶

✨ NAME ✨

sqitch-verify — verify that the changes you deployed to your database are actually, y'know, valid. 💅

🌸 SYNOPSIS 🌸

sqitch verify [options] [<database>]
sqitch verify [options] --from-change <change>
sqitch verify [options] --to-change <change>
sqitch verify [options] --from-change <change> --to-change <change>

🦋 DESCRIPTION 🦋

So the whole vibe of verify is: check that a database is valid relative to the plan and the verification scripts for every change that got deployed. No cap. 🔥

More specifically — and bestie, listen, this is the part that matters — verify iterates over all deployed and planned changes (or just the subset you point at with --from-change and/or --to-change) and checks that each one:

  • Is deployed. ✅
  • Is present in the plan. ✅
  • Was deployed in the proper order. ✅
  • Passes its verify test, if one exists and the change has not been reworked. ✅

The <database> parameter tells it which database to connect to, and you can also hand it over via the --target option instead. It can be a target name, a URI, an engine name, or a plan file path. Like, whatever, it's flexible. 💁‍♀️

Verify tests are scripts that may be associated with each change. Quick facts:

  • If a change has no verify script, it emits a warning — but that is not considered a failure. Chill.
  • If a change has been reworked, only the most recent reworking will have its verify script executed. Periodt.

Also, verify scripts should make no assumptions about the contents of the database, the way unit tests might. That's not their job!! Their job is to make sure the state of a database is correct after a deploy script has completed. They get run through the database engine command-line client, exactly like deploy and revert scripts. And if they fail? They should make the client exit with a non-zero exit code. That's the whole signal. 🚨

👑 OPTIONS 👑

  • -t, --target — The target database to connect to. This can be either a URI or the name of a target in the configuration. 🎯
  • --from-change, --from — Specify the change to start the verification with. Defaults to the earliest deployed change. Wanna know all the cute little ways you can specify changes? See sqitchchanges. 📖
  • --to-change, --to — Specify the change to complete the verification with. Defaults to the last deployed change. Same deal — the various ways to specify changes live in sqitchchanges. 📖
  • -s, --set — Set a variable name and value for the database engine client to use, if it supports variables. The format must be name=value, e.g., --set defuser='Homer Simpson'. This overrides any values loaded from configuration Variables. 💌
  • --registry — The name of the Sqitch registry schema or database where sqitch stores its own data.
sqitch verify --registry registry
  • --db-client, --client — Path to the command-line client for the database engine. Defaults to a client in the current path named appropriately for the database engine.
sqitch verify --client /usr/local/pgsql/bin/psql
  • -d, --db-name — Name of the database. In general, targets and URIs are preferred, but this option can be used to override the database name in a target.
sqitch verify --db-name widgets
sqitch verify -d bricolage
  • -u, --db-user, --db-username — User name to use when connecting to the database. Does not apply to all engines. In general, targets and URIs are preferred, but this option can be used to override the user name in a target.
sqitch verify --db-username root
sqitch verify --db-user postgres
sqitch verify -u Mom
  • -h, --db-host — Host name to use when connecting to the database. Does not apply to all engines. In general, targets and URIs are preferred, but this option can be used to override the host name in a target.
sqitch verify --db-host db.example.com
sqitch verify -h appdb.example.net
  • -p, --db-port — Port number to connect to. Does not apply to all engines. In general, targets and URIs are preferred, but this option can be used to override the port in a target.
sqitch verify --db-port 7654
sqitch verify -p 5431
  • --plan-file, -f — Path to the deployment plan file. Overrides target, engine, and core configuration values. Defaults to $top_dir/sqitch.plan.
sqitch verify --plan-file my.plan

🧚 CONFIGURATION VARIABLES 🧚

🌈 [deploy.variables] and [verify.variables] 🌈

A section defining database client variables. The deploy.variables configuration is read from the deploy command configuration, on the assumption that the values will generally be the same on verify. If they're not, use verify.variables to override deploy.variables. 💖

These variables are useful if your database engine supports variables in scripts, such as:

May be overridden by --set or target and engine configuration. Variables are merged in the following priority order (highest first, bestie, don't get it twisted 👇):

  1. --set
  2. target.$target.variables
  3. engine.$engine.variables
  4. verify.variables
  5. deploy.variables
  6. core.variables

⭐ SQITCH ⭐

Part of the sqitch suite. Obviously. Iconic behavior only. 💅

okay so that's the whole page, no notes. go verify ur stuff bestie, ur database will thank u 🫶✨

Sign-off time, my love: this one comes from perl v5.40.1, dated 2026-07-26, and it's the sqitch-verify(3pm) page. Mwah. 💋🎀🌸

📦 where this page comes from