keepcalculator

06 Numbers and Powers

Test GitHub Actions Workflow Changes Before Merging

Card No. 06·62419 · Updated · Standard formula, shown below

Testing GitHub Actions workflow changes before merging prevents broken pipelines from disrupting your team. This guide shows you how to validate workflow syntax, test logic locally, and run workflows from branches or pull requests before they reach your main branch.

What You’ll Need

  • A GitHub repository with an existing workflow (or the ability to create one)
  • Git installed locally (for CLI methods)
  • Optional: Docker installed (for act local testing)
  • Basic familiarity with YAML syntax

Step-by-Step

  1. Validate YAML syntax locally
    Before pushing, check that your workflow file is valid YAML. Use a linter or an online YAML validator. For example, with Python: python -c "import yaml; yaml.safe_load(open('.github/workflows/your-workflow.yml'))". This catches indentation errors and malformed structures early.
  2. Use GitHub’s workflow linter (actionlint)
    Install actionlint locally or run it in a container. It checks for syntax errors, deprecated actions, and common mistakes. Run it on your workflow file: actionlint .github/workflows/your-workflow.yml. This tool understands GitHub Actions-specific syntax and catches issues that generic YAML linters miss.
  3. Test with act locally (optional but powerful)
    If you have Docker, install act to run workflows locally. It simulates the GitHub Actions environment. Run act -l to list jobs, then act -j to run a specific job. Use act -n to do a dry-run without executing steps. Note: some actions (especially those requiring secrets or specific GitHub APIs) may not work perfectly locally, but it’s great for catching logic errors.
  4. Push to a feature branch
    Create a new branch, commit your workflow changes, and push. This triggers the workflow on that branch. Check the Actions tab to see if the workflow runs as expected. Look for any failures in the run logs.
  5. Use workflow_dispatch for manual testing
    Add a workflow_dispatch trigger to your workflow (if not already present). This allows you to manually trigger the workflow from the GitHub UI with a button. After pushing to a branch, go to the Actions tab, select your workflow, and click “Run workflow” to test it on demand.
  6. Test on a pull request (PR)
    Create a pull request from your feature branch to the main branch. If your workflow has a pull_request trigger, it will run on the PR. This is the closest to production testing without merging. Review the PR checks and logs for any issues.
  7. Use a staging environment or separate branch for destructive tests
    If your workflow deploys or modifies resources, run it against a staging environment first. You can use environment variables or secrets to point to a test server. This avoids breaking production if something goes wrong.
  8. Review the workflow run logs carefully
    After a test run, expand each step in the GitHub Actions UI to see the output. Look for warnings, deprecation notices, or unexpected failures. Pay attention to the exit codes of each step.
  9. Test with a matrix strategy
    If your workflow uses a matrix (e.g., multiple OS or Node versions), test with a small matrix first (e.g., one OS) to catch issues quickly, then expand to the full matrix. This saves time and resources.
  10. Merge and monitor
    Once all tests pass, merge the PR. After merging, monitor the workflow run on the main branch to ensure it still works. Sometimes the context (e.g., branch name, default branch) differs, so a quick check is wise.

Common Mistakes

  • Ignoring YAML indentation: GitHub Actions is strict about indentation; even a single space can break the file. Always validate YAML syntax.
  • Using secrets in local tests: act doesn’t have access to GitHub secrets unless you provide them. Never commit real secrets; use dummy values for local testing.
  • Forgetting to update the on trigger: If you add a new trigger (like workflow_dispatch), you must push the change to the branch before it takes effect.
  • Testing only the happy path: Test failure scenarios too. For example, if a step is supposed to fail under certain conditions, verify that the workflow handles it correctly.
  • Not checking the environment: Actions that rely on specific OS versions or pre-installed tools may fail locally if your environment differs. Use the same runner image as GitHub (e.g., ubuntu-latest) in act.

Tips

  • Use if conditions to skip steps: You can test with a variable that skips certain steps (e.g., if: env.SKIP_DEPLOY == 'true') to avoid side effects during testing.
  • Leverage concurrency to cancel redundant runs: If you push multiple times, use concurrency to cancel previous runs, saving resources and avoiding confusion.
  • Keep a testing workflow separate: Create a dedicated workflow for testing changes to your main workflow, or use a separate branch that is never merged to main.
  • Use the GitHub API to trigger workflows: You can trigger a workflow_dispatch event via the API, which is useful for automated testing scripts. Example: curl -X POST -H "Authorization: token $GITHUB_TOKEN" https://api.github.com/repos/owner/repo/actions/workflows/your-workflow.yml/dispatches -d '{"ref":"main"}'
  • Check the workflow’s permissions: If your workflow uses the GITHUB_TOKEN for actions like pushing or creating releases, ensure the permissions are set correctly. Test with the least privilege needed.

Troubleshooting

Workflow doesn’t appear in the Actions tab
Check the file path: it must be .github/workflows/your-file.yml. Also ensure the YAML is valid. If you just pushed, wait a few seconds; GitHub may take a moment to pick it up.

Workflow runs but fails immediately
Look at the first step’s logs. Common causes: invalid YAML (caught by GitHub), missing secrets, or incorrect syntax in the on trigger. Use actionlint to catch these.

Local act fails with “Cannot find any actions”
Ensure you have Docker running and the action is available. Some actions require specific setup; check the action’s README for local testing instructions.

Secrets are not available in the run
Secrets are only available in the GitHub environment, not locally. For local testing, use dummy values. In GitHub, ensure the secret is defined in the repository or environment settings.

Workflow passes locally but fails on GitHub
Differences between local and GitHub environments (e.g., OS versions, installed software, environment variables). Check the runner image used on GitHub and try to match it locally. Also, some actions may require network access that is blocked locally.

Frequently Asked Questions

Can I test a workflow without pushing to GitHub?

Yes, using act locally. It simulates the GitHub environment, but not all features are supported (e.g., secrets, some actions). It’s a good first pass, but always push to a branch for final validation.

How do I test a workflow that runs on a schedule?

You can’t manually trigger a scheduled workflow, but you can temporarily change the on trigger to workflow_dispatch for testing, or use the API to trigger it manually if you add workflow_dispatch alongside the schedule.

Is it safe to test workflows on the main branch?

It’s not recommended. Use a feature branch or a separate testing branch. If you must test on main, ensure the workflow has no destructive side effects, or use environment protections.

What is the best way to test a workflow that deploys to production?

Use a staging environment. Configure the workflow to deploy to a test server by using environment variables or secrets that point to staging. You can also add a manual approval step before production deployment.

Can I test multiple workflow files at once?

Yes, you can run act on the entire .github/workflows directory. It will run all workflows that match the event you specify. Use act -l to list all jobs across all workflows.

How do I debug a failing step in GitHub Actions?

Add debug logging by setting the secret ACTIONS_STEP_DEBUG to true in your repository. This enables verbose logs for each step. Also, you can add echo "::debug::message" in your steps to output custom debug info.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →