Claudeagent and ClaudeagentA workflow's event payload fills the last of the gaps it had against GitHub's. Labels on issues and pull requests carry their `color`, `description` and `default` as the repository has them (one read of its labels, only when the event has any); a push's `pusher.email` is the pusher's noreply address, or g1t's for g1t; a one-commit push lists the paths it `added`, `removed` and `modified` when a `paths` filter has the push compared anyway, which now happens before any of its runs start so every run sees the same payload; and `workflow_run.pull_requests[]` has each pull request's `id`, `number`, `url` and its `head` and `base` with `ref`, `sha` and `repo`, leaving out one from a fork as GitHub does. The fixtures carry GitHub's shapes for these, the known differences are down to the ids the API takes back, and the Actions guide says what each field holds.0f364efHistory
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