Automatic fixes fail when modifying workflow YAML files about megalinter

[nvuillam]

@andrewvaughan when such case happens, you can just download the job artifacts, then copy-paste content of folder "updated-sources" in your repo, then commit & push again: as the commit is from you and not from the workflow, it will pass :)

[andrewvaughan]

@andrewvaughan when such case happens, you can just download the job artifacts, then copy-paste content of folder "updated-sources" in your repo, then commit & push again: as the commit is from you and not from the workflow, it will pass :)

I did something similar on my end - I just ran npx prettier -w . on my end to fix things up and committed them myself.

Maybe the solution here, just to simplify things, would be to have a default configuration in that MegaLinter will not auto-fix anything in the workflows folder, but simply add a warning annotation in the workflow for the user that it found something to fix, but wouldn't fix it? That will prevent the less-graceful failure state.

The solution I imagine is an extra workflow step, directly after auto-fix has been performed, but prior to adding/committing to the commit or new PR.

This step would see if there were any un-added modifications to the glob .github/workflow/*.yml. If so, it would git checkout those files to revert them back to the base SHA and then the Workflow can add a warning annotation to the run to let the user know "hey, there were some workflow files that need auto-correction, but we're gracefully refusing to do that because we need special permissions to modify other workflow files." A similar message could be added to the PR comment.

That way, everything else would auto-fix, and the user would get a nice, tidy warning about it. I think this would only be one extra step, maybe two, in the workflow file? But y'all may have a more graceful idea. Would love to hear your thoughts!

[nvuillam]

@andrewvaughan your solution would work, but i'm afraid it would be a bit hammer for a little fly ^^

We would need to either add specific behavior on all linters that can impact yml, or to update the default workflow for all existing users...

That seems too big just for one use case, and it also would be opening the door to handle and maintain thousands of specific use cases ^^

But if you want to test the additional step just for documentation purpose , please be my guest :)

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.