yamllint: command not found
till opened this issue ยท 7 comments
Running your action with act
currently produces:
[ci/helm-lint] ๐ณ docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/5-composite-yamllint.sh] user= workdir=
| ======================
| = Linting YAML files =
| ======================
| /var/run/act/actions/ibiqlik-action-yamllint@v3.1.1/entrypoint.sh: line 34: yamllint: command not found
This is how I use it:
---
name: ci
on:
pull_request
jobs:
helm-lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: ibiqlik/action-yamllint@v3.1.1
with:
format: github
file_or_dir: |
certmanager
certmanager-config
cloudnative-pg
haproxy-ingress
postgresql
I found the same problem when use act for local ci test.
Part of my workflows job show:
yamllint-checker:
needs: changes
if: |
(needs.changes.outputs.yaml == 'true')
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Yamllint checker
uses: ibiqlik/action-yamllint@v3
with:
file_or_dir: samples/deploy
config_file: .yamllint.yml
I just looked at the action, it seems it doesn't actually install yamllint? I am a bit confused.
I'm facing the same issue in a self hosted runner. I was under the impression this was a docker action (https://docs.github.com/en/actions/creating-actions/creating-a-docker-container-action), but it appears to be a composite action which only runs the entrypoint.sh
...
Looks like versions prior to v3 might work. https://github.com/ibiqlik/action-yamllint/releases/tag/v3.0.0
Perhaps the action should verify that yamllint
is installed? And if not, install it into a venv
that is then destroyed.
I will take a stab at this improvement. If it wouldn't be accepted, please let me know though so I don't waste my time.
I was able to fork this repository and fix it for myself by modifying action.yml
to replace
using: 'composite'
steps:
- run: ${{ github.action_path }}/entrypoint.sh
shell: bash
env:
INPUT_FILE_OR_DIR: ${{ inputs.file_or_dir }}
INPUT_CONFIG_FILE: ${{ inputs.config_file }}
INPUT_CONFIG_DATA: ${{ inputs.config_data }}
INPUT_FORMAT: ${{ inputs.format }}
INPUT_STRICT: ${{ inputs.strict }}
with
using: 'docker'
image: 'Dockerfile'
If this has no other unwanted side effects, I would like to see this fixed upstream.
Good thinking! The only problem I can see is that this builds the image each time.
I ended up installing into a venv
, and destroying the venv
afterwards. It's not necessary to destroy after on a GitHub runner, but it could be necessary in a self hosted runner. I'd be happy to submit a PR... if this would be desirable, please let me know.
From what I'm reading, pip install
ing into a temporary venv
as part of the composite action steps seems like the best path forward.