How to use the GitHub Actions Workflow Generator.
CI workflows need the actual triggers, runtime and test commands. Keep permissions narrow and do not expose secrets to untrusted pull-request code.
Make the workflow fit your task.
Define triggers, runtime and test commands from the project, then grant only the permissions required by those steps. Keep untrusted pull-request execution separate from privileged release actions and verify runner compatibility.
- What you provide
- Repository stack and CI requirements.
- What you get
- Workflow YAML draft with scoped permissions.
See the input and the result.
Illustrative input and output · a teaching example, not a live WebAct run
Example input
Create a GitHub Actions workflow for a Node 24 project with committed package-lock.json and npm test. Trigger on push and pull request. No publishing or secrets required.
Completed example
name: Tests
on: [push, pull_request]
permissions:
contents: read
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- uses: actions/setup-node@v7
with:
node-version: 24
package-manager-cache: false
- run: npm ci
- run: npm test
Action major versions follow their official examples at editorial review. Confirm runner compatibility and pin reviewed commit SHAs if required by your repository policy.Load this input into the prompt, then copy it to WebAct to try the task. Your result may differ from the illustration.
Decisions and troubleshooting.
Should a test workflow receive write permissions by default?
Use read-only permissions when the test job does not need writes. Add privileges only for a clearly required action.
Why does the workflow fail before the test command runs?
Check the lockfile, runtime version, working directory and action runner requirements. Setup failures are distinct from failing tests.
Reference for this workflow.
Try it with your own source.
Replace the example with your material in the task prompt. Keep the requirements you need, then copy the task into WebAct.
Customize and copy the task ↑