Shell arguments not passed though

[bobturneruk]

Describe the bug

The action does not allow arguments to be passed into the shell parameter. These are apparently required to run in a conda environment (e.g. https://github.com/pykale/pykale/blob/main/.github/workflows/test.yml).

- name: Run tests
  id: run_tests
  uses: nick-invision/retry@v2
  with:
    timeout_minutes: 180 # Very long
    max_attempts: 3
    retry_wait_seconds: 10800 # Wait 180 minutes before trying again (fail likely because server down)
    command: |
      pytest --nbmake --cov=kale
    shell: bash -l {0}

##[warning]Attempt 1 failed. Reason: Shell bash -l {0} not supported.  See https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#using-a-specific-shell for supported shells

Expected behavior This may be a fairly straightforward job around this switch statement https://github.com/nick-invision/retry/blob/7f8f3d9f0f62fe5925341be21c2e8314fd4f7c7c/src/index.ts#L84 but I'm not a typescript coder. If Windows didn't need the appended ".exe", perhaps passing SHELL to executable would solve this? I guess it depends a bit on downstream error handling if someone passes a genuinely invalid shell.

Logs Some logging here https://github.com/pykale/pykale/runs/5142791229?check_suite_focus=true I can provide more if needed.

[ureciocais]

@haipinglu would you be ok if I raise a PR for this? Perhaps a simple SHELL.split(' ')[0] for that switch?

[nick-fields]

@haipinglu would you be ok if I raise a PR for this? Perhaps a simple SHELL.split(' ')[0] for that switch?

Please do!

[ureciocais]

PR ready @nick-fields :)

[anmyachev]

Looks like my problem related to the issue (was launched on standard Ubuntu). It starts appearing after I start using shell: bash -l {0} in order to correctly activate the conda environment:

Run nick-fields/retry@v2
  with:
    timeout_minutes: 1
    max_attempts: 5
    shell: bash -l {0}
    command: conda env list
    retry_wait_seconds: 10
    polling_interval_seconds: 1
    warning_on_retry: true
    continue_on_error: false
  env:
    MODIN_GITHUB_CI: true
    MODIN_ENGINE: unidist
    UNIDIST_BACKEND: mpi
    PARALLEL: 
    INPUT_RUN_POST: true
    CONDA: /usr/share/miniconda
    CONDA_PKGS_DIR: /home/runner/conda_pkgs_dir

node:events:491
       throw er; // Unhandled 'error' event
       ^
 
 Error: spawn bash -l {0} ENOENT
     at Process.ChildProcess._handle.onexit (node:internal/child_process:285:19)
     at onErrorNT (node:internal/child_process:485:16)
     at processTicksAndRejections (node:internal/process/task_queues:83:21)
 Emitted 'error' event on ChildProcess instance at:
     at Process.ChildProcess._handle.onexit (node:internal/child_process:291:12)
     at onErrorNT (node:internal/child_process:485:16)
     at processTicksAndRejections (node:internal/process/task_queues:83:21) {
   errno: -2,
   code: 'ENOENT',
   syscall: 'spawn bash -l {0}',
   path: 'bash -l {0}',
   spawnargs: [
     '-c',
     'conda env list\n'
   ]
 }

Hello @nick-fields! Maybe you have an idea what's wrong?

[keremispirli]

Run nick-fields/retry@v2
  with:
...
    shell: bash -l {0}
...
node:events:491
       throw er; // Unhandled 'error' event
       ^
 
 Error: spawn bash -l {0} ENOENT
     at Process.ChildProcess._handle.onexit (node:internal/child_process:285:19)
     at onErrorNT (node:internal/child_process:485:16)
     at processTicksAndRejections (node:internal/process/task_queues:83:21)
 Emitted 'error' event on ChildProcess instance at:
     at Process.ChildProcess._handle.onexit (node:internal/child_process:291:12)
     at onErrorNT (node:internal/child_process:485:16)
     at processTicksAndRejections (node:internal/process/task_queues:83:21) {
   errno: -2,
   code: 'ENOENT',
   syscall: 'spawn bash -l {0}',
   path: 'bash -l {0}',
   spawnargs: [
     '-c',
     'conda env list\n'
   ]
 }

Hello @nick-fields! Maybe you have an idea what's wrong?

I had the same error with v3, without passing a "shell" param. It turned out the runner machine didn't have bash. Solved by setting shell: sh.

@nick-fields would it make sense to use sh as the default shell instead of bash? AFAIK it's hard-/symlinked to whatever shell is used in any distro.