SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
CI/CD 18 errors

CI/CD Pipeline Errors

GitHub Actions, GitLab CI, Jenkins, CircleCI: permissions, runners and resource limits.

Understanding CI/CD errors

CI failures that do not reproduce locally are almost always about environment, permissions or resource limits rather than about your code. CI runners have less memory than a laptop, a deliberately restricted token, a clean cache, and often a different CPU architecture. Treating a CI failure as a code bug before checking those four things wastes an enormous amount of time.

How to debug CI/CD errors

  1. Re-run the job with debug logging enabled (ACTIONS_STEP_DEBUG=true in GitHub Actions, CI_DEBUG_TRACE in GitLab). The default log deliberately hides the most useful lines.
  2. Print the environment early: env | sort, node -v, free -m, df -h. Half of all "works on my machine" CI bugs are visible in that output.
  3. Check token permissions explicitly. GitHub's GITHUB_TOKEN defaults to read-only in many organisations and produces the misleading Resource not accessible by integration error.
  4. Remember that secrets are not available to workflows triggered by pull requests from forks. This is a security feature, not a misconfiguration.
  5. Reproduce locally in the same container image the runner uses, rather than on your host, before changing pipeline configuration.

Tools worth reaching for

  • ACTIONS_STEP_DEBUG
  • act (local Actions runner)
  • docker run <runner image>
  • free -m / df -h in-job

All 18 CI/CD errors

Other categories