50c8cee541
- runAppBinary registers SIGINT and SIGTERM after its build and recursion checks and runChild forwards each signal to the app binary, then waits for it to exit, so stopping summer serve frees the port (WR-08) - newAppCmd keeps the inherited stdin, env and output, and a context cancel sends SIGTERM with a 15-second appShutdownGrace before SIGKILL - the child stays in summer's process group so the admin password prompts can read the terminal - helper-process tests cover SIGINT, SIGTERM and context cancel - console introduction notes the signal forwarding
70 lines
4.0 KiB
Markdown
70 lines
4.0 KiB
Markdown
---
|
|
title: Console introduction
|
|
description: The two command-line programs of SummerCMS, the summer developer tool and the application binary, and how summer delegates runtime commands.
|
|
section: console
|
|
order: 10
|
|
---
|
|
# Console introduction
|
|
|
|
WinterCMS has one console entry point, `php artisan`. SummerCMS has two programs, because the developer tooling and the running application are separate binaries:
|
|
|
|
| Program | Where it comes from | What it does |
|
|
|---------|---------------------|--------------|
|
|
| `summer` | Installed once, by the `curl -fsSL https://summercms.io/new \| bash -s -- <name>` one-liner or from a framework checkout with `go install ./cmd/summer`. | Creates, builds and watches applications, scaffolds plugins and their parts, records API parity fixtures and builds these docs. |
|
|
| The application binary, for example `./bin/acme` | Written by `summer build` into the application's `bin/` directory. | Runs the application: the HTTP server, migrations, workers, the scheduler, admin accounts and every command its plugins add. |
|
|
|
|
The application binary is what you deploy, so everything that must run in production, such as migrations and workers, is a command of the binary rather than of `summer`.
|
|
|
|
## Getting help
|
|
|
|
Both programs list their commands with `--help`, and every command accepts `--help` for its arguments and flags:
|
|
|
|
```sh
|
|
summer --help
|
|
summer make:model --help
|
|
./bin/acme --help
|
|
./bin/acme migrate:rollback --help
|
|
```
|
|
|
|
A command that `summer` delegates to the application binary, such as `summer serve`, answers `--help` with the binary's own help, so run it inside an application directory. Asking the help command of `summer` about a delegated command instead prints a short description and its common flags without running the binary.
|
|
|
|
## Commands that summer delegates
|
|
|
|
During development you often work from the application directory with `summer` alone. These `summer` commands find the application's `summer.yaml`, build `bin/<binary>` when it does not exist yet, and run the same command of the binary with the same arguments:
|
|
|
|
| summer command | Runs |
|
|
|----------------|------|
|
|
| `summer migrate` | `./bin/acme migrate` |
|
|
| `summer migrate:rollback` | `./bin/acme migrate:rollback` |
|
|
| `summer migrate:status` | `./bin/acme migrate:status` |
|
|
| `summer serve` | `./bin/acme serve` |
|
|
| `summer queue:work` | `./bin/acme queue:work` |
|
|
| `summer queue:clear` | `./bin/acme queue:clear` |
|
|
| `summer schedule:run` | `./bin/acme schedule:run` |
|
|
| `summer route:list` | `./bin/acme route:list` |
|
|
| `summer key:generate` | `./bin/acme key:generate` |
|
|
| `summer admin:create` | `./bin/acme admin:create` |
|
|
| `summer admin:reset-password` | `./bin/acme admin:reset-password` |
|
|
|
|
`summer` parses no flags of these commands: every flag and argument, including `--help`, goes to the binary unchanged, and the binary's input is your terminal, so the password prompts of `admin:create` and `admin:reset-password` work as usual:
|
|
|
|
```sh
|
|
summer serve --addr 127.0.0.1:8123
|
|
summer serve --help
|
|
summer migrate:rollback --plugin acme.blog
|
|
summer admin:create --email admin@example.com --superuser
|
|
```
|
|
|
|
One leading `--` is ignored, so `summer serve -- --addr 127.0.0.1:8123` behaves the same as `summer serve --addr 127.0.0.1:8123`.
|
|
|
|
When `summer` receives SIGINT or SIGTERM while the binary runs, it passes the signal on and waits for the binary to shut down, so stopping `summer serve` with Ctrl+C or `kill` frees its port.
|
|
|
|
`summer` does not rebuild an existing binary before it delegates. Run `summer build` after you change code, or keep `summer dev` running. Every other runtime command, such as `deferred:purge` or the commands your plugins add, is run on the binary directly.
|
|
|
|
## The sections of this chapter
|
|
|
|
- [Setup and maintenance](setup-and-maintenance.md) lists every command of the application binary.
|
|
- [Scaffolding](scaffolding.md) covers `summer new`, `summer build`, `summer dev` and the `make:` commands.
|
|
- [Writing commands](writing-commands.md) shows how a plugin adds its own commands.
|
|
- [Utilities](utilities.md) covers the parity and documentation commands of `summer`.
|