Merge pull request 'Add the guides and wiki pages for C++ and C# quality checks (MIL-007 task 6)' (#113) from mil-007-guides into mil-007-cpp-csharp-workflows
TirSystem/github-action: Publish wiki / publish-wiki (push) Skipped
TirSystem/github-action: Sync GitHub mirror metadata / sync-metadata (push) Skipped
Validate workflows / validate (pull_request) Successful in 20s

Reviewed-on: #113
This commit was merged in pull request #113.
This commit is contained in:
2026-10-11 10:26:29 +02:00
19 changed files with 783 additions and 14 deletions
+1
View File
@@ -458,6 +458,7 @@ Rows that say Implemented or Guides written exist today. The rest is planned and
| Onboard a repository, manage runners, diagnose failures | Guides written ([onboarding](guides/onboarding.md), [troubleshooting](guides/troubleshooting.md)); scoped delivery to the repositories of all four organizations verified (MIL-002) | | Onboard a repository, manage runners, diagnose failures | Guides written ([onboarding](guides/onboarding.md), [troubleshooting](guides/troubleshooting.md)); scoped delivery to the repositories of all four organizations verified (MIL-002) |
| Publish a repository wiki from `wiki/` (opt-in, delivered to every organization) | Implemented in `.gitea/scoped_workflows/publish-wiki.yml`, with offline tests; a pilot in a second repository publishes its wiki (MIL-006) | | Publish a repository wiki from `wiki/` (opt-in, delivered to every organization) | Implemented in `.gitea/scoped_workflows/publish-wiki.yml`, with offline tests; a pilot in a second repository publishes its wiki (MIL-006) |
| Shared quality checks (Python and shell) | Implemented as the reusable workflow `.gitea/workflows/quality-checks.yml`, with offline tests and a trial in a second organization; adopted in RepoFoundry ([guide](guides/quality-checks.md)) | | Shared quality checks (Python and shell) | Implemented as the reusable workflow `.gitea/workflows/quality-checks.yml`, with offline tests and a trial in a second organization; adopted in RepoFoundry ([guide](guides/quality-checks.md)) |
| Shared quality checks (C and C++, C#) | Implemented as the reusable workflows `.gitea/workflows/quality-checks-cpp.yml` and `.gitea/workflows/quality-checks-csharp.yml` with exact tool versions and offline tests; not yet used in another repository (MIL-007) ([C and C++ guide](guides/quality-checks-cpp.md), [C# guide](guides/quality-checks-csharp.md)) |
| Versioned release and publishing | Release process, changelog and upgrade guide defined; the release workflow exists and `v1.0.0` is released (MIL-004) ([guide](guides/upgrading.md)) | | Versioned release and publishing | Release process, changelog and upgrade guide defined; the release workflow exists and `v1.0.0` is released (MIL-004) ([guide](guides/upgrading.md)) |
## 📄 License ## 📄 License
+98
View File
@@ -0,0 +1,98 @@
# Reading C and C++ quality-check results
How a software engineer calls the shared C and C++ quality checks, reads a
failed run and makes it pass. The workflow format-checks and statically checks
the C and C++ files of a repository with clang tools at exact versions, changes
no file and needs no secret. Its contract is ADR-0008 in this repository.
## Calling the workflow
```yaml
name: Quality C++
on:
pull_request:
push:
branches: [ main ]
jobs:
quality:
permissions:
contents: read
uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1
with:
std: c++20
```
| Input | Default | Meaning |
| --- | --- | --- |
| `working-directory` | `.` | Directory, relative to the repository root, whose files are checked |
| `std` | `c++20` | C++ standard given to clang-tidy when there is no compile database, such as `c++17` or `gnu++20` |
| `compile-commands-dir` | empty | Directory, relative to the repository root, with a `compile_commands.json` that your pipeline built before the call; when set, clang-tidy uses it and ignores `std` |
| `clang-format-version` | `23.1.3` | Exact version of the clang-format package |
| `clang-tidy-version` | `22.1.8` | Exact version of the clang-tidy package |
| `tools-ref` | `v1` | Tag or branch of `TirSystem/github-action` from which the script `tools/quality-checks-cpp.sh` is fetched |
Reference the workflow at the major tag (`@v1`) or at an exact tag, never at
`main`. A call at an exact tag is pinned completely only when `tools-ref` names
the same tag. See the upgrade guide. The tool versions are exact: a newer
version of a tool is a new release of this repository, not a silent change.
## What the repository needs
- A `.clang-format` in the working directory or in a directory above it, up to
the top of the repository. Without one the run fails with `[configuration]`
and no tool runs.
- Optionally a `.clang-tidy` with the checks of the project (for example the
C++ Core Guidelines). Without one clang-tidy runs its default checks.
- For precise static checks, a compile database: build it first (for example
`cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON`) and pass
`compile-commands-dir: build`. The workflow does not build your project.
## What is checked
| Files | Tool | What it reports |
| --- | --- | --- |
| tracked `*.c`, `*.cc`, `*.cpp`, `*.cxx`, `*.h`, `*.hh`, `*.hpp`, `*.hxx` | `clang-format --dry-run -Werror` | formatting that differs from `.clang-format` |
| the same files | `clang-tidy` | findings of the checks of `.clang-tidy`; `*.c` files are checked as C17, the other files as the C++ standard of `std` |
Untracked files are not checked. A repository without these files passes with a
notice. There is no `cppcheck`: only an old version of it is available as a
package, and old tools are not run (ADR-0008).
## Reading a run
1. Open the status check on the pull request, then the job `quality-checks-cpp`.
2. Each tool has its own log group. Every tool runs even when an earlier one
failed, so one run shows all findings.
3. A tool ends with `PASS <tool>` or `FAIL <tool>`; the last line of a failed
run names them: `Quality checks failed: clang-format`.
4. A finding is written by the tool itself as `path:line:column: message`.
Paths are relative to `working-directory`.
## Typical failures and fixes
| Tool | What the log shows | Fix |
| --- | --- | --- |
| `clang-format` | `code should be clang-formatted [-Wclang-format-violations]` | Run `clang-format -i <file>` with the same version and commit |
| `clang-tidy` | `warning: ... [modernize-use-nullptr]` | Fix the code, or switch the check off in `.clang-tidy` with a reason |
| `clang-tidy` | `error: 'x.h' file not found` | Build the compile database and set `compile-commands-dir`, or add the include path to it |
To reproduce a run on your machine, install the same versions:
```bash
python3 -m venv .qc
.qc/bin/pip install clang-format==23.1.3 clang-tidy==22.1.8
git ls-files '*.cpp' '*.hpp' | xargs .qc/bin/clang-format --dry-run -Werror
```
## When the workflow itself fails
| Message | Cause | Fix |
| --- | --- | --- |
| `[configuration] std '<x>' is not a C++ standard` | `std` is not like `c++20` or `gnu++20` | Correct the input |
| `[configuration] ... is not an exact version` | A tool version is a range, a channel or empty | Give an exact version such as `23.1.3` |
| `[configuration] working-directory must be a relative path inside the repository.` | An absolute path or `..` | Use a path inside the repository |
| `[configuration] No .clang-format found` | The project has no style file | Add a `.clang-format` |
| `[configuration] compile-commands-dir '<x>' has no compile_commands.json` | The database was not built before the call | Build it in an earlier step of the job or in a job it depends on |
| The install step fails | PyPI or the runner network is unreachable | Re-run the job; see [troubleshooting.md](troubleshooting.md) |
+95
View File
@@ -0,0 +1,95 @@
# Reading C# quality-check results
How a software engineer calls the shared C# quality checks, reads a failed run
and makes it pass. The workflow checks the formatting and builds a solution or
project with warnings as errors, on an exact .NET SDK of version 10 or later,
changes no file and needs no secret. Its contract is ADR-0008 in this
repository.
## Calling the workflow
```yaml
name: Quality C#
on:
pull_request:
push:
branches: [ main ]
jobs:
quality:
permissions:
contents: read
uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1
with:
project: src/App.sln
```
| Input | Default | Meaning |
| --- | --- | --- |
| `working-directory` | `.` | Directory, relative to the repository root, whose files are checked |
| `project` | empty | Solution or project file, relative to `working-directory`; empty uses the single `*.sln` or `*.slnx`, else the single `*.csproj`, that is tracked there |
| `dotnet-sdk-version` | `10.0.401` | Exact version of the .NET SDK, 10 or later; a channel such as `10.0`, a range and a version below 10 are refused |
| `tools-ref` | `v1` | Tag or branch of `TirSystem/github-action` from which the script `tools/quality-checks-csharp.sh` is fetched |
Reference the workflow at the major tag (`@v1`) or at an exact tag, never at
`main`. A call at an exact tag is pinned completely only when `tools-ref` names
the same tag. See the upgrade guide. The SDK version is exact: raising the
default is a new release of this repository, not a silent change.
## What the repository needs
- A solution or project that builds with the SDK. Several candidates need the
`project` input; C# files with no solution or project fail with
`[configuration]`.
- The network: `dotnet format` and `dotnet build` restore the NuGet packages of
the project in the run.
- Rules in `.editorconfig` (and the analyzers the project enables, for example
with `AnalysisLevel` and `EnforceCodeStyleInBuild`) decide what a finding is.
## What is checked
| Files | Tool | What it reports |
| --- | --- | --- |
| the solution or project | `dotnet format --verify-no-changes` | formatting and style that differ from `.editorconfig` |
| the same | `dotnet build -warnaserror` | compiler and analyzer warnings, which fail the build |
Untracked files are not checked. A repository without `*.cs` files passes with
a notice. Project tests are not run.
## Reading a run
1. Open the status check on the pull request, then the job
`quality-checks-csharp`.
2. Each tool has its own log group. Both run even when the first failed, so one
run shows all findings.
3. A tool ends with `PASS <tool>` or `FAIL <tool>`; the last line of a failed
run names them:
`Quality checks failed: dotnet format --verify-no-changes`.
4. A finding is written by the tool itself as `path(line,column): CODE message`.
## Typical failures and fixes
| Tool | What the log shows | Fix |
| --- | --- | --- |
| `dotnet format --verify-no-changes` | `Program.cs(12,5): error WHITESPACE: Fix whitespace formatting` | Run `dotnet format <project>` and commit |
| `dotnet build -warnaserror` | `CS8602: Dereference of a possibly null reference` | Fix the code (null check), do not suppress the warning without a reason |
| `dotnet build -warnaserror` | `IDE0005: Using directive is unnecessary` | Remove the directive |
To reproduce a run on your machine, use the same SDK:
```bash
dotnet --version # 10.0.401
dotnet format src/App.sln --verify-no-changes
dotnet build src/App.sln -warnaserror
```
## When the workflow itself fails
| Message | Cause | Fix |
| --- | --- | --- |
| `[configuration] dotnet-sdk-version '<x>' is not an exact stable version 10 or later` | A channel, a range, a preview or a version below 10 | Give an exact version such as `10.0.401` |
| `[configuration] working-directory must be a relative path inside the repository.` | An absolute path or `..` | Use a path inside the repository |
| `[configuration] C# files exist but no solution or project was found` | The repository has `*.cs` files and no `*.sln`, `*.slnx` or `*.csproj` in the working directory | Add one, or set `working-directory` |
| `[configuration] Several solutions or projects were found` | More than one candidate | Set the input `project` |
| The install step fails | `dot.net` or the runner network is unreachable | Re-run the job; see [troubleshooting.md](troubleshooting.md) |
+3 -2
View File
@@ -16,8 +16,9 @@ repository, tags `vMAJOR.MINOR.PATCH` and a moving major tag `vMAJOR`.
A breaking release gets a new major version (`v2`), so a pipeline on `@v1` A breaking release gets a new major version (`v2`), so a pipeline on `@v1`
never receives it until you change the line yourself. never receives it until you change the line yourself.
The quality-checks workflow fetches its script at its input `tools-ref`, which The quality-checks workflows (`quality-checks.yml`, `quality-checks-cpp.yml` and
defaults to `v1`. To pin it completely, call it at an exact tag and set `quality-checks-csharp.yml`) fetch their script at their input `tools-ref`, which
defaults to `v1`. To pin one completely, call it at an exact tag and set
`tools-ref` to the same tag; otherwise the script follows the major tag. `tools-ref` to the same tag; otherwise the script follows the major tag.
The two scoped workflows (**Sync GitHub mirror metadata** and **Publish The two scoped workflows (**Sync GitHub mirror metadata** and **Publish
+10 -1
View File
@@ -98,7 +98,16 @@ def _write_sources(root: Path) -> None:
"## 📄 License\nMIT.\n", "## 📄 License\nMIT.\n",
encoding="utf-8", encoding="utf-8",
) )
for name in ("onboarding", "credentials", "troubleshooting", "quality-checks", "upgrading"): guide_names = (
"onboarding",
"credentials",
"troubleshooting",
"quality-checks",
"quality-checks-cpp",
"quality-checks-csharp",
"upgrading",
)
for name in guide_names:
(root / "guides" / f"{name}.md").write_text( (root / "guides" / f"{name}.md").write_text(
f"# {name.title()}\nBody.\n", encoding="utf-8" f"# {name.title()}\nBody.\n", encoding="utf-8"
) )
+7 -3
View File
@@ -44,6 +44,8 @@ PAGES: tuple[Page, ...] = (
Page("Credentials", "guides/credentials.md"), Page("Credentials", "guides/credentials.md"),
Page("Troubleshooting", "guides/troubleshooting.md"), Page("Troubleshooting", "guides/troubleshooting.md"),
Page("QualityChecksPythonShell", "guides/quality-checks.md"), Page("QualityChecksPythonShell", "guides/quality-checks.md"),
Page("QualityChecksCpp", "guides/quality-checks-cpp.md"),
Page("QualityChecksCSharp", "guides/quality-checks-csharp.md"),
Page("Upgrading", "guides/upgrading.md"), Page("Upgrading", "guides/upgrading.md"),
Page("Capabilities", "README.md", ("Capabilities",)), Page("Capabilities", "README.md", ("Capabilities",)),
) )
@@ -62,6 +64,8 @@ _PAGE_FOR_SOURCE = {
"guides/credentials.md": "Credentials", "guides/credentials.md": "Credentials",
"guides/troubleshooting.md": "Troubleshooting", "guides/troubleshooting.md": "Troubleshooting",
"guides/quality-checks.md": "QualityChecksPythonShell", "guides/quality-checks.md": "QualityChecksPythonShell",
"guides/quality-checks-cpp.md": "QualityChecksCpp",
"guides/quality-checks-csharp.md": "QualityChecksCSharp",
"guides/upgrading.md": "Upgrading", "guides/upgrading.md": "Upgrading",
} }
@@ -187,9 +191,9 @@ def render_page(page: Page, repo_root: Path = REPO_ROOT) -> str:
# Link text of the sidebar: English, then one list per translation code. # Link text of the sidebar: English, then one list per translation code.
SIDEBAR_TITLE = "TirSystem GitHub Actions" SIDEBAR_TITLE = "TirSystem GitHub Actions"
SIDEBAR_LABELS: dict[str, tuple[str, ...]] = { SIDEBAR_LABELS: dict[str, tuple[str, ...]] = {
"en": ("Home", "Onboarding", "Credentials", "Troubleshooting", "Quality checks (Python, shell)", "Upgrading", "Capabilities"), "en": ("Home", "Onboarding", "Credentials", "Troubleshooting", "Quality checks (Python, shell)", "Quality checks (C and C++)", "Quality checks (C#)", "Upgrading", "Capabilities"),
"da": ("Hjem", "Tilslutning", "Credentials", "Fejlfinding", "Kvalitetskontrol (Python, shell)", "Opgradering", "Kapabiliteter"), "da": ("Hjem", "Tilslutning", "Credentials", "Fejlfinding", "Kvalitetskontrol (Python, shell)", "Kvalitetskontrol (C og C++)", "Kvalitetskontrol (C#)", "Opgradering", "Kapabiliteter"),
"ms": ("Utama", "Menyertakan", "Kelayakan", "Diagnosis", "Semakan kualiti (Python, shell)", "Menaik taraf", "Keupayaan"), "ms": ("Utama", "Menyertakan", "Kelayakan", "Diagnosis", "Semakan kualiti (Python, shell)", "Semakan kualiti (C dan C++)", "Semakan kualiti (C#)", "Menaik taraf", "Keupayaan"),
} }
SIDEBAR_NAME = "_Sidebar.md" SIDEBAR_NAME = "_Sidebar.md"
+2 -1
View File
@@ -1,4 +1,4 @@
<!-- translation of Capabilities.md, source sha256 a8c03a001880 --> <!-- translation of Capabilities.md, source sha256 1f12a6b27e5d -->
> Dette er en oversættelse af [`Capabilities`](Capabilities). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres. > Dette er en oversættelse af [`Capabilities`](Capabilities). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
@@ -15,4 +15,5 @@ Rækker, der siger Implementeret eller Vejledninger er skrevet, findes i dag. Re
| Tilslutning af et repository, administration af runners, fejlfinding | Vejledninger er skrevet ([tilslutning](Onboarding.da), [fejlfinding](Troubleshooting.da)); scoped levering til alle fire organisationers repositories er verificeret (MIL-002) | | Tilslutning af et repository, administration af runners, fejlfinding | Vejledninger er skrevet ([tilslutning](Onboarding.da), [fejlfinding](Troubleshooting.da)); scoped levering til alle fire organisationers repositories er verificeret (MIL-002) |
| Publicering af et repositorys wiki fra `wiki/` (tilmelding, leveres til alle organisationer) | Implementeret i `.gitea/scoped_workflows/publish-wiki.yml`, med offline-tests; et pilotforsøg i et andet repository publicerer sin wiki (MIL-006) | | Publicering af et repositorys wiki fra `wiki/` (tilmelding, leveres til alle organisationer) | Implementeret i `.gitea/scoped_workflows/publish-wiki.yml`, med offline-tests; et pilotforsøg i et andet repository publicerer sin wiki (MIL-006) |
| Fælles kvalitetskontrol (Python og shell) | Implementeret som det genbrugelige workflow `.gitea/workflows/quality-checks.yml`, med offline-tests og et forsøg i en anden organisation; taget i brug i RepoFoundry ([vejledning](QualityChecksPythonShell.da)) | | Fælles kvalitetskontrol (Python og shell) | Implementeret som det genbrugelige workflow `.gitea/workflows/quality-checks.yml`, med offline-tests og et forsøg i en anden organisation; taget i brug i RepoFoundry ([vejledning](QualityChecksPythonShell.da)) |
| Fælles kvalitetskontrol (C og C++, C#) | Implementeret som de genbrugelige workflows `.gitea/workflows/quality-checks-cpp.yml` og `.gitea/workflows/quality-checks-csharp.yml` med præcise værktøjsversioner og offline-tests; endnu ikke brugt i et andet repository (MIL-007) ([vejledning til C og C++](QualityChecksCpp.da), [vejledning til C#](QualityChecksCSharp.da)) |
| Versioneret udgivelse og publicering | Udgivelsesproces, changelog og opgraderingsvejledning er defineret; udgivelsesworkflowet findes, og `v1.0.0` er udgivet (MIL-004) ([vejledning](Upgrading.da)) | | Versioneret udgivelse og publicering | Udgivelsesproces, changelog og opgraderingsvejledning er defineret; udgivelsesworkflowet findes, og `v1.0.0` er udgivet (MIL-004) ([vejledning](Upgrading.da)) |
+1
View File
@@ -15,4 +15,5 @@ Rows that say Implemented or Guides written exist today. The rest is planned and
| Onboard a repository, manage runners, diagnose failures | Guides written ([onboarding](Onboarding), [troubleshooting](Troubleshooting)); scoped delivery to the repositories of all four organizations verified (MIL-002) | | Onboard a repository, manage runners, diagnose failures | Guides written ([onboarding](Onboarding), [troubleshooting](Troubleshooting)); scoped delivery to the repositories of all four organizations verified (MIL-002) |
| Publish a repository wiki from `wiki/` (opt-in, delivered to every organization) | Implemented in `.gitea/scoped_workflows/publish-wiki.yml`, with offline tests; a pilot in a second repository publishes its wiki (MIL-006) | | Publish a repository wiki from `wiki/` (opt-in, delivered to every organization) | Implemented in `.gitea/scoped_workflows/publish-wiki.yml`, with offline tests; a pilot in a second repository publishes its wiki (MIL-006) |
| Shared quality checks (Python and shell) | Implemented as the reusable workflow `.gitea/workflows/quality-checks.yml`, with offline tests and a trial in a second organization; adopted in RepoFoundry ([guide](QualityChecksPythonShell)) | | Shared quality checks (Python and shell) | Implemented as the reusable workflow `.gitea/workflows/quality-checks.yml`, with offline tests and a trial in a second organization; adopted in RepoFoundry ([guide](QualityChecksPythonShell)) |
| Shared quality checks (C and C++, C#) | Implemented as the reusable workflows `.gitea/workflows/quality-checks-cpp.yml` and `.gitea/workflows/quality-checks-csharp.yml` with exact tool versions and offline tests; not yet used in another repository (MIL-007) ([C and C++ guide](QualityChecksCpp), [C# guide](QualityChecksCSharp)) |
| Versioned release and publishing | Release process, changelog and upgrade guide defined; the release workflow exists and `v1.0.0` is released (MIL-004) ([guide](Upgrading)) | | Versioned release and publishing | Release process, changelog and upgrade guide defined; the release workflow exists and `v1.0.0` is released (MIL-004) ([guide](Upgrading)) |
+2 -1
View File
@@ -1,4 +1,4 @@
<!-- translation of Capabilities.md, source sha256 a8c03a001880 --> <!-- translation of Capabilities.md, source sha256 1f12a6b27e5d -->
> Ini ialah terjemahan [`Capabilities`](Capabilities). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya. > Ini ialah terjemahan [`Capabilities`](Capabilities). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
@@ -15,4 +15,5 @@ Baris yang menyatakan Dilaksanakan atau Panduan telah ditulis wujud hari ini. Se
| Menyertakan repositori, mengurus runner, mendiagnosis kegagalan | Panduan telah ditulis ([menyertakan repositori](Onboarding.ms), [diagnosis](Troubleshooting.ms)); penghantaran scoped ke repositori keempat-empat organisasi telah disahkan (MIL-002) | | Menyertakan repositori, mengurus runner, mendiagnosis kegagalan | Panduan telah ditulis ([menyertakan repositori](Onboarding.ms), [diagnosis](Troubleshooting.ms)); penghantaran scoped ke repositori keempat-empat organisasi telah disahkan (MIL-002) |
| Menerbitkan wiki repositori daripada `wiki/` (pilih menyertai, dihantar ke setiap organisasi) | Dilaksanakan dalam `.gitea/scoped_workflows/publish-wiki.yml`, dengan ujian luar talian; satu juruterbang dalam repositori kedua menerbitkan wikinya (MIL-006) | | Menerbitkan wiki repositori daripada `wiki/` (pilih menyertai, dihantar ke setiap organisasi) | Dilaksanakan dalam `.gitea/scoped_workflows/publish-wiki.yml`, dengan ujian luar talian; satu juruterbang dalam repositori kedua menerbitkan wikinya (MIL-006) |
| Semakan kualiti bersama (Python dan shell) | Dilaksanakan sebagai aliran kerja boleh guna semula `.gitea/workflows/quality-checks.yml`, dengan ujian luar talian dan percubaan dalam organisasi kedua; digunakan dalam RepoFoundry ([panduan](QualityChecksPythonShell.ms)) | | Semakan kualiti bersama (Python dan shell) | Dilaksanakan sebagai aliran kerja boleh guna semula `.gitea/workflows/quality-checks.yml`, dengan ujian luar talian dan percubaan dalam organisasi kedua; digunakan dalam RepoFoundry ([panduan](QualityChecksPythonShell.ms)) |
| Semakan kualiti bersama (C dan C++, C#) | Dilaksanakan sebagai aliran kerja boleh guna semula `.gitea/workflows/quality-checks-cpp.yml` dan `.gitea/workflows/quality-checks-csharp.yml` dengan versi alat yang tepat dan ujian luar talian; belum digunakan dalam repositori lain (MIL-007) ([panduan C dan C++](QualityChecksCpp.ms), [panduan C#](QualityChecksCSharp.ms)) |
| Keluaran berversi dan penerbitan | Proses keluaran, changelog dan panduan naik taraf telah ditakrifkan; aliran kerja keluaran sudah ada dan `v1.0.0` telah dikeluarkan (MIL-004) ([panduan](Upgrading.ms)) | | Keluaran berversi dan penerbitan | Proses keluaran, changelog dan panduan naik taraf telah ditakrifkan; aliran kerja keluaran sudah ada dan `v1.0.0` telah dikeluarkan (MIL-004) ([panduan](Upgrading.ms)) |
+85
View File
@@ -0,0 +1,85 @@
<!-- translation of QualityChecksCSharp.md, source sha256 2baa0d48f712 -->
> Dette er en oversættelse af [`QualityChecksCSharp`](QualityChecksCSharp). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
[English](QualityChecksCSharp) | Dansk | [Bahasa Melayu](QualityChecksCSharp.ms)
# Aflæsning af resultater fra kvalitetskontrol af C#
Sådan kalder en softwareudvikler den fælles kvalitetskontrol af C#, aflæser en mislykket kørsel og får den til at bestå. Workflowet kontrollerer formateringen og bygger en solution eller et projekt med advarsler som fejl, på et præcist .NET SDK i version 10 eller nyere, ændrer ingen fil og kræver ingen secret. Dets kontrakt er ADR-0008 i dette repository.
## Kald af workflowet
```yaml
name: Quality C#
on:
pull_request:
push:
branches: [ main ]
jobs:
quality:
permissions:
contents: read
uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1
with:
project: src/App.sln
```
| Input | Standard | Betydning |
| --- | --- | --- |
| `working-directory` | `.` | Mappe, relativt til repositoryets rod, hvis filer kontrolleres |
| `project` | tom | Solution- eller projektfil, relativt til `working-directory`; tom bruger den eneste sporede `*.sln` eller `*.slnx`, ellers den eneste `*.csproj`, der er sporet dér |
| `dotnet-sdk-version` | `10.0.401` | Præcis version af .NET SDK, 10 eller nyere; en kanal som `10.0`, et interval og en version under 10 afvises |
| `tools-ref` | `v1` | Tag eller gren i `TirSystem/github-action`, hvorfra scriptet `tools/quality-checks-csharp.sh` hentes |
Henvis til workflowet ved major-tagget (`@v1`) eller et præcist tag, aldrig ved `main`. Et kald ved et præcist tag er kun fuldt fastlåst, når `tools-ref` angiver samme tag. Se opgraderingsvejledningen. SDK-versionen er præcis: at hæve standardværdien er en ny udgivelse af dette repository, ikke en stille ændring.
## Hvad repositoryet skal have
- En solution eller et projekt, der bygger med SDK'et. Flere kandidater kræver inputtet `project`; C#-filer uden solution eller projekt fejler med `[configuration]`.
- Netværk: `dotnet format` og `dotnet build` gendanner projektets NuGet-pakker i kørslen.
- Regler i `.editorconfig` (og de analysatorer, projektet slår til, for eksempel med `AnalysisLevel` og `EnforceCodeStyleInBuild`) afgør, hvad et fund er.
## Hvad der kontrolleres
| Filer | Værktøj | Hvad det melder |
| --- | --- | --- |
| solutionen eller projektet | `dotnet format --verify-no-changes` | formatering og stil, der afviger fra `.editorconfig` |
| det samme | `dotnet build -warnaserror` | compiler- og analysatoradvarsler, som får bygningen til at fejle |
Usporede filer kontrolleres ikke. Et repository uden `*.cs`-filer består med en bemærkning. Projektets tests køres ikke.
## Aflæsning af en kørsel
1. Åbn statuskontrollen på pull requesten og derefter jobbet `quality-checks-csharp`.
2. Hvert værktøj har sin egen logggruppe. Begge kører, selv om det første fejlede, så én kørsel viser alle fund.
3. Et værktøj ender med `PASS <værktøj>` eller `FAIL <værktøj>`; sidste linje i en mislykket kørsel nævner dem: `Quality checks failed: dotnet format --verify-no-changes`.
4. Et fund skrives af værktøjet selv som `path(line,column): CODE message`.
## Typiske fejl og rettelser
| Værktøj | Hvad loggen viser | Rettelse |
| --- | --- | --- |
| `dotnet format --verify-no-changes` | `Program.cs(12,5): error WHITESPACE: Fix whitespace formatting` | Kør `dotnet format <projekt>`, og commit |
| `dotnet build -warnaserror` | `CS8602: Dereference of a possibly null reference` | Ret koden (null-kontrol); undertryk ikke advarslen uden en begrundelse |
| `dotnet build -warnaserror` | `IDE0005: Using directive is unnecessary` | Fjern direktivet |
For at gentage en kørsel på din egen maskine skal du bruge samme SDK:
```bash
dotnet --version # 10.0.401
dotnet format src/App.sln --verify-no-changes
dotnet build src/App.sln -warnaserror
```
## Når workflowet selv fejler
| Meddelelse | Årsag | Rettelse |
| --- | --- | --- |
| `[configuration] dotnet-sdk-version '<x>' is not an exact stable version 10 or later` | En kanal, et interval, en preview eller en version under 10 | Angiv en præcis version som `10.0.401` |
| `[configuration] working-directory must be a relative path inside the repository.` | En absolut sti eller `..` | Brug en sti inde i repositoryet |
| `[configuration] C# files exist but no solution or project was found` | Repositoryet har `*.cs`-filer og ingen `*.sln`, `*.slnx` eller `*.csproj` i arbejdsmappen | Tilføj en, eller sæt `working-directory` |
| `[configuration] Several solutions or projects were found` | Mere end én kandidat | Sæt inputtet `project` |
| Installationstrinnet fejler | `dot.net` eller runnerens netværk kan ikke nås | Kør jobbet igen; se [troubleshooting.md](troubleshooting.md) |
+101
View File
@@ -0,0 +1,101 @@
<!-- Generated from guides/quality-checks-csharp.md by tools/build_wiki.py. Edit the source, not this page. -->
> This page is generated from [`guides/quality-checks-csharp.md`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/quality-checks-csharp.md). Changes made here are overwritten the next time the wiki is published.
English | [Dansk](QualityChecksCSharp.da) | [Bahasa Melayu](QualityChecksCSharp.ms)
# Reading C# quality-check results
How a software engineer calls the shared C# quality checks, reads a failed run
and makes it pass. The workflow checks the formatting and builds a solution or
project with warnings as errors, on an exact .NET SDK of version 10 or later,
changes no file and needs no secret. Its contract is ADR-0008 in this
repository.
## Calling the workflow
```yaml
name: Quality C#
on:
pull_request:
push:
branches: [ main ]
jobs:
quality:
permissions:
contents: read
uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1
with:
project: src/App.sln
```
| Input | Default | Meaning |
| --- | --- | --- |
| `working-directory` | `.` | Directory, relative to the repository root, whose files are checked |
| `project` | empty | Solution or project file, relative to `working-directory`; empty uses the single `*.sln` or `*.slnx`, else the single `*.csproj`, that is tracked there |
| `dotnet-sdk-version` | `10.0.401` | Exact version of the .NET SDK, 10 or later; a channel such as `10.0`, a range and a version below 10 are refused |
| `tools-ref` | `v1` | Tag or branch of `TirSystem/github-action` from which the script `tools/quality-checks-csharp.sh` is fetched |
Reference the workflow at the major tag (`@v1`) or at an exact tag, never at
`main`. A call at an exact tag is pinned completely only when `tools-ref` names
the same tag. See the upgrade guide. The SDK version is exact: raising the
default is a new release of this repository, not a silent change.
## What the repository needs
- A solution or project that builds with the SDK. Several candidates need the
`project` input; C# files with no solution or project fail with
`[configuration]`.
- The network: `dotnet format` and `dotnet build` restore the NuGet packages of
the project in the run.
- Rules in `.editorconfig` (and the analyzers the project enables, for example
with `AnalysisLevel` and `EnforceCodeStyleInBuild`) decide what a finding is.
## What is checked
| Files | Tool | What it reports |
| --- | --- | --- |
| the solution or project | `dotnet format --verify-no-changes` | formatting and style that differ from `.editorconfig` |
| the same | `dotnet build -warnaserror` | compiler and analyzer warnings, which fail the build |
Untracked files are not checked. A repository without `*.cs` files passes with
a notice. Project tests are not run.
## Reading a run
1. Open the status check on the pull request, then the job
`quality-checks-csharp`.
2. Each tool has its own log group. Both run even when the first failed, so one
run shows all findings.
3. A tool ends with `PASS <tool>` or `FAIL <tool>`; the last line of a failed
run names them:
`Quality checks failed: dotnet format --verify-no-changes`.
4. A finding is written by the tool itself as `path(line,column): CODE message`.
## Typical failures and fixes
| Tool | What the log shows | Fix |
| --- | --- | --- |
| `dotnet format --verify-no-changes` | `Program.cs(12,5): error WHITESPACE: Fix whitespace formatting` | Run `dotnet format <project>` and commit |
| `dotnet build -warnaserror` | `CS8602: Dereference of a possibly null reference` | Fix the code (null check), do not suppress the warning without a reason |
| `dotnet build -warnaserror` | `IDE0005: Using directive is unnecessary` | Remove the directive |
To reproduce a run on your machine, use the same SDK:
```bash
dotnet --version # 10.0.401
dotnet format src/App.sln --verify-no-changes
dotnet build src/App.sln -warnaserror
```
## When the workflow itself fails
| Message | Cause | Fix |
| --- | --- | --- |
| `[configuration] dotnet-sdk-version '<x>' is not an exact stable version 10 or later` | A channel, a range, a preview or a version below 10 | Give an exact version such as `10.0.401` |
| `[configuration] working-directory must be a relative path inside the repository.` | An absolute path or `..` | Use a path inside the repository |
| `[configuration] C# files exist but no solution or project was found` | The repository has `*.cs` files and no `*.sln`, `*.slnx` or `*.csproj` in the working directory | Add one, or set `working-directory` |
| `[configuration] Several solutions or projects were found` | More than one candidate | Set the input `project` |
| The install step fails | `dot.net` or the runner network is unreachable | Re-run the job; see [troubleshooting.md](Troubleshooting) |
+85
View File
@@ -0,0 +1,85 @@
<!-- translation of QualityChecksCSharp.md, source sha256 2baa0d48f712 -->
> Ini ialah terjemahan [`QualityChecksCSharp`](QualityChecksCSharp). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
[English](QualityChecksCSharp) | [Dansk](QualityChecksCSharp.da) | Bahasa Melayu
# Membaca keputusan semakan kualiti C#
Cara seorang jurutera perisian memanggil semakan kualiti bersama untuk C#, membaca larian yang gagal dan menjadikannya lulus. Aliran kerja ini menyemak pemformatan dan membina solution atau projek dengan amaran sebagai ralat, pada .NET SDK versi 10 atau lebih baharu yang tepat, tidak mengubah sebarang fail dan tidak memerlukan secret. Kontraknya ialah ADR-0008 dalam repositori ini.
## Memanggil aliran kerja
```yaml
name: Quality C#
on:
pull_request:
push:
branches: [ main ]
jobs:
quality:
permissions:
contents: read
uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1
with:
project: src/App.sln
```
| Input | Lalai | Maksud |
| --- | --- | --- |
| `working-directory` | `.` | Direktori, relatif kepada akar repositori, yang failnya disemak |
| `project` | kosong | Fail solution atau projek, relatif kepada `working-directory`; kosong menggunakan satu-satunya `*.sln` atau `*.slnx` yang dijejaki, jika tiada maka satu-satunya `*.csproj` yang dijejaki di situ |
| `dotnet-sdk-version` | `10.0.401` | Versi tepat .NET SDK, 10 atau lebih baharu; saluran seperti `10.0`, julat dan versi di bawah 10 ditolak |
| `tools-ref` | `v1` | Tag atau cabang `TirSystem/github-action` tempat skrip `tools/quality-checks-csharp.sh` diambil |
Rujuk aliran kerja pada tag major (`@v1`) atau pada tag tepat, jangan sekali-kali pada `main`. Panggilan pada tag tepat hanya disematkan sepenuhnya apabila `tools-ref` menamakan tag yang sama. Lihat panduan naik taraf. Versi SDK adalah tepat: menaikkan nilai lalai ialah keluaran baharu repositori ini, bukan perubahan senyap.
## Apa yang diperlukan oleh repositori
- Satu solution atau projek yang boleh dibina dengan SDK. Beberapa calon memerlukan input `project`; fail C# tanpa solution atau projek gagal dengan `[configuration]`.
- Rangkaian: `dotnet format` dan `dotnet build` memulihkan pakej NuGet projek dalam larian.
- Peraturan dalam `.editorconfig` (dan penganalisis yang diaktifkan projek, contohnya dengan `AnalysisLevel` dan `EnforceCodeStyleInBuild`) menentukan apa yang dikira sebagai dapatan.
## Apa yang disemak
| Fail | Alat | Apa yang dilaporkan |
| --- | --- | --- |
| solution atau projek | `dotnet format --verify-no-changes` | pemformatan dan gaya yang berbeza daripada `.editorconfig` |
| yang sama | `dotnet build -warnaserror` | amaran pengkompil dan penganalisis, yang menggagalkan binaan |
Fail yang tidak dijejaki tidak disemak. Repositori tanpa fail `*.cs` lulus dengan satu notis. Ujian projek tidak dijalankan.
## Membaca satu larian
1. Buka semakan status pada pull request, kemudian kerja `quality-checks-csharp`.
2. Setiap alat mempunyai kumpulan lognya sendiri. Kedua-duanya dijalankan walaupun yang pertama gagal, jadi satu larian menunjukkan semua dapatan.
3. Satu alat berakhir dengan `PASS <alat>` atau `FAIL <alat>`; baris terakhir larian yang gagal menamakannya: `Quality checks failed: dotnet format --verify-no-changes`.
4. Satu dapatan ditulis oleh alat itu sendiri sebagai `path(line,column): CODE message`.
## Kegagalan biasa dan pembetulan
| Alat | Apa yang ditunjukkan log | Pembetulan |
| --- | --- | --- |
| `dotnet format --verify-no-changes` | `Program.cs(12,5): error WHITESPACE: Fix whitespace formatting` | Jalankan `dotnet format <projek>` dan commit |
| `dotnet build -warnaserror` | `CS8602: Dereference of a possibly null reference` | Betulkan kod (semakan null); jangan tindas amaran tanpa sebab |
| `dotnet build -warnaserror` | `IDE0005: Using directive is unnecessary` | Buang arahan itu |
Untuk mengulangi satu larian pada mesin anda, gunakan SDK yang sama:
```bash
dotnet --version # 10.0.401
dotnet format src/App.sln --verify-no-changes
dotnet build src/App.sln -warnaserror
```
## Apabila aliran kerja itu sendiri gagal
| Mesej | Punca | Pembetulan |
| --- | --- | --- |
| `[configuration] dotnet-sdk-version '<x>' is not an exact stable version 10 or later` | Saluran, julat, pratonton atau versi di bawah 10 | Berikan versi tepat seperti `10.0.401` |
| `[configuration] working-directory must be a relative path inside the repository.` | Laluan mutlak atau `..` | Gunakan laluan di dalam repositori |
| `[configuration] C# files exist but no solution or project was found` | Repositori mempunyai fail `*.cs` tetapi tiada `*.sln`, `*.slnx` atau `*.csproj` dalam direktori kerja | Tambah satu, atau tetapkan `working-directory` |
| `[configuration] Several solutions or projects were found` | Lebih daripada satu calon | Tetapkan input `project` |
| Langkah pemasangan gagal | `dot.net` atau rangkaian runner tidak dapat dicapai | Jalankan semula kerja; lihat [troubleshooting.md](troubleshooting.md) |
+88
View File
@@ -0,0 +1,88 @@
<!-- translation of QualityChecksCpp.md, source sha256 f54f7f7dc713 -->
> Dette er en oversættelse af [`QualityChecksCpp`](QualityChecksCpp). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
[English](QualityChecksCpp) | Dansk | [Bahasa Melayu](QualityChecksCpp.ms)
# Aflæsning af resultater fra kvalitetskontrol af C og C++
Sådan kalder en softwareudvikler den fælles kvalitetskontrol af C og C++, aflæser en mislykket kørsel og får den til at bestå. Workflowet formatkontrollerer og analyserer statisk repositoryets C- og C++-filer med clang-værktøjer i præcise versioner, ændrer ingen fil og kræver ingen secret. Dets kontrakt er ADR-0008 i dette repository.
## Kald af workflowet
```yaml
name: Quality C++
on:
pull_request:
push:
branches: [ main ]
jobs:
quality:
permissions:
contents: read
uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1
with:
std: c++20
```
| Input | Standard | Betydning |
| --- | --- | --- |
| `working-directory` | `.` | Mappe, relativt til repositoryets rod, hvis filer kontrolleres |
| `std` | `c++20` | C++-standard, som clang-tidy får, når der ikke er en compile-database, for eksempel `c++17` eller `gnu++20` |
| `compile-commands-dir` | tom | Mappe, relativt til repositoryets rod, med en `compile_commands.json`, som din pipeline har bygget før kaldet; når den er sat, bruger clang-tidy den og ignorerer `std` |
| `clang-format-version` | `23.1.3` | Præcis version af pakken clang-format |
| `clang-tidy-version` | `22.1.8` | Præcis version af pakken clang-tidy |
| `tools-ref` | `v1` | Tag eller gren i `TirSystem/github-action`, hvorfra scriptet `tools/quality-checks-cpp.sh` hentes |
Henvis til workflowet ved major-tagget (`@v1`) eller et præcist tag, aldrig ved `main`. Et kald ved et præcist tag er kun fuldt fastlåst, når `tools-ref` angiver samme tag. Se opgraderingsvejledningen. Værktøjsversionerne er præcise: en nyere version af et værktøj er en ny udgivelse af dette repository, ikke en stille ændring.
## Hvad repositoryet skal have
- En `.clang-format` i arbejdsmappen eller i en mappe over den, op til repositoryets rod. Uden en fejler kørslen med `[configuration]`, og intet værktøj kører.
- Eventuelt en `.clang-tidy` med projektets kontroller (for eksempel C++ Core Guidelines). Uden en kører clang-tidy sine standardkontroller.
- For præcise statiske kontroller en compile-database: byg den først (for eksempel `cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON`) og angiv `compile-commands-dir: build`. Workflowet bygger ikke dit projekt.
## Hvad der kontrolleres
| Filer | Værktøj | Hvad det melder |
| --- | --- | --- |
| sporede `*.c`, `*.cc`, `*.cpp`, `*.cxx`, `*.h`, `*.hh`, `*.hpp`, `*.hxx` | `clang-format --dry-run -Werror` | formatering, der afviger fra `.clang-format` |
| de samme filer | `clang-tidy` | fund fra kontrollerne i `.clang-tidy`; `*.c`-filer kontrolleres som C17, de øvrige filer som C++-standarden i `std` |
Usporede filer kontrolleres ikke. Et repository uden disse filer består med en bemærkning. Der er ingen `cppcheck`: kun en gammel version findes som pakke, og gamle værktøjer køres ikke (ADR-0008).
## Aflæsning af en kørsel
1. Åbn statuskontrollen på pull requesten og derefter jobbet `quality-checks-cpp`.
2. Hvert værktøj har sin egen logggruppe. Alle værktøjer kører, selv om et tidligere fejlede, så én kørsel viser alle fund.
3. Et værktøj ender med `PASS <værktøj>` eller `FAIL <værktøj>`; sidste linje i en mislykket kørsel nævner dem: `Quality checks failed: clang-format`.
4. Et fund skrives af værktøjet selv som `path:line:column: message`. Stier er relative til `working-directory`.
## Typiske fejl og rettelser
| Værktøj | Hvad loggen viser | Rettelse |
| --- | --- | --- |
| `clang-format` | `code should be clang-formatted [-Wclang-format-violations]` | Kør `clang-format -i <fil>` med samme version, og commit |
| `clang-tidy` | `warning: ... [modernize-use-nullptr]` | Ret koden, eller slå kontrollen fra i `.clang-tidy` med en begrundelse |
| `clang-tidy` | `error: 'x.h' file not found` | Byg compile-databasen og sæt `compile-commands-dir`, eller tilføj include-stien til den |
For at gentage en kørsel på din egen maskine skal du installere de samme versioner:
```bash
python3 -m venv .qc
.qc/bin/pip install clang-format==23.1.3 clang-tidy==22.1.8
git ls-files '*.cpp' '*.hpp' | xargs .qc/bin/clang-format --dry-run -Werror
```
## Når workflowet selv fejler
| Meddelelse | Årsag | Rettelse |
| --- | --- | --- |
| `[configuration] std '<x>' is not a C++ standard` | `std` er ikke som `c++20` eller `gnu++20` | Ret inputtet |
| `[configuration] ... is not an exact version` | En værktøjsversion er et interval, en kanal eller tom | Angiv en præcis version som `23.1.3` |
| `[configuration] working-directory must be a relative path inside the repository.` | En absolut sti eller `..` | Brug en sti inde i repositoryet |
| `[configuration] No .clang-format found` | Projektet har ingen stilfil | Tilføj en `.clang-format` |
| `[configuration] compile-commands-dir '<x>' has no compile_commands.json` | Databasen blev ikke bygget før kaldet | Byg den i et tidligere trin i jobbet eller i et job, det afhænger af |
| Installationstrinnet fejler | PyPI eller runnerens netværk kan ikke nås | Kør jobbet igen; se [troubleshooting.md](troubleshooting.md) |
+104
View File
@@ -0,0 +1,104 @@
<!-- Generated from guides/quality-checks-cpp.md by tools/build_wiki.py. Edit the source, not this page. -->
> This page is generated from [`guides/quality-checks-cpp.md`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/quality-checks-cpp.md). Changes made here are overwritten the next time the wiki is published.
English | [Dansk](QualityChecksCpp.da) | [Bahasa Melayu](QualityChecksCpp.ms)
# Reading C and C++ quality-check results
How a software engineer calls the shared C and C++ quality checks, reads a
failed run and makes it pass. The workflow format-checks and statically checks
the C and C++ files of a repository with clang tools at exact versions, changes
no file and needs no secret. Its contract is ADR-0008 in this repository.
## Calling the workflow
```yaml
name: Quality C++
on:
pull_request:
push:
branches: [ main ]
jobs:
quality:
permissions:
contents: read
uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1
with:
std: c++20
```
| Input | Default | Meaning |
| --- | --- | --- |
| `working-directory` | `.` | Directory, relative to the repository root, whose files are checked |
| `std` | `c++20` | C++ standard given to clang-tidy when there is no compile database, such as `c++17` or `gnu++20` |
| `compile-commands-dir` | empty | Directory, relative to the repository root, with a `compile_commands.json` that your pipeline built before the call; when set, clang-tidy uses it and ignores `std` |
| `clang-format-version` | `23.1.3` | Exact version of the clang-format package |
| `clang-tidy-version` | `22.1.8` | Exact version of the clang-tidy package |
| `tools-ref` | `v1` | Tag or branch of `TirSystem/github-action` from which the script `tools/quality-checks-cpp.sh` is fetched |
Reference the workflow at the major tag (`@v1`) or at an exact tag, never at
`main`. A call at an exact tag is pinned completely only when `tools-ref` names
the same tag. See the upgrade guide. The tool versions are exact: a newer
version of a tool is a new release of this repository, not a silent change.
## What the repository needs
- A `.clang-format` in the working directory or in a directory above it, up to
the top of the repository. Without one the run fails with `[configuration]`
and no tool runs.
- Optionally a `.clang-tidy` with the checks of the project (for example the
C++ Core Guidelines). Without one clang-tidy runs its default checks.
- For precise static checks, a compile database: build it first (for example
`cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON`) and pass
`compile-commands-dir: build`. The workflow does not build your project.
## What is checked
| Files | Tool | What it reports |
| --- | --- | --- |
| tracked `*.c`, `*.cc`, `*.cpp`, `*.cxx`, `*.h`, `*.hh`, `*.hpp`, `*.hxx` | `clang-format --dry-run -Werror` | formatting that differs from `.clang-format` |
| the same files | `clang-tidy` | findings of the checks of `.clang-tidy`; `*.c` files are checked as C17, the other files as the C++ standard of `std` |
Untracked files are not checked. A repository without these files passes with a
notice. There is no `cppcheck`: only an old version of it is available as a
package, and old tools are not run (ADR-0008).
## Reading a run
1. Open the status check on the pull request, then the job `quality-checks-cpp`.
2. Each tool has its own log group. Every tool runs even when an earlier one
failed, so one run shows all findings.
3. A tool ends with `PASS <tool>` or `FAIL <tool>`; the last line of a failed
run names them: `Quality checks failed: clang-format`.
4. A finding is written by the tool itself as `path:line:column: message`.
Paths are relative to `working-directory`.
## Typical failures and fixes
| Tool | What the log shows | Fix |
| --- | --- | --- |
| `clang-format` | `code should be clang-formatted [-Wclang-format-violations]` | Run `clang-format -i <file>` with the same version and commit |
| `clang-tidy` | `warning: ... [modernize-use-nullptr]` | Fix the code, or switch the check off in `.clang-tidy` with a reason |
| `clang-tidy` | `error: 'x.h' file not found` | Build the compile database and set `compile-commands-dir`, or add the include path to it |
To reproduce a run on your machine, install the same versions:
```bash
python3 -m venv .qc
.qc/bin/pip install clang-format==23.1.3 clang-tidy==22.1.8
git ls-files '*.cpp' '*.hpp' | xargs .qc/bin/clang-format --dry-run -Werror
```
## When the workflow itself fails
| Message | Cause | Fix |
| --- | --- | --- |
| `[configuration] std '<x>' is not a C++ standard` | `std` is not like `c++20` or `gnu++20` | Correct the input |
| `[configuration] ... is not an exact version` | A tool version is a range, a channel or empty | Give an exact version such as `23.1.3` |
| `[configuration] working-directory must be a relative path inside the repository.` | An absolute path or `..` | Use a path inside the repository |
| `[configuration] No .clang-format found` | The project has no style file | Add a `.clang-format` |
| `[configuration] compile-commands-dir '<x>' has no compile_commands.json` | The database was not built before the call | Build it in an earlier step of the job or in a job it depends on |
| The install step fails | PyPI or the runner network is unreachable | Re-run the job; see [troubleshooting.md](Troubleshooting) |
+88
View File
@@ -0,0 +1,88 @@
<!-- translation of QualityChecksCpp.md, source sha256 f54f7f7dc713 -->
> Ini ialah terjemahan [`QualityChecksCpp`](QualityChecksCpp). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
[English](QualityChecksCpp) | [Dansk](QualityChecksCpp.da) | Bahasa Melayu
# Membaca keputusan semakan kualiti C dan C++
Cara seorang jurutera perisian memanggil semakan kualiti bersama untuk C dan C++, membaca larian yang gagal dan menjadikannya lulus. Aliran kerja ini menyemak format dan menganalisis secara statik fail C dan C++ sesebuah repositori dengan alat clang pada versi yang tepat, tidak mengubah sebarang fail dan tidak memerlukan secret. Kontraknya ialah ADR-0008 dalam repositori ini.
## Memanggil aliran kerja
```yaml
name: Quality C++
on:
pull_request:
push:
branches: [ main ]
jobs:
quality:
permissions:
contents: read
uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1
with:
std: c++20
```
| Input | Lalai | Maksud |
| --- | --- | --- |
| `working-directory` | `.` | Direktori, relatif kepada akar repositori, yang failnya disemak |
| `std` | `c++20` | Piawaian C++ yang diberikan kepada clang-tidy apabila tiada pangkalan data kompilasi, seperti `c++17` atau `gnu++20` |
| `compile-commands-dir` | kosong | Direktori, relatif kepada akar repositori, dengan `compile_commands.json` yang dibina oleh saluran paip anda sebelum panggilan; apabila ditetapkan, clang-tidy menggunakannya dan mengabaikan `std` |
| `clang-format-version` | `23.1.3` | Versi tepat pakej clang-format |
| `clang-tidy-version` | `22.1.8` | Versi tepat pakej clang-tidy |
| `tools-ref` | `v1` | Tag atau cabang `TirSystem/github-action` tempat skrip `tools/quality-checks-cpp.sh` diambil |
Rujuk aliran kerja pada tag major (`@v1`) atau pada tag tepat, jangan sekali-kali pada `main`. Panggilan pada tag tepat hanya disematkan sepenuhnya apabila `tools-ref` menamakan tag yang sama. Lihat panduan naik taraf. Versi alat adalah tepat: versi alat yang lebih baharu ialah keluaran baharu repositori ini, bukan perubahan senyap.
## Apa yang diperlukan oleh repositori
- Satu `.clang-format` dalam direktori kerja atau dalam direktori di atasnya, sehingga akar repositori. Tanpanya larian gagal dengan `[configuration]` dan tiada alat dijalankan.
- Pilihan: satu `.clang-tidy` dengan semakan projek (contohnya C++ Core Guidelines). Tanpanya clang-tidy menjalankan semakan lalainya.
- Untuk semakan statik yang tepat, satu pangkalan data kompilasi: bina dahulu (contohnya `cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON`) dan berikan `compile-commands-dir: build`. Aliran kerja tidak membina projek anda.
## Apa yang disemak
| Fail | Alat | Apa yang dilaporkan |
| --- | --- | --- |
| `*.c`, `*.cc`, `*.cpp`, `*.cxx`, `*.h`, `*.hh`, `*.hpp`, `*.hxx` yang dijejaki | `clang-format --dry-run -Werror` | pemformatan yang berbeza daripada `.clang-format` |
| fail yang sama | `clang-tidy` | dapatan semakan dalam `.clang-tidy`; fail `*.c` disemak sebagai C17, fail lain sebagai piawaian C++ dalam `std` |
Fail yang tidak dijejaki tidak disemak. Repositori tanpa fail ini lulus dengan satu notis. Tiada `cppcheck`: hanya versi lama tersedia sebagai pakej, dan alat lama tidak dijalankan (ADR-0008).
## Membaca satu larian
1. Buka semakan status pada pull request, kemudian kerja `quality-checks-cpp`.
2. Setiap alat mempunyai kumpulan lognya sendiri. Setiap alat dijalankan walaupun yang terdahulu gagal, jadi satu larian menunjukkan semua dapatan.
3. Satu alat berakhir dengan `PASS <alat>` atau `FAIL <alat>`; baris terakhir larian yang gagal menamakannya: `Quality checks failed: clang-format`.
4. Satu dapatan ditulis oleh alat itu sendiri sebagai `path:line:column: message`. Laluan relatif kepada `working-directory`.
## Kegagalan biasa dan pembetulan
| Alat | Apa yang ditunjukkan log | Pembetulan |
| --- | --- | --- |
| `clang-format` | `code should be clang-formatted [-Wclang-format-violations]` | Jalankan `clang-format -i <fail>` dengan versi yang sama dan commit |
| `clang-tidy` | `warning: ... [modernize-use-nullptr]` | Betulkan kod, atau matikan semakan itu dalam `.clang-tidy` dengan sebab |
| `clang-tidy` | `error: 'x.h' file not found` | Bina pangkalan data kompilasi dan tetapkan `compile-commands-dir`, atau tambah laluan include kepadanya |
Untuk mengulangi satu larian pada mesin anda, pasang versi yang sama:
```bash
python3 -m venv .qc
.qc/bin/pip install clang-format==23.1.3 clang-tidy==22.1.8
git ls-files '*.cpp' '*.hpp' | xargs .qc/bin/clang-format --dry-run -Werror
```
## Apabila aliran kerja itu sendiri gagal
| Mesej | Punca | Pembetulan |
| --- | --- | --- |
| `[configuration] std '<x>' is not a C++ standard` | `std` bukan seperti `c++20` atau `gnu++20` | Betulkan input |
| `[configuration] ... is not an exact version` | Versi alat ialah julat, saluran atau kosong | Berikan versi tepat seperti `23.1.3` |
| `[configuration] working-directory must be a relative path inside the repository.` | Laluan mutlak atau `..` | Gunakan laluan di dalam repositori |
| `[configuration] No .clang-format found` | Projek tiada fail gaya | Tambah `.clang-format` |
| `[configuration] compile-commands-dir '<x>' has no compile_commands.json` | Pangkalan data tidak dibina sebelum panggilan | Bina dalam langkah terdahulu kerja itu atau dalam kerja yang menjadi tanggungannya |
| Langkah pemasangan gagal | PyPI atau rangkaian runner tidak dapat dicapai | Jalankan semula kerja; lihat [troubleshooting.md](troubleshooting.md) |
+2 -2
View File
@@ -1,4 +1,4 @@
<!-- translation of Upgrading.md, source sha256 3f119a1ab12d --> <!-- translation of Upgrading.md, source sha256 7fba937279b1 -->
> Dette er en oversættelse af [`Upgrading`](Upgrading). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres. > Dette er en oversættelse af [`Upgrading`](Upgrading). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
@@ -18,7 +18,7 @@ Sådan tager en softwareudvikler en ny udgivelse af de fælles workflows i brug
En udgivelse, der bryder kompatibiliteten, får en ny major-version (`v2`), så en pipeline på `@v1` aldrig modtager den, før du selv ændrer linjen. En udgivelse, der bryder kompatibiliteten, får en ny major-version (`v2`), så en pipeline på `@v1` aldrig modtager den, før du selv ændrer linjen.
Kvalitetskontrol-workflowet henter sit script ved sit input `tools-ref`, som som standard er `v1`. For at fastlåse det helt skal du kalde det ved et præcist tag og sætte `tools-ref` til samme tag; ellers følger scriptet major-tagget. Kvalitetskontrol-workflowene (`quality-checks.yml`, `quality-checks-cpp.yml` og `quality-checks-csharp.yml`) henter deres script ved deres input `tools-ref`, som som standard er `v1`. For at fastlåse et helt skal du kalde det ved et præcist tag og sætte `tools-ref` til samme tag; ellers følger scriptet major-tagget.
De to scoped workflows (**Sync GitHub mirror metadata** og **Publish wiki**) leveres af instansen og står ikke i dine `uses:`-linjer; du kan ikke fastlåse dem, men de henter deres scripts ved major-tagget. De to scoped workflows (**Sync GitHub mirror metadata** og **Publish wiki**) leveres af instansen og står ikke i dine `uses:`-linjer; du kan ikke fastlåse dem, men de henter deres scripts ved major-tagget.
+3 -2
View File
@@ -22,8 +22,9 @@ repository, tags `vMAJOR.MINOR.PATCH` and a moving major tag `vMAJOR`.
A breaking release gets a new major version (`v2`), so a pipeline on `@v1` A breaking release gets a new major version (`v2`), so a pipeline on `@v1`
never receives it until you change the line yourself. never receives it until you change the line yourself.
The quality-checks workflow fetches its script at its input `tools-ref`, which The quality-checks workflows (`quality-checks.yml`, `quality-checks-cpp.yml` and
defaults to `v1`. To pin it completely, call it at an exact tag and set `quality-checks-csharp.yml`) fetch their script at their input `tools-ref`, which
defaults to `v1`. To pin one completely, call it at an exact tag and set
`tools-ref` to the same tag; otherwise the script follows the major tag. `tools-ref` to the same tag; otherwise the script follows the major tag.
The two scoped workflows (**Sync GitHub mirror metadata** and **Publish The two scoped workflows (**Sync GitHub mirror metadata** and **Publish
+2 -2
View File
@@ -1,4 +1,4 @@
<!-- translation of Upgrading.md, source sha256 3f119a1ab12d --> <!-- translation of Upgrading.md, source sha256 7fba937279b1 -->
> Ini ialah terjemahan [`Upgrading`](Upgrading). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya. > Ini ialah terjemahan [`Upgrading`](Upgrading). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
@@ -18,7 +18,7 @@ Cara seorang jurutera perisian menerima keluaran baharu aliran kerja bersama den
Keluaran yang memecahkan keserasian mendapat versi major baharu (`v2`), jadi saluran paip pada `@v1` tidak menerimanya sehingga anda sendiri menukar baris itu. Keluaran yang memecahkan keserasian mendapat versi major baharu (`v2`), jadi saluran paip pada `@v1` tidak menerimanya sehingga anda sendiri menukar baris itu.
Aliran kerja semakan kualiti mengambil skripnya pada inputnya `tools-ref`, yang lalai ialah `v1`. Untuk menyematkannya sepenuhnya, panggil pada tag tepat dan tetapkan `tools-ref` kepada tag yang sama; jika tidak, skrip mengikuti tag major. Aliran kerja semakan kualiti (`quality-checks.yml`, `quality-checks-cpp.yml` dan `quality-checks-csharp.yml`) mengambil skripnya pada inputnya `tools-ref`, yang lalai ialah `v1`. Untuk menyematkan satu sepenuhnya, panggil pada tag tepat dan tetapkan `tools-ref` kepada tag yang sama; jika tidak, skrip mengikuti tag major.
Dua aliran kerja scoped (**Sync GitHub mirror metadata** dan **Publish wiki**) dihantar oleh instans dan tidak terdapat dalam baris `uses:` anda; anda tidak boleh menyematkannya, tetapi ia mengambil skripnya pada tag major. Dua aliran kerja scoped (**Sync GitHub mirror metadata** dan **Publish wiki**) dihantar oleh instans dan tidak terdapat dalam baris `uses:` anda; anda tidak boleh menyematkannya, tetapi ia mengambil skripnya pada tag major.
+6
View File
@@ -9,6 +9,8 @@
- [Credentials](Credentials) - [Credentials](Credentials)
- [Troubleshooting](Troubleshooting) - [Troubleshooting](Troubleshooting)
- [Quality checks (Python, shell)](QualityChecksPythonShell) - [Quality checks (Python, shell)](QualityChecksPythonShell)
- [Quality checks (C and C++)](QualityChecksCpp)
- [Quality checks (C#)](QualityChecksCSharp)
- [Upgrading](Upgrading) - [Upgrading](Upgrading)
- [Capabilities](Capabilities) - [Capabilities](Capabilities)
@@ -19,6 +21,8 @@
- [Credentials](Credentials.da) - [Credentials](Credentials.da)
- [Fejlfinding](Troubleshooting.da) - [Fejlfinding](Troubleshooting.da)
- [Kvalitetskontrol (Python, shell)](QualityChecksPythonShell.da) - [Kvalitetskontrol (Python, shell)](QualityChecksPythonShell.da)
- [Kvalitetskontrol (C og C++)](QualityChecksCpp.da)
- [Kvalitetskontrol (C#)](QualityChecksCSharp.da)
- [Opgradering](Upgrading.da) - [Opgradering](Upgrading.da)
- [Kapabiliteter](Capabilities.da) - [Kapabiliteter](Capabilities.da)
@@ -29,5 +33,7 @@
- [Kelayakan](Credentials.ms) - [Kelayakan](Credentials.ms)
- [Diagnosis](Troubleshooting.ms) - [Diagnosis](Troubleshooting.ms)
- [Semakan kualiti (Python, shell)](QualityChecksPythonShell.ms) - [Semakan kualiti (Python, shell)](QualityChecksPythonShell.ms)
- [Semakan kualiti (C dan C++)](QualityChecksCpp.ms)
- [Semakan kualiti (C#)](QualityChecksCSharp.ms)
- [Menaik taraf](Upgrading.ms) - [Menaik taraf](Upgrading.ms)
- [Keupayaan](Capabilities.ms) - [Keupayaan](Capabilities.ms)