NAME
Punk::Command::Sqitch - `punk sqitch ...`, Sqitch against the configured database
SYNOPSIS
punk sqitch deploy
punk sqitch deploy --env production
punk sqitch status --database analytics
punk sqitch add users -n 'users table'
punk sqitch check
punk sqitch help deployDESCRIPTION
Loading this module registers sqitch with Punk::Command's registry - which is what bin/punk does on an unknown command, so punk sqitch works wherever Punk::Sqitch is installed, with no configuration.
Three options belong to punk and come before the verb:
--env ENV-
The environment config/punk.yml is resolved for:
PUNK_ENV, elseproduction. The same resolutionpunk config checkperforms, every$env,$fileand$execreference included. --database NAME-
Which configured database to target; the default one when omitted. A name that is not configured croaks listing the ones that are.
--dir DIR-
Where to start looking for the application (its app.psgi, walking up). The current directory by default.
--project NAME-
Run a target verb over one project only - a plugin's, or the application's own.
--app-only-
The application's own project only, without loading its class to find the plugins' projects - for an application class that will not load, or a deploy that must not touch what the plugins ship.
Projects
A target verb runs over every project: the plugins' (see "FOR PLUGIN AUTHORS" in Punk::Plugin::Sqitch) in dependency order, then the application's own, each announced with a # project NAME line when there is more than one; revert goes the other way, the application first. The plugins' projects are found by loading the application class with the boot check held off. Each plugin project runs from its own directory against the same target, made absolute for SQLite so the registry is the one file beside the database. The first project to fail stops the run. A plan verb works on the application's project alone.
revert asks for confirmation unless given -y, as Sqitch does; from a script, pass it.
Everything after the verb is Sqitch's: its options, its arguments, its help. For a verb that takes a target (deploy, revert, verify, status, log, check, checkout, rebase, upgrade, bundle) punk supplies --target from the configuration unless the arguments carry one, and the password through $SQITCH_PASSWORD, never in the URI. A plan-only verb (add, tag, rework, plan, show, init, ...) needs no database and reads none.
The command runs in-process, with the project's own directory as its working directory: sqitch/ under the application root for the application's project (see "The sqitch directory" in Punk::Sqitch), and its own directory for each plugin's. A relative SQLite path - in punk.yml or in a --target of your own - is resolved against the application root whichever project is running, and deploy creates the directory it names if it is missing. Exit codes: Sqitch's own for its errors (printed as punk sqitch: ...), 2 for a usage error, 1 otherwise.
punk sqitch pending
punk sqitch pending # lists what is pending; exit 1 if anything is
punk sqitch pending --quiet # the exit code alone, for a CI stepThe one verb that is punk's rather than Sqitch's: the plan against the registry ("pending" in Punk::Sqitch), exit 1 when a change is pending or the registry has drifted from the plan, 0 otherwise. Sqitch's status shows the same changes but exits 0; its check detects a deployed script edited since deployment and exits 1 for that. A deploy gate wants both:
punk config check && punk sqitch pending --quiet && punk sqitch checkpunk sqitch init [NAME] [sqitch init options]
Sqitch's init with the blanks the application can fill: the project name from the application class when none is given (MyApp is myapp, My::App is my_app - Sqitch's name grammar, lowercased), and --engine from the configured database's driver unless given. The project is created under sqitch/ in the application root ("The sqitch directory" in Punk::Sqitch). No target is written into sqitch.conf; it comes from punk.yml on every run. An application that already has a plan is refused naming it, because Sqitch's own init is a silent no-op on one and a silent no-op is how a second project name goes unnoticed.
punk sqitch add CHANGE --model NAME [sqitch add options]
Sqitch's add, then the deploy, revert and verify scripts drafted from the Punk::Model named - MyApp::Model::NAME, or +Full::Class - for the project's engine: a CREATE TABLE of the model's fields in order with the primary key as the engine's autoincrement, NOT NULL for required, a DROP TABLE, and a SELECT of every column from no rows. The scripts say where they came from and that they are a starting point: indexes, defaults, foreign keys and the database's real types are yours, and the model is not read again. The model is loaded before the change is added, so a misspelt one costs nothing. Without --model this is Sqitch's add.
punk doctor
A Punk::Sqitch row joins punk doctor's plugin section: App::Sqitch's version and, inside an application, the engine its database implies and whether that engine's client binary - sqlite3 (3.3.9 or later), psql, mysql, or the one sqitch.conf names - is on PATH. The client is the one thing the Perl side cannot supply, and a deployment image that forgot it learns so here rather than from its first deploy.
SEE ALSO
Punk::Sqitch, Punk::Command, sqitch.
AUTHOR
LNATION <email@lnation.org>
LICENSE AND COPYRIGHT
This software is Copyright (c) 2026 by LNATION <email@lnation.org>.
This is free software, licensed under:
The Artistic License 2.0 (GPL Compatible)