Testing Locally with act - Problem with Context Issue

[palagdan]

Hello, I created a GitHub workflow that automatically assigns a label to an issue based on its title and description after the issue is created or edited.

To test this workflow locally, I struggled a lot because using a test repository wasn't very convenient. I found this tool that helps run GitHub Actions workflows locally.

The problem is that my workflow requires the issue creation event to extract the title and labels from the issue and based on these two parameters assigns a label to the issue from the repo available labels.

To simulate this, I created a JSON file with an actual issue object from my test repository and provided it to the act command using the -e flag for a scenario like this:

act -W .github/workflows/issue-created.yml  -e scenarios/create-issue-event.json 

However, when the workflow runs locally, I encounter an error stating that the issue does not exist, or every field of the issue is undefined:

const issue = await octokit.rest.issues.get({
    ...github.context.issue,
    issue_number: github.context.issue.number,
});

Could anyone suggest why this might be happening? Am I missing something in the setup, or is there another way to simulate an issue context for testing? Thank you for any help!

[wellkilo]

-e supplies github.event, but it does not create a real issue in GitHub. Your action then calls octokit.rest.issues.get, which is a network API call against the repository from github.context; if the event points to a fake/nonexistent issue or act's default repository, GitHub correctly returns not found.

Use a webhook-shaped event file and set the repository/token explicitly:

{
  "action": "opened",
  "issue": {
    "number": 123,
    "title": "real test issue title",
    "body": "body",
    "labels": []
  },
  "repository": {
    "name": "repo",
    "full_name": "OWNER/repo",
    "owner": { "login": "OWNER" }
  }
}

act issues \
  -W .github/workflows/issue-created.yml \
  -e scenarios/create-issue-event.json \
  -s GITHUB_TOKEN="$(gh auth token)" \
  --env GITHUB_REPOSITORY=OWNER/repo

If the workflow only needs the triggering data, do not re-fetch it: read github.context.payload.issue (or github.event.issue in YAML) and unit-test the label-selection function with fixtures. If you deliberately call issues.get, number 123 must actually exist in OWNER/repo and the token must have access.

Also pass the event name explicitly. Without act issues, act may plan a different trigger even though an event JSON file is present. The -e flag only defines GITHUB_EVENT_PATH; it does not infer or materialize GitHub resources.

[Icaro0310]

act defaults to a push event, so on issues/issues.edited triggers your context fields like github.event.issue.title come up empty. You need to explicitly run the issues event and pass a payload:

// event.json
{
  "action": "opened",
  "issue": {
    "number": 1,
    "title": "Bug: app crashes on login",
    "body": "Steps to reproduce..."
  }
}

Then:

act issues -e event.json

That populated github.event.issue.title/body correctly for my issue-context debugging. Also note that anything actually hitting the GitHub API (like applying the label) will fail locally without a real token — you can pass -s GITHUB_TOKEN=$(gh auth token) if your workflow calls the API, though I usually split "compute the label" and "apply it" into separate steps and only test the first part with act.

—
Check out my Repositories: github.com/Icaro0310 · Website: icaro0310.github.io