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 project can build with a workflow. Turning on **Build with a workflow** under Settings, Deployments installs a managed workflow named `g1t` that calls g1t's reusable deploy workflow (`g1t/workflows/.g1t/workflows/deploy.yml@v1`, published from `workflows/` by the actions release) with the project's settings, and pushes and pull requests then start it rather than a build of Deployments' own: the same previews and production, at the same addresses, reported as `g1t / deploy`, now the check of the workflow's job, listed on the Actions page with its runs and logs. A pull request from a fork runs it with a read-only token, as on GitHub, and still gets its preview without the project's build secrets: a read-only job token may open a preview build only from a run of a managed workflow. Fork pull requests run the repository's managed workflows too. Its jobs are Actions time, at cost plus 20% on g1t's machines and free on a self-hosted runner. A workflow named `g1t` in `.g1t/workflows/` takes its place. The deployments and Actions guides say so. | 1 | # g1t/workflows |
| 2 | ||
| 3 | g1t's own reusable workflows, published from this folder of g1t's | |
| 4 | repository to `g1t/workflows` on g1t.sh by `.g1t/workflows/actions-release.yml`. | |
| 5 | ||
| 6 | | Workflow | What it does | | |
| 7 | | --- | --- | | |
| 8 | | `.g1t/workflows/deploy.yml` | Builds the commit onto g1t.page with `g1t/deploy`. The deploy workflow g1t manages for a project calls it. | | |
| 9 | ||
| 10 | ```yaml | |
| 11 | jobs: | |
| 12 | g1t: | |
| 13 | uses: g1t/workflows/.g1t/workflows/deploy.yml@v1 | |
| 14 | with: | |
| 15 | project: web | |
| 16 | secrets: inherit | |
| 17 | ``` |