-
Notifications
You must be signed in to change notification settings - Fork 742
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://microsoft.github.io/GitOps/index.html is the official page
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚢🚢🚢
This PR adds a workflow to automate running
dotnet format
per 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 format
and 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 themain
branch.formatted-...
branch, the action will also create a new issue with the name of the branch in the body and acode-formatting-automation
label.code-formatting-automation
label andformatting-refs/heads/main
in the body and create a PR to mergeformatting-refs/heads/main
intomain
with thecode-formatting-automation
label.code-formatting-automation
label 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.