GitHub Actions runs your build, test, and deploy steps automatically every time you push code. The catch is the YAML file that drives it: indentation matters, the keys are easy to misremember, and one bad space breaks the whole run. The fastest way to a clean file is the GitHub Actions Generator, which builds valid workflow YAML from a guided form. Here is how the pieces fit together.
Where the workflow file lives
A GitHub Actions workflow is a YAML file stored in the .github/workflows directory at the root of your repository. You can have several of them, one per task, such as one for tests and another for deployment. GitHub reads every file in that folder and runs the ones whose triggers match what just happened.
The structure of a workflow
Every workflow shares the same skeleton:
- name: a human-readable label that shows up in the Actions tab.
- on: the trigger. Common values are
push,pull_request, andworkflow_dispatch(a manual run button). You can scope these to specific branches. - jobs: one or more named units of work that can run in parallel.
- runs-on: the runner image a job uses, such as
ubuntu-latest. - steps: the ordered actions inside a job. Each step either uses a prebuilt action with
usesor runs a shell command withrun.
A typical continuous integration job checks out the code, sets up your language runtime, installs dependencies, then runs the tests. A deploy job adds a build step and a publish step on top of that.
Generate your workflow in three steps
- Open the GitHub Actions Generator and pick your trigger, such as push to main or a manual dispatch.
- Choose your runner and add steps: checkout, language setup, install, test, build, and deploy as needed.
- Copy the generated YAML into
.github/workflows/ci.ymland commit it.
The whole thing runs in your browser. Nothing about your repository or config is sent to a server.
Handle secrets the right way
Deploy steps usually need credentials: an API token, an SSH key, a registry password. Never paste these directly into the YAML, because anyone who can read the repo can read them. Instead, store each value under your repository settings as an encrypted secret, then reference it by name inside the workflow using the secrets context. GitHub injects the value at run time and masks it in the logs. The generator leaves placeholders for secret names so you can wire them up without ever exposing the actual value.
Related tools
- .gitignore Generator: keep build artifacts and local files out of the repo your workflow runs against.
- JSON Formatter & Validator: clean up the config and payloads your CI steps read and write.
- Word & Character Counter: handy for trimming commit messages, release notes, and PR descriptions.
Pick your trigger, add the steps you need, copy the YAML, and push. Your pipeline runs itself from there.