GitHub actions workflow throws error 137 when installing dependencies

Question

I've created a workflow on GitHub actions. The first run worked well, but the next time I push to the main branch fails at install dependencies step. It throws me the following error

##[debug]Evaluating condition for step: 'Install dependencies'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: Install dependencies
##[debug]Loading inputs
##[debug]Loading env
Run npm i
##[debug]/usr/bin/bash -e /home/username/actions-runner/server-actions/_temp/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.sh
/home/user/actions-runner/server-actions/_temp/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.sh: line 1: 36323 Killed                  npm i
Error: Process completed with exit code 137.
##[debug]Finishing: Install dependencies

This is the yaml

name: Node.js CI

on:
  push:
    branches: [ "main" ]

jobs:
  build:

    runs-on: self-hosted

    strategy:
      matrix:
        node-version: [16.x]

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - name: Install dependencies
      run: npm ci
    - name: Building
      run: npm run build --if-present

What I'm doing wrong? Thanks in advance

Olpe

Which step is it? You are using a self-hosted runner. Have you verified if the OS on that runner killed it due to overutilization of memory or CPU? If it's a Linux-based runner, OOM (out-of-memory) killer might have killed it. But, you need to verify this on that runner e.g. with top or htop command. – Magdau

It's a Linux-based runner. I've created a droplet on DigitalOcean with the cheapest plan. Where do I have to add the htop command? – Olpe

You can SSH to that instance from your local machine and then observe the behavior there while the jobs are running. – Magdau

Thanks. CPU is on red numbers with 95% or higher, and Mem with green numbers 426M/474M. Probably I have to resize the droplet? This is the current machine Regular Intel 1 vCPU, 512 MB, 10 Gb SSD, Transfer 0.5 TB – Olpe

Was the job killed again while you were observing this? – Magdau

I cancelled the job because took more than 10 minutes. Do I let the job be killed? Also I saw the DigitalOcean graphic and it shows a 120% use of cpu – Olpe

Yes, please first make sure it is the reason. That higher CPU is fine as it's processing the job at that time. – Magdau

I tried again, and the job was killed in less than two minutes – Olpe

Check the output of grep -i 'killed process' /var/log/messages or dmesg -T | grep -i 'killed process'. Do you see that process name in the output? – Magdau

Yes! It says Out of memory: Killed process 40854 (npm ci) – Olpe

Right, that's the reason. Now, it's confirmed. You may consider beefing up your self-hosted runner. – Magdau

Thank you so much! Just to be sure, I have to resize the droplet on DigitalOcean, right? Or am I missing something? – Olpe

Sure, no problem at all! :) Yes, you may resize the droplet. BTW, why are you not using GHA-hosted runners? – Magdau

I'm totally new with runners, so I followed a tutorial. I want to build the app and upload it to the droplet when there's a push to main. I don't know what is the difference between a self-hosted and a GHA-hosted runner. – Olpe

Oh, right. So, you want to host your app too. In that case, you can simply use the GHA-hosted runner for CI, and use your droplet only to host your app. Your droplet won't be running the CI, it'll only host your app. – Magdau

Great thanks. My server uses Ubuntu 20.04, Is it ok to add runs-on: ubuntu-20.04 on the yaml? Sorry for all my questions. – Olpe

No worries. Yes, you can use ubuntu-latest. – Magdau

Awesome! :-) Glad to hear that. All the best! – Magdau

Answer 1

Seems like that process is being killed by the OOM (out-of-memory) killer. As you are using a self-hosted runner, you can SSH to that machine and observe the memory and CPU utilization with the top or htop command when the jobs are run.

If the job is killed, check system logs with:

dmesg -T | grep -i 'killed process'

If that killed process is there then that's the reason and you may consider beefing up the specs of your self-hosted runner.

Magdau

Answer 2

The error surprisingly came from the missing env variable that was used in my tests in NodeJS application (actually the entire env file was missing). Check all your env variables are accessible for your application. Thanks to this comment.

Algol