Fixup changes/no changes exit codes for build-command

[echoix]

Seems like the handling of the exit codes to determine if changes are to be committed didn't work well once used in an action. Going simpler in bash, using only git diff with --exit-code in order to show the diff, but have the exit code. Then the exit code is handled by the outcome (using continue-on-error) to use the success or failure outcome of a step.

~~https://docs.github.com/en/actions/learn-github-actions/contexts#steps-context ~~
https://docs.github.com/en/actions/creating-actions/setting-exit-codes-for-actions#about-exit-codes
https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---exit-code
vs https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---quiet

Edit:
Since this approach didn't end up going smoothly, I changed the approach and used the https://github.com/stefanzweifel/git-auto-commit-action to commit and set an output if there were changes. With this, it works as expected.

Proposed Changes

1. Be able to commit changes with the build command (without the step being always skipped) -> using https://github.com/stefanzweifel/git-auto-commit-action
2. Disable workflow runs for slash command dispatcher and its commands on PR/pushes where possible: these files can't change the flavors by themselves
3. ...

Readiness Checklist

Author/Contributor

• Add entry to the CHANGELOG listing the change and linking to the corresponding issue (if appropriate)
• If documentation is needed for this change, has that been included in this pull request

Reviewing Maintainer

• Label as breaking if this is a large fundamental change
• Label as either automation, bug, documentation, enhancement, infrastructure, or performance

[echoix]

🦙 MegaLinter status: ⚠️ WARNING

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ BASH	bash-exec	6		0	0.01s
✅ BASH	shellcheck	6		0	0.14s
✅ BASH	shfmt	6	0	0	0.35s
✅ COPYPASTE	jscpd	yes		no	2.74s
✅ DOCKERFILE	hadolint	114		0	16.64s
✅ JSON	eslint-plugin-jsonc	21	0	0	2.14s
✅ JSON	jsonlint	19		0	0.26s
✅ JSON	v8r	21		0	11.92s
⚠️ MARKDOWN	markdownlint	309	4	230	6.15s
✅ MARKDOWN	markdown-link-check	309		0	5.46s
✅ MARKDOWN	markdown-table-formatter	309	4	0	17.85s
✅ OPENAPI	spectral	1		0	1.75s
⚠️ PYTHON	bandit	183		47	1.95s
✅ PYTHON	black	183	0	0	3.75s
✅ PYTHON	flake8	183		0	1.87s
✅ PYTHON	isort	183	0	0	0.78s
✅ PYTHON	mypy	183		0	6.77s
✅ PYTHON	pylint	183		0	11.81s
⚠️ PYTHON	pyright	183		249	17.97s
✅ REPOSITORY	checkov	yes		no	28.93s
✅ REPOSITORY	git_diff	yes		no	0.38s
✅ REPOSITORY	secretlint	yes		no	14.45s
✅ REPOSITORY	trivy	yes		no	26.46s
✅ SPELL	cspell	745		0	18.86s
✅ SPELL	misspell	566	0	0	0.87s
✅ XML	xmllint	3	0	0	0.35s
✅ YAML	prettier	81	0	0	3.34s
✅ YAML	v8r	23		0	58.32s
✅ YAML	yamllint	82		0	1.08s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[echoix]

Giving up. The theory worked, the shell commands worked, but I wasn't able to get it working as expected on GH actions on my fork's branch (the status handling, it was even worse). So I just went and looked for an action that does what I wanted. Went for the first that seemed correct, did what I wanted, and that was not too sketchy/still alive, https://github.com/stefanzweifel/git-auto-commit-action.

echoix#2
It works there now. So I'll port the changes here and retry.

[echoix]

@nvuillam could you take a look at this?

[echoix]

The failure is about the extends test, unrelated and won't help nor worsen that test

[bdovaz]

@echoix the culprit seems to be me.

In workflows I started to pass the branch to the container (GITHUB_REF_NAME):

megalinter/.github/workflows/deploy-DEV.yml

Line 210 in e90b345

docker run $CI_ENV -e TEST_CASE_RUN=true -e OUTPUT_FORMAT=text -e OUTPUT_FOLDER=${GITHUB_SHA} -e OUTPUT_DETAIL=detailed -e GITHUB_SHA=${GITHUB_SHA} -e GITHUB_REF_NAME=${GITHUB_REF_NAME} -e PAT="${{secrets.PAT}}" -e TEST_KEYWORDS="${TEST_KEYWORDS_TO_USE}" -e MEGALINTER_VOLUME_ROOT="${GITHUB_WORKSPACE}" -v "/var/run/docker.sock:/var/run/docker.sock:rw" -v ${GITHUB_WORKSPACE}:/tmp/lint oxsecurity/megalinter:${{steps.image_tag.outputs.tag}}

I do this because the remote tests use a url that was previously fixed to the main branch but now I make it vary based on that environment variable:

megalinter/megalinter/tests/test_megalinter/config_test.py

Line 22 in e90b345

test_folder = (

I don't know if it is because it is a fork the source of the PR but the url is weird, it equals to PR ID (2381):

And it returns a 404: https://raw.githubusercontent.com/oxsecurity/megalinter/2381/merge/.automation/test/mega-linter-config-test/remote/custom.mega-linter.yml

[echoix]

I see how it fails, and it seems we just need to find the correct variable/url to send.
Either way, I'm only waiting for a review to approve that PR to continue the Golang dependabot PR. I don't know if it has to be Nicolas, or it could be anybody else

[Kurt-von-Laven]

@bdovaz, we encountered this issue as well. Here is how we solved it. Basically, the branch name is usually GITHUB_REF_NAME, but you want GITHUB_HEAD_REF instead when GITHUB_EVENT_NAME is "pull_request", "pull_request_target", or I think anything else that starts with "pull_request".

[nvuillam]

@echoix I fixed a CI issue in main branch, please can u merge it in your branch so it passes more easily ?

[echoix]

@nvuillam Done :)

[nvuillam]

@echoix these test cases do not fail in other branches... ^^

[echoix]

Because they come from a branch of the repo. This comes from a fork.

[nvuillam]

Does it means that #2375 broke CI jobs from forks ? ^^ cc @bdovaz

[echoix]

See #2381 (comment)

[bdovaz]

Does it means that #2375 broke CI jobs from forks ? ^^ cc @bdovaz

Indeed, either someone will find the time to fix it or you will have to wait for me to be able to do so before the end of this week.

[echoix]

In the meantime could you merge to continue?

[echoix]

Thanks!

[echoix]

@nvuillam I don't understand now. What was working for even a PR in my branch, and that time I was sure (it's the third iteration of all what was supposed to work), still doesn't work on the PR #2380. My other option is to use the fetch depth of at least 2 instead of the default that is 1, since I read that detecting if changes were made may not always work if the fetch depth is 1.

[echoix]

Or maybe there is something special with the dependabot PRs?

[Kurt-von-Laven]

There is, yes. They are essentially treated like PRs opened from a fork.