Create workflow to automate code formatting #11911
Conversation
|
Test this change out locally with the following install scripts (Action run 6328626962) VSCode
Azure CLI
|
| @@ -0,0 +1,49 @@ | |||
| id: prAutoApproval.formatter | |||
There was a problem hiding this comment.
Is there any documentation you can point to in a comment here? I'm having trouble finding anything.
There was a problem hiding this comment.
https://microsoft.github.io/GitOps/index.html is the official page
There was a problem hiding this comment.
So I guess https://microsoft.github.io/GitOps/policies/resource-management.html?tabs=event-conditions%2Csearch-frequency was the documentation I was looking for. Does it make sense to add this link as a comment?
There was a problem hiding this comment.
Maybe we should have a readme.md file in .github/policies? This is the repo's third policy file, but I did need to search emails and Teams chats to find documentation on the structure of these files.
There was a problem hiding this comment.
The Policy Service doesn't seem to like .md files in the .github/policies folder. I'll add that note to the repo's CONTRIBUTING.md file instead.
.github/workflows/run-formatter.yml
Outdated
| @@ -0,0 +1,75 @@ | |||
| name: Run formatter | |||
| # This action will be run weekly against main and can be run on-demand against main. | |||
| # It will run an automated code formatter and commit and push the changes (if any). If the source branch is protected, then the workflow will create a new to commit and push the changes. | |||
There was a problem hiding this comment.
will create a new (missing word) to commit
CL, branch, PR?
|
Thanks! |
| @@ -7,6 +7,7 @@ indent_size = 4 | |||
| charset = utf-8 | |||
There was a problem hiding this comment.
So is it possible to test out policies in a forked branch? (I hate that actions and build scripts are difficult to verify pre-merge.)
There was a problem hiding this comment.
Unfortunately not. I was able to test out the GH action declared in .github/workflows/run-formatter.yml before opening the PR (#11910 was opened automatically when I enabled branch protection on the jeskew/automated-formatting branch; a prior run pushed directly to jeskew/automated-formatting before branch protection was enabled).
Github policies, however, will by design only run once they are committed to the repo's default branch. The GitOps.YmlValidation workflow checks the syntax of policies, but it can't verify that a policy will do what we expect it to.
|
@jeskew Are the formatting settings consistent between VS, VS code, and |
@majastrz Yes, they should all be following the directives in the |
Makes sense. If we do have VS code or VS specific directives in use, we should remove them, so all methods of editing converge on the same formatting. (I wouldn't block the PR on this, though.) |
This PR adds a workflow to automate running
dotnet formatper the discussion in #11691. Since we can't create a PR from a GitHub action, the workflow is a bit of a Rube Goldberg machine:dotnet formatand then either commit and push the results directly to the source branch (if the branch is not protected) or commit and push the results to a branch namedformatted-refs/heads/<branch name>otherwise. This action can be run on demand for any branch and will be run weekly for themainbranch.formatted-...branch, the action will also create a new issue with the name of the branch in the body and acode-formatting-automationlabel.code-formatting-automationlabel andformatting-refs/heads/mainin the body and create a PR to mergeformatting-refs/heads/mainintomainwith thecode-formatting-automationlabel.code-formatting-automationlabel that were opened by the MS policy bot.I was able to test steps 1 and 2 with both protected and unprotected branches. The policy yml (for steps 3 & 4) is untested since policies must be committed to the repository's default branch before they will run.