General notes on things to do and how things work.
Features:
- Users, who are able to login, edit their own profiles, and view the status of Lanes
- Harbormasters, who can create Users, Ship to all Lanes, and promote Users to Captains or Harbormasters
- Captains, who can sent Shipments to Lanes they Ply
- Lanes, which represent deployment paths, comprised of Harbors
- Shipments, which represent discrete actions at a specific Harbor
- Harbors, which represent a specific custom task
- Logs, which are the output of Shipments
- Manifests, which are passed from lane to lane
- Salvage Plans, which are Lanes to be executed when a Shipment fails
- Shipping, the act of initiating discreet Shipments to a Lane
- Plying, the responsibility of Shipping to a Lane
- Defining a Lane, which allows input of individual commands as Harbors
- Promoting & Demoting Users, allowing Harbormasters to change roles
- Hooks, allowing remote calls to trigger shipments
- Abort shipment, canceling a shipment in the middle of it, optionally triggering a Salvage Plan
- Plugins, for modular capabilities
TODO:
- Blur bug on form input in harbor
- Convenience methods?
- Charters?
Environment variables you'll want if you run this docker container:
MAIL_URL=[username]:[password]@[smtp.someserver.com]:[port]
MONGO_URL=mongodb://[user]:[password]@[mongodb url]:[mongodb port]/[db name, usually "harbormaster"]
ROOT_URL=http[s]://[wherever the app is running][:port]
PORT=[usually 80]
Calling webhooks can be done like so:
# Can be triggered via RPC, e.g.:
curl \
-f \
-H "token: [the token for this user with this lane]" \
-H "user_id: [the user id]" \
-X POST [url]/lanes/[lane name]/ship[?key=value]
# Any query passed will be assigned as a prior_manifest on the manifest for the lane