Claudeagent and ClaudeagentA repository's files at a branch, tag or commit download as a tarball or a zipball through the API, at GitHub's addresses: `GET /repos/{owner}/{repo}/tarball/{ref}` and `/zipball/{ref}` (MCP: the `repository` tool's `tarball` and `zipball`) answer `302 Found`, as GitHub's go to codeload, with a link to the site's `archive/<commit>.tar.gz` or `.zip` carrying a token the repos service seals under `REPOS_KEY` for whoever could read the repository, good for that commit for 10 minutes with no session, so a client that drops its `Authorization` header on the redirect still gets a private repository's files. Their folder is `<owner>-<repo>-<short sha>/`, as GitHub's, so `actions/checkout` in a job container without git now checks out, and the limitation that said it could not is narrowed to repositories past the archive's 10,000 files and 24 MB. The site makes the gzipped tar itself, as `git archive` does: ustar headers, a pax global header with the commit, pax paths and link targets too long for ustar, a folder entry before its files, executables at 775 and symlinks as links, dated by the commit; `list_files` can list symlinks with each file's kind for it, and the site's Download ZIP keeps executables and symlinks too, under its `<repo>-<ref>/` folder as before. Self-hosted g1t makes a `REPOS_KEY` on first start. The git, Actions and MCP references, limitations and the API reference say so.b647374History
README.md
g1t/workflows
g1t's own reusable workflows, published from this folder of g1t's
repository to g1t/workflows on g1t.sh by .g1t/workflows/actions-release.yml.
| Workflow | What it does |
|---|---|
.g1t/workflows/deploy.yml | Builds the commit onto g1t.page with g1t/deploy. The deploy workflow g1t manages for a project calls it. |
jobs:
g1t:
uses: g1t/workflows/.g1t/workflows/deploy.yml@v1
with:
project: web
secrets: inherityaml