Skip to main content

​
A job doesn’t start

  • Your organization isn’t turned on yet. After you install the App, we turn your organization on by hand, and jobs wait until then.
  • The label. It must be exactly one Coreload label, one we sent you, with nothing else in runs-on.
  • The repository. It must be private, and selected in the App’s repository list (Settings > GitHub Apps > Coreload CI > Configure).
  • The runner group. Coreload’s runner group in Settings > Actions > Runner groups must be left as we set it. Widened, it serves nothing until it matches again.
  • Coreload itself. Check the status page. (coming soon)

​
A job is slow

​
A step fails

A job that starts but fails on a step its old runner passed usually needs something the Coreload image doesn’t have yet. See Languages and tools for what works. No Docker yet. A step that runs docker fails because the command is not found, and a job with container: or services: can’t start. Keep these jobs on their current runner for now. A setup action that downloads an Ubuntu build. actions/setup-python failed for the CPython versions our benchmark runs tried (the quickstart lists them) when it downloaded them. Keep the job on its current runner for now.
A tool that isn’t preinstalled. Go and Rust aren’t, so a step that runs go without installing it fails. Our run recorded spawn go ENOENT from a step that starts go from Node.js (a JavaScript action or script). Add actions/setup-go before it. Coming: the image GitHub’s hosted Ubuntu runners use, with Docker and the standard toolchains. (coming soon)