Add kube-linter to ci

[LuisDuarte1]

Adds kube-linter to lint Kubernetes *.yaml files automatically

[limwa]

I was looking at the sample workflow for kube-linter-action and I saw they were uploading the SARIF report files using CodeQL. Is this better?

Also, did you consider running the workflow on push? If so, is there any reason why you decided that event shouldn't run the workflow?

[LuisDuarte1]

I was looking at the sample workflow for kube-linter-action and I saw they were uploading the SARIF report files using CodeQL. Is this better?

I tried that method, but on the recent versions of the SARIF upload action (which github requires), the actions fails when there are no linting issues (because kube-lint doesn't create a report SARIF file if it passes). I think that reading the action log when it fails is also okay, there aren't many advantages on this case of using the SARIF files, wdyt?

Also, did you consider running the workflow on push? If so, is there any reason why you decided that event shouldn't run the workflow?

What's the advantage of push vs pull_request on this case? I think both due to our flow, they accomplish the same thing? I'm not too sure 😅

[limwa]

I was looking at the sample workflow for kube-linter-action and I saw they were uploading the SARIF report files using CodeQL. Is this better?

I tried that method, but on the recent versions of the SARIF upload action (which github requires), the actions fails when there are no linting issues (because kube-lint doesn't create a report SARIF file if it passes). I think that reading the action log when it fails is also okay, there aren't many advantages on this case of using the SARIF files, wdyt?

Okay, that sounds good! I think we can leave things as they are and if it eventually becomes beneficial, we can consider it.

Also, did you consider running the workflow on push? If so, is there any reason why you decided that event shouldn't run the workflow?

What's the advantage of push vs pull_request on this case? I think both due to our flow, they accomplish the same thing? I'm not too sure 😅

You're right, there aren't many differences. push triggers the check when a commit is pushed to a branch in the list and the status indicator is present next to the commit on the repository page. pull_request triggers the check when a commit is pushed to a branch with an active pull request that targets one of the branches in the list and the status indicator is only shown on the PR.

Most people use both and push therefore serves the purpose of giving more assurances to the maintainers. Some maintainers also use pull_request for linting and code quality issues and push for deployment or publishing to a registry.

You are right in that, in our case, they would accomplish the same thing since a commit can only be pushed to a branch via a PR. I was just asking in case there was any other reason!

[LuisDuarte1]

You're right, there aren't many differences. push triggers the check when a commit is pushed to a branch in the list and the status indicator is present next to the commit on the repository page. pull_request triggers the check when a commit is pushed to a branch with an active pull request that targets one of the branches in the list and the status indicator is only shown on the PR.

Most people use both and push therefore serves the purpose of giving more assurances to the maintainers. Some maintainers also use pull_request for linting and code quality issues and push for deployment or publishing to a registry.

I'll add it to push then too, just to be visible in the commit history on the repo page ^^

[limwa]

LGTM 🚀