Claudeagent and ClaudeagentA workflow's event payload (`github.event` and the file at `GITHUB_EVENT_PATH`) reads as GitHub's webhook payload does. Ids are whole numbers, the same for an object wherever it appears and safe in JavaScript: `repository.id`, `pull_request.id`, `issue.id`, `review.id`, `sender.id` and every user's and owner's `id`, with g1t's own id as `node_id`; `github.repository_id`, `github.repository_owner_id`, `github.actor_id` and their `GITHUB_*` variables are the same numbers. What g1t's API takes back by id (comments, releases, deployments, workflow runs) keeps g1t's id, so `github.event.comment.id` still edits the comment. A repository in a person's own workspace is owned by a `User`, not an `Organization`. A push says whether it was `forced`, `created` or `deleted`, and its `head_commit` is the commit pushed. A pull request's `base.sha` is the tip of the branch it merges into at the event, not the merge base, and `merge_commit_sha` is the commit it landed as once merged; pull requests and issues carry `node_id`, `assignee`, `locked`, dates and label and milestone ids, and a fork's head names the fork. `workflow_run` has the followed run's attempt, times, actor, head commit, workflow id and URLs. Tests compare each payload's keys and types with trimmed copies of GitHub's documented payloads, and the Actions guide says what differs. OIDC claims keep g1t's ids, so trust policies already written still match.dfefa68History
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