syntaqxAn issue says what closed it, linked: on flagon-io/demo #1 the session that built the page closed the issue through the issue tool's close, and its timeline said only "syntaqx closed this as completed", with nothing to follow to the commit that did the work or the session that made it. close_issue (REST, the MCP issue tool's close, `g1t issue close --commit`) now takes an optional commit: one on the default branch (repos' log and branch_drift) whose message names the issue after a closing keyword (closing::references). The issue then closes as completed in that commit exactly as its push would (close_by_commit: resolved_commit, "closed this in <commit>", issue.closed with commit), by the caller; a commit not on the default branch, or one not naming the issue, is refused saying why, and an already-closed issue says what closed it. The work service's CloseIssueArgs flattens IssueActionArgs, so integrations and security keep calling close_issue as they do. When an issue is closed in a session, the note ends "via session ses_…" and issue.closed carries session: the session the closing commit names in a G1t-Session trailer (on a push too), or, for a close made with a token, the closer's own active session on the issue (attached or linked; the person it acts for when it acts for one). The timeline renders that id as a session chip linking /<owner>/<repo>/work/sessions/<id>, next to the existing commit chip and #N links (messageParts gains a session part). The pull requests guide's Closing issues, the sessions guide, webhooks, the API reference notes, openapi.json, the CLI reference and ops table say so. Deploy: work and api together, then the site; the CLI flag ships with the next CLI release. Checked: cargo test -p g1t-work (202), -p g1t-api (209, openapi regenerated), -p g1t-contracts, -p g1t (ops_table and cli_reference regenerated); wasm32 check of g1t-work and g1t-api; apps/web npm run typecheck; node --test app/lib/commit-message.test.ts.84f55cbHistory
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.