Script editor useful for actions, tasks, etc.

• [X] Syntax highlighting, other standard editor features
• [X] Autovalidate actions/inputs/payload/schemas where applicable
• [ ] Simulate scripts client-side

In the experimentation phase of the project I forewent writing extensive tests. Now that the core design has crystalized, it's time to fix that.

• [X] Write test stubs
• [X] Tests can create and populate a new PostgreSQL database for each test
• [X] Tests can create Redis queues with custom (random-ish) names
• [X] Tests can run their own instances of the server
• [X] Write the tests!

Currently task triggers go into a queue. For POST endpoint-triggered inputs, we should be able to run the trigger server in a mode where it bypasses the queue and executes it immediately. This allows the task to generate a payload that can be sent directly in the HTTP response, which may be useful for things like Slack/Discord outgoing webhook implementations, among others.

Right now you have to do &mut state.pg.acquire().await.unwrap().conn. By implementing the Executor trait from sqlx this can just be &state.pg.

Currently using a fork to resolve conflicting indexmap version requirements. We can move back to the mainline once https://github.com/denoland/deno/blob/004d07dccd69c9fae8370665632d90401f770938/core/Cargo.toml#L18 is changed.

• [X] Add information about pending scheduled tasks to the input logs
• [X] Cron format
• [X] API support for adding/updating periodic task triggers
• [X] Enqueue periodic triggers when they are added or updated.
• [X] Reschedule a periodic trigger when it is edited.
• [X] Re-enqueue periodic triggers after processing one.
• [X] Make sure periodic triggers get rescheduled when errors occur and the maximum number of retries is hit.
• [X] UI support for adding schedules to triggers

First version won't have a UI but will work for basic authentication.

• User table
• Roles and organizations tables, for good measure. These won't do much yet.
• Data structure made with OAuth in mind
• Users can have API keys
• Event trigger endpoint checks API key

Currently the long-running tasks for renewing Vault auth use their own sigint listeners which are only active during the wait. Instead, there should be a single SIGINT listener that closes a broadcast channel, and all other things currently using sigint listeners should listen to that instead.

Feature Ideas

• Show all the machines in a grid with some visualization
• State machines can be configured with buttons that send them events when clicked.

Some Options:

• Provide an HTTP endpoint to hit with the output payload.
  • This has the downside that you have to provide a URL that is actually resolvable by the task.
  • Providing the base hostname or IP in the Ergo config would be a good way to do this.
• Provide a file path to write with the output payload. For docker containers this would be a volume mounted into the container.
  • For task orchestrators, can we do something similar?