syntaqxsudo's Overview adds up this month the way the Costs page does, so the two can't disagree. Before, the Overview kept its own count from the ledger. That count left usage paid with credit nowhere: neither revenue nor given. It also estimated what gifts cost as price less the margin. So a month of comped use read as a red margin on nothing sold. Now billing's Overview carries month_margin, the Costs model's figures for the month through its last rolled-up day (margin_through), and the Costs page and the Overview add up the same days with one function, overall_of. In the model, credits spent count as given (promotional, goodwill) or as sold (paid, refund), and so do the free tier, discounts and testing resets. Given is what it actually cost, and cost includes Cloudflare's bill. The Overview's revenue, margin on what was sold, Given by g1t, cost line (Cloudflare and models apart, with a link to Costs & margin) and the Given this month table (cost by why) read from it. The header says through which day. Before a day of the month is rolled up, it falls back to the ledger as before. The six-month chart and This month by kind still read the ledger. Checked: cargo test -p g1t-billing (292; new: the Overview and the Costs page add up the same days), apps/sudo tsc -b and npm test (159; new: marginApart, dayShort).ada34d7History
README.md
g1t/detect
Says what a g1t.page build of the checkout would find, without building or deploying anything: the same rules g1t/deploy builds with.
steps:
- uses: actions/checkout@v5
- id: detect
uses: g1t/detect@v1
- if: steps.detect.outputs.kind == 'none'
run: echo "::error::Nothing here would be served."
- if: steps.detect.outputs.framework == 'hugo'
run: echo "A Hugo site, served from ${{ steps.detect.outputs.output-dir }}"
- if: steps.detect.outputs.install != ''
run: ${{ steps.detect.outputs.install }}yaml
Inputs
| Input | Default | |
|---|---|---|
root-dir | The checkout | Where the project is in the checkout. |
build-command | None | A build command of your own, as g1t/deploy takes it. |
output-dir | None | An output folder of your own, as g1t/deploy takes it. |
build-as | auto | What it is built as: auto, static, workers or docker (Container), as g1t/deploy takes it. |
dockerfile | None | A Dockerfile's path of your own, as g1t/deploy takes it. |
Outputs
| Output | |
|---|---|
kind | workers (a wrangler.jsonc, wrangler.json or wrangler.toml, a framework's Cloudflare adapter, or a Node.js server run as a Worker), static (a site a build writes), html (the files as they are), container (a server that is not run as a Worker, a framework set up to need a server, or a Dockerfile with nothing else to serve) or none (nothing to serve). |
framework | The framework it is built with, from the table below; node for a Node.js server run as a Worker; for a container without one, dockerfile, or the server g1t writes a Dockerfile for (node, django, flask, fastapi, python, go, rails, rack, laravel, php). Empty when there is none. |
dockerfile | A container's own Dockerfile, relative to the project. Empty when g1t writes one, and for anything that is not a container. |
port | The port a container listens on: its Dockerfile's EXPOSE, else 8080. |
entry | For a Node.js server run as a Worker, the file that starts it, relative to the project. Empty for anything else. |
install | How dependencies are installed, from the lockfile: npm ci, pnpm install --frozen-lockfile, and so on, and bundle install for Jekyll. Empty when there is nothing to install. |
build | What builds it: your command, the package's build script (npm run build), the framework's own command, or wrangler deploy --dry-run for Workers. Empty when nothing does. |
output-dir | The folder served, relative to the project (. for the project itself): yours, a Workers project's assets directory, the folder the framework writes, or the first of dist, build, out, public, _site, .output/public that exists. Empty when a build has yet to write it, as for a Cloudflare adapter's Worker. |
When kind is none, the step's log says what to change or add, such as
a Dockerfile. Docker deployments
has the order in which a project's kind is decided.
Frameworks
framework | Found by | Serves |
|---|---|---|
vite, vite-react, vite-vue, vite-svelte, vite-solid, vite-preact | vite, and the framework's Vite plugin | dist, or build.outDir |
astro | astro | dist, or outDir; a Worker with @astrojs/cloudflare |
nextjs | next | out with output: 'export'; a Worker with @opennextjs/cloudflare and a wrangler.jsonc |
sveltekit | @sveltejs/kit | build with adapter-static; a Worker with adapter-cloudflare |
nuxt | nuxt | .output/public, from nuxi generate |
react-router, remix | @react-router/dev, @remix-run/dev | build/client with ssr: false |
gatsby | gatsby | public |
docusaurus | @docusaurus/core | build |
eleventy | @11ty/eleventy | _site |
angular | @angular/core and angular.json | dist/<project>/browser |
create-react-app | react-scripts | build |
hugo | hugo.toml, or Hugo's config.toml | public |
jekyll | _config.yml and a Gemfile | _site |
mdbook | book.toml | book |
What deploys has
each one's build command. Your build-command and output-dir win over
what is detected.
It runs g1t-runner detect, found or downloaded as g1t/deploy finds it.