Pick any line to see why it is the way it is: the commit, the pull request and issue it came from, and what the agent was thinking.
| A repository can run a managed workflow: one installed by g1t's own services without a file in the repository. It is listed, started, run and re-run like any workflow in `.g1t/workflows/`, under the path `managed/<name>.yml`, and a workflow of the same `name:` in the repository runs in its place, so moving one into the repository is committing its source. The Actions page says a managed workflow is managed by g1t rather than linking to a file. Nothing installs one yet; the deploy workflow deployments will install, which calls g1t's reusable deploy workflow with a project's settings as its inputs and reports as `g1t / deploy`, is written and tested but not installed. | 1 | -- Managed workflows (src/managed.rs): workflows installed into a repository |
| 2 | -- without being committed to it, such as the one deployments install for a | |
| 3 | -- project. Each runs under the path `managed/<name>.yml`; a workflow of the | |
| 4 | -- same `name:` in the repository's own folder runs in its place. | |
| 5 | CREATE TABLE IF NOT EXISTS managed_workflows ( | |
| 6 | repo_id TEXT NOT NULL, | |
| 7 | name TEXT NOT NULL, | |
| 8 | source TEXT NOT NULL, | |
| 9 | -- What installed it and keeps it: `deployments`, or a workspace's id. | |
| 10 | origin TEXT NOT NULL, | |
| 11 | updated_at TEXT NOT NULL, | |
| 12 | PRIMARY KEY (repo_id, name) | |
| 13 | ); |