Automatic fixes fail when modifying workflow YAML files

[andrewvaughan]

Describe the bug GitHub blocks any workflow actions that attempt to modify another workflow YAML file, unless the token being used explicitly has the workflows permission set. This is generally a really bad idea, from a security perspective, to enable this permission for 3rd-party workflows. The GITHUB_TOKEN doesn't have the workflows permission set and cannot be used, per my understanding.

My recommendation would be one of the following, if a workflow .yml file is changed and the workflows permission is not set on the provided token:

1. Ignore any GitHub workflow .yml files and create a warning within the action runner to alert the user that those files were not automatically fixed;
2. Skip auto-acceptance and require the end-user to manually accept the changes if this circumstance appears, with a notice on the PR explaining why the automatic change was not made; or,
3. Create a separate PR specifically for the modified workflow .yml files to separate it from the token.

Another option, of course, would be to ignore any workflow YML file, by default, but I would heavily recommend making this configurable for users if this is the action taken.

To Reproduce Steps to reproduce the behavior:

1. Configure Megalinter to automatically commit auto-fix changes during PR
2. Enable Prettier in the Megalinter configuration to clean up .yml files; ensure the GitHub workflows directory is in scope
3. Create a horribly formatted GitHub workflow configuration (Hello World will suffice) parallel to the megalinter.yml file in .github/workflows and submit a Pull Request

Expected behavior Don't die.

Screenshots An example of a crash and failure, even though all Megalinter tests passed, because a parallel GitHub workflow (in this case .github/workflows/sync-labels.yml) was modified by the Prettier auto-fix:

Run stefanzweifel/git-auto-commit-action@3ea6ae190baf489ba007f7c92608f33ce20ef04a
  
Started: bash /home/runner/work/_actions/stefanzweifel/git-auto-commit-action/3ea6ae190baf489ba007f7c92608f33ce[20](https://github.com/andrewvaughan/template-core/actions/runs/7522939759/job/20475634172?pr=72#step:9:20)ef04a/entrypoint.sh
INPUT_REPOSITORY value: .
INPUT_STATUS_OPTIONS: 
INPUT_FILE_PATTERN: .
INPUT_BRANCH value: ops/0001/label-sync
From https://github.com/andrewvaughan/template-core
 * [new branch]      main                 -> origin/main
 * [new branch]      ops/0001/label-sync  -> origin/ops/0001/label-sync
 * [new branch]      ops/00[23](https://github.com/andrewvaughan/template-core/actions/runs/7522939759/job/20475634172?pr=72#step:9:24)/issue-automation -> origin/ops/0023/issue-automation
 * [new branch]      ops/0023/label-automation-v2 -> origin/ops/0023/label-automation-v2
 * [new branch]      ops/0056/yaml-config -> origin/ops/0056/yaml-config
 * [new branch]      production           -> origin/production
 * [new branch]      staging              -> origin/staging
Previous HEAD position was d99ecad Merge 73c839727505812ee4630524d80ae4da4034a8f1 into 9a88cacde6c8c154ac0c3594f6f7f1be75379bac
Switched to a new branch 'ops/0001/label-sync'
M	.github/.config/labels.yml
M	.github/workflows/sync-labels.yml
M	_TEMPLATE_CHECKLIST.md
branch 'ops/0001/label-sync' set up to track 'origin/ops/0001/label-sync'.
INPUT_ADD_OPTIONS: 
INPUT_FILE_PATTERN: .
INPUT_COMMIT_OPTIONS: 
INPUT_COMMIT_USER_NAME: megalinter-bot
INPUT_COMMIT_USER_EMAIL: [email protected]
INPUT_COMMIT_MESSAGE: [MegaLinter] Apply linters fixes
INPUT_COMMIT_AUTHOR: andrewvaughan <[email protected]>
[ops/0001/label-sync ea81744] [MegaLinter] Apply linters fixes
 Author: andrewvaughan <[email protected]>
 3 files changed, 1 insertion(+), 6 deletions(-)
INPUT_TAGGING_MESSAGE: 
No tagging message supplied. No tag will be added.
INPUT_PUSH_OPTIONS: 
To https://github.com/andrewvaughan/template-core
 ! [remote rejected] HEAD -> ops/0001/label-sync (refusing to allow a GitHub App to create or update workflow `.github/workflows/sync-labels.yml` without `workflows` permission)

Live view: https://github.com/andrewvaughan/template-core/actions/runs/7522939759/job/20475634172?pr=72#step:9:54

[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[bot]]

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.