how does generation of environment variables, event payloads and various contexts work?

[iamstarkov]

I want to write a test for my GitHub action, which I want to be able to run locally, for that I need make env vars, payloads and context available. That reminded me of act, because you must have solved this problem in order to run arbitrary workflows. I looked into the code and found https://github.com/nektos/act/blob/master/pkg/model/github_context.go.

Does it mean you just generate from scratch and have to update every time GitHub adds new things to it?

[wellkilo]

act combines static defaults, local repository data, CLI inputs, and the event JSON; it does not attempt to synthesize a byte-for-byte GitHub webhook for every event.

At a high level:

• -e/--eventpath supplies github.event and GITHUB_EVENT_PATH.
• the positional event name (for example act pull_request) selects workflows and sets github.event_name;
• repository/ref/SHA/workspace values come from the local Git repository plus CLI overrides;
• secrets, vars, env and inputs come from their respective CLI files/flags and workflow YAML;
• actor/server/API URLs have act defaults and can be overridden where supported.

The GitHub context is assembled in pkg/model/github_context.go, while the runner reads the supplied event file and copies it into the job as workflow/event.json.

For testing an action, do not recreate all possible contexts yourself. Create minimal webhook fixtures for the events your action supports, inject secrets/vars explicitly, and assert only fields in GitHub's documented event schema. When your code calls the live REST API, either use a real test repository/token or mock that boundary—an event fixture cannot create the referenced issue/PR/release in GitHub.

Yes, act must evolve when GitHub adds semantics that affect emulation, but most new event fields need no act code change: they pass through transparently from event.json. Code changes are needed for derived context values, runner behavior, expressions, commands, services, and other execution semantics.

[Icaro0310]

Roughly, yes — it's assembled from scratch. In my reading the flow is:

• pkg/model/github_context.go builds the github context: repo/sha/ref come from your local git checkout (remote URL → GITHUB_REPOSITORY, HEAD → GITHUB_SHA), GITHUB_EVENT_NAME/payload come from the --eventpath/-e event JSON (defaults to push), actor from --actor or git config, the rest are defaults like RUNNER_OS/RUNNER_ARCH.
• The other contexts (env, matrix, needs, steps, secrets, vars, inputs) are populated per-job in pkg/runner/run_context.go by merging workflow env: blocks, --env-file/-e, --secret-file, --var-file, and job outputs.
• ${{ }} expressions get evaluated against those contexts via pkg/exprparser.

For your test you could just reuse act: act -e event.json --env-file .env --secret-file .secrets, or import pkg/model/pkg/runner as a library instead of re-implementing it.

—
More of my work lives here: github.com/Icaro0310 · Website: icaro0310.github.io