diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json index 7a9af1b153b970..fe4a95bcc6b83a 100644 --- a/.devcontainer/devcontainer.json +++ b/.devcontainer/devcontainer.json @@ -16,7 +16,8 @@ "yzhang.markdown-all-in-one", "eamodio.gitlens", "yuichinukiyama.vscode-preview-server", - "aaron-bond.better-comments" + "aaron-bond.better-comments", + "foxundermoon.shell-format" ], // Use 'settings' to set *default* container specific settings.json values on container create. // You can edit these settings after create using File > Preferences > Settings > Remote. diff --git a/.restyled.yaml b/.restyled.yaml new file mode 100644 index 00000000000000..dd9c3eaa9aa0fe --- /dev/null +++ b/.restyled.yaml @@ -0,0 +1,83 @@ +# Do anything at all +enabled: true + +# Push the style fixes directly to the original PR +auto: false + +# Open Restyle PRs? +pull_requests: true + +# Add labels to any created Restyle PRs +labels: + - restyled + +# Labels to ignore +ignore_labels: + - restyled-ignore + +# Leave comments on the original PR linking to the Restyle PR? +comments: false + +# Request review on the Restyle PR +request_review: none + +# Patterns to exclude from all Restylers +exclude: + - ".github/workflows/**/*" # https://github.com/restyled-io/restyler/issues/73 + - "third_party/**/*" + - "third_party/**" + - "third_party/*" + - "build/**/*" + - "autom4te.cache/**/*" + +# Restylers to run, and how +restylers: + - name: clang-format + enabled: true + image: restyled/restyler-clang-format:v9.0.0 + command: + - clang-format + - "-i" + arguments: [] + include: + - "**/*.c" + - "**/*.cc" + - "**/*.cpp" + - "**/*.cxx" + - "**/*.c++" + - "**/*.C" + - "**/*.cs" + - "**/*.h" + - "**/*.hh" + - "**/*.hpp" + - "**/*.hxx" + - "**/*.h++" + - "**/*.H" + - "**/*.java" + - "**/*.js" + - "**/*.m" + interpreters: [] + - name: jq + enabled: true + include: + - "**/*.json" + - name: prettier-markdown + enabled: true + include: + - "**/*.md" + - "**/*.markdown" + - name: prettier-yaml + enabled: true + include: + - "**/*.yml" + - "**/*.yaml" + - name: shellharden + enabled: true + include: + - "**/*.sh" + - "**/*.bash" + - name: shfmt + enabled: true + include: + - "**/*.sh" + - "**/*.bash" diff --git a/.restyled.yml b/.restyled.yml deleted file mode 100644 index 7f917eeb8f275d..00000000000000 --- a/.restyled.yml +++ /dev/null @@ -1,28 +0,0 @@ ---- -image: restyled/restyler-clang-format:v9.0.0 -command: - - clang-format - - "-i" -auto: true -arguments: [] -exclude: - - ".github/workflows/**/*" # https://github.com/restyled-io/restyler/issues/73 - - "third_party/**" -include: - - "**/*.c" - - "**/*.cc" - - "**/*.cpp" - - "**/*.cxx" - - "**/*.c++" - - "**/*.C" - - "**/*.cs" - - "**/*.h" - - "**/*.hh" - - "**/*.hpp" - - "**/*.hxx" - - "**/*.h++" - - "**/*.H" - - "**/*.java" - - "**/*.js" - - "**/*.m" -interpreters: [] diff --git a/.vscode/settings.json b/.vscode/settings.json index 8864b21c0442bd..13ab3e1ac42d35 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -19,6 +19,9 @@ "[cpp]": { "editor.defaultFormatter": "xaver.clang-format" }, + "[dockerfile]": { + "editor.defaultFormatter": "ms-azuretools.vscode-docker" + }, "files.associations": { "iostream": "cpp", "array": "cpp", diff --git a/docs/PROJECT_FLOW.md b/docs/PROJECT_FLOW.md index 72e9be36b742f4..866e0087e5d3eb 100644 --- a/docs/PROJECT_FLOW.md +++ b/docs/PROJECT_FLOW.md @@ -1,50 +1,51 @@ ## CHIP Project Flow -This section is intended to cover how CHIP uses GitHub Projects, -Issues, Milestones, Releases, and Branches for program/project -management in the code repository. +This section is intended to cover how CHIP uses GitHub Projects, Issues, +Milestones, Releases, and Branches for program/project management in the code +repository. ### Issues -CHIP uses issues as simple problem descriptions or feature requests. In -general, all work contributed to the repository in the form of pull requests -(PR) should be under the auspices of some open issue. This may seem onerous and -in some cases duplicative, so consider these guidelines when deciding whether to -you can get away with not creating an issue: - - * Trivial fixes: issues can function as TODO lists, simple reminders that - something should be addressed. Sometimes, though, the work required to - fix is smaller than the work required to write the issue. - * Issues intended to be addressed by a PR may not actually be fixed or - may regress. - * Issues can span PRs (as PRs should be as small as possible, but no smaller). - * Issues help form an important basis for release notes. Any PR that addresses - a problem that should have release visibility, please do open an issue. +CHIP uses issues as simple problem descriptions or feature requests. In general, +all work contributed to the repository in the form of pull requests (PR) should +be under the auspices of some open issue. This may seem onerous and in some +cases duplicative, so consider these guidelines when deciding whether to you can +get away with not creating an issue: + +- Trivial fixes: issues can function as TODO lists, simple reminders that + something should be addressed. Sometimes, though, the work required to fix is + smaller than the work required to write the issue. +- Issues intended to be addressed by a PR may not actually be fixed or may + regress. +- Issues can span PRs (as PRs should be as small as possible, but no smaller). +- Issues help form an important basis for release notes. Any PR that addresses a + problem that should have release visibility, please do open an issue. ### Pull requests Pull requests should be small and address a single, specific change to the code -base. They should be easy to review, as a "yes, that's better". Refrain from +base. They should be easy to review, as a "yes, that's better". Refrain from requesting review until all PR checks have completed successfully, lest you tire your reviewers. PR Don'ts: - * Don't combine unrelated changes. E.g. if the PR addresses a bug in some - C code, an update to the top-level .gitignore doesn't belong. - * Don't make stacks. E.g. if a change in a component requires a new feature - or even a small tweak in one or more of its dependencies, each dependency - change belongs in its own separate PR. +- Don't combine unrelated changes. E.g. if the PR addresses a bug in some C + code, an update to the top-level .gitignore doesn't belong. +- Don't make stacks. E.g. if a change in a component requires a new feature or + even a small tweak in one or more of its dependencies, each dependency change + belongs in its own separate PR. ### Milestones In CHIP parlance, a milestone is simply an expected due date or release. -Date-based milestones start with an "M" and have the form M3, M3.2, M4, -etc. corresponding to the number of months since January 1, 2020, and generally -mean the last Friday of that month. E.g. M1 corresponds to EOB January 24, -2020. The Morrow milestone is a special milestone that means "unprioritized" or -"unscheduled" or "unscoped". +Date-based milestones start with an "M" and have the form M3, M3.2, M4, etc. +corresponding to the number of months since January 1, 2020, and generally mean +the last Friday of that month. E.g. M1 corresponds to EOB January 24, + +2020. The Morrow milestone is a special milestone that means "unprioritized" or + "unscheduled" or "unscoped". The form of the names of release-based milestone names are TBD, and may have flexible or changing dates. @@ -53,20 +54,20 @@ flexible or changing dates. Projects are collections of issues, pull requests, and notes intended to capture larger efforts that don't fit in issues, have multiple-subsystems involved, or -may span multiple milestones. We use projects 2 ways: +may span multiple milestones. We use projects 2 ways: -1. To track burn down on a larger task. When constructing such a project, it's -important to think in terms of something that will eventually have -an end, i.e. a definite scope. +1. To track burn down on a larger task. When constructing such a project, it's + important to think in terms of something that will eventually have an end, + i.e. a definite scope. 2. To categorize issues, denote broader efforts without a definite time scope. -These projects might reflect or show burndown or percent complete, but are mostly -used to view where effort is going. + These projects might reflect or show burndown or percent complete, but are + mostly used to view where effort is going. Issues can belong to any number of projects, but should generally only belong to one of the task-tracking projects (the first type). ### Branches, releases, and general development flow -Master should always be CHIPs best branch. Release branches, once cut, are -closed for any feature work. Software fixes for release branches must first -land on master unless demonstrably infeasible. +Master should always be CHIPs best branch. Release branches, once cut, are +closed for any feature work. Software fixes for release branches must first land +on master unless demonstrably infeasible. diff --git a/third_party/nlbuild-autotools/README.md b/third_party/nlbuild-autotools/README.md index 1cf48e64c148bc..520ceff92588f6 100644 --- a/third_party/nlbuild-autotools/README.md +++ b/third_party/nlbuild-autotools/README.md @@ -13,7 +13,7 @@ See "Getting Started" in repo/README.md. ### Subsequent Update -Assuming the project copy of nlbuild-autotools was created with git +Assuming the project copy of nlbuild-autotools was created with git subtree, a subsequent update can be accomplished with the following, replacing HEAD with a named, tagged version if the HEAD commit is not what is desired.