Reviewing AL-Go System Update files is not cool

[navdotnetreqs]

Hi,

reviewing changes in the PR created by Update AL-Go System Files is not cool.

This is the change in literally every single file:

And the minute thing that actually changed is buried within these.

Is there really no way to set a general version-tag somewhere and reference to that instead ? That way all these lines needn't be modified in every update.

uses: microsoft/AL-Go-Actions/[email protected]

[freddydk]

I am not really expecting people to review the Update AL-Go System Files PR - all the changes done to the system files are really the same as updating your phone or computer - you can see in the release notes what's new - but no reason to go through all the changes.

[AskeHolst]

But why create a PR if there is no reason to review it? In earlier versions, a scheduled run of Update AL-Go System Files would just commit directly. Now there is a PR created for review - not fun to approve a hundred PRs...

[aholstrup1]

In Microsoft, we create pull requests for Update AL-Go System Files to two reasons:

• Security - We don't want to give an account or GitHub app permission to push directly to main / release branches
• Protecting the build processes - In case something in the latest AL-Go versions breaks your build (it shouldn't but in case we have a bug in AL-Go) you'll catch it in the PR and won't have a broken CI/CD after an AL-Go update.

That being said, I believe we do support direct commits in AL-Go workflows. If you add the following construct to your settings, it should attempt to do a direct commit (if your branch protection policies allows for that of course)

"commitOptions": {
    "createPullRequest": false
}

https://aka.ms/algosettings#commitOptions

[AskeHolst]

Thank you @aholstrup1 that's what I was looking for.
I actually do like the PR for the AppSource apps we have, but not for the hundred repos for customer PTEs, some of which have been stale for years. I'll play with the commitOptions and workflow settings.