Add the reusable quality-check workflows for C++ and C# (MIL-007 tasks 4 and 5) #110

Open
Tirsvad wants to merge 6 commits from mil-007-cpp-csharp-workflows into main
28 changed files with 2321 additions and 24 deletions
+72
View File
@@ -0,0 +1,72 @@
name: Quality checks C++
# Reusable workflow (ADR-0008). A repository calls it with
#
# jobs:
# quality:
# uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1
#
# It checks the C and C++ files of the repository with clang-format and
# clang-tidy at exact versions, changes no file and needs no secret. The
# repository needs a .clang-format; a .clang-tidy and a compile database
# (compile-commands-dir) are optional.
on:
workflow_call:
inputs:
working-directory:
description: "Directory, relative to the repository root, whose files are checked"
type: string
default: "."
std:
description: "C++ standard for clang-tidy when no compile database is given, such as c++20"
type: string
default: "c++20"
compile-commands-dir:
description: "Directory with a compile_commands.json built by the caller before the call; empty uses the std input"
type: string
default: ""
clang-format-version:
description: "Exact version of the clang-format package"
type: string
default: "23.1.3"
clang-tidy-version:
description: "Exact version of the clang-tidy package"
type: string
default: "22.1.8"
tools-ref:
description: "Tag or branch of TirSystem/github-action whose tools/quality-checks-cpp.sh is run; pin it to the exact tag together with the workflow"
type: string
default: "v1"
jobs:
quality-checks-cpp:
permissions:
contents: read
runs-on: ubuntu-latest
timeout-minutes: 15
env:
WORKING_DIRECTORY: ${{ inputs.working-directory }}
STD: ${{ inputs.std }}
COMPILE_COMMANDS_DIR: ${{ inputs.compile-commands-dir }}
CLANG_FORMAT_VERSION: ${{ inputs.clang-format-version }}
CLANG_TIDY_VERSION: ${{ inputs.clang-tidy-version }}
QC_VENV: /tmp/quality-tools
steps:
- name: Check out the repository
uses: actions/checkout@v4.2.2
- name: Fetch the shared script
uses: actions/checkout@v4.2.2
with:
repository: TirSystem/github-action
ref: ${{ inputs.tools-ref }}
path: shared-scripts
- name: Validate the inputs
run: bash shared-scripts/tools/quality-checks-cpp.sh validate
- name: Install the tools
run: bash shared-scripts/tools/quality-checks-cpp.sh install
- name: Run the checks
run: bash shared-scripts/tools/quality-checks-cpp.sh run
@@ -0,0 +1,61 @@
name: Quality checks C#
# Reusable workflow (ADR-0008). A repository calls it with
#
# jobs:
# quality:
# uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1
#
# It checks the C# solution or project of the repository with `dotnet format`
# and `dotnet build` (warnings as errors) on an exact .NET SDK 10 or later,
# changes no file and needs no secret. The package restore needs the network.
on:
workflow_call:
inputs:
working-directory:
description: "Directory, relative to the repository root, whose files are checked"
type: string
default: "."
project:
description: "Solution or project file, relative to working-directory; empty uses the single .sln, .slnx or .csproj found"
type: string
default: ""
dotnet-sdk-version:
description: "Exact .NET SDK version, 10 or later (no channel, no range)"
type: string
default: "10.0.401"
tools-ref:
description: "Tag or branch of TirSystem/github-action whose tools/quality-checks-csharp.sh is run; pin it to the exact tag together with the workflow"
type: string
default: "v1"
jobs:
quality-checks-csharp:
permissions:
contents: read
runs-on: ubuntu-latest
timeout-minutes: 15
env:
WORKING_DIRECTORY: ${{ inputs.working-directory }}
PROJECT: ${{ inputs.project }}
DOTNET_SDK_VERSION: ${{ inputs.dotnet-sdk-version }}
DOTNET_ROOT: /tmp/dotnet
steps:
- name: Check out the repository
uses: actions/checkout@v4.2.2
- name: Fetch the shared script
uses: actions/checkout@v4.2.2
with:
repository: TirSystem/github-action
ref: ${{ inputs.tools-ref }}
path: shared-scripts
- name: Validate the inputs
run: bash shared-scripts/tools/quality-checks-csharp.sh validate
- name: Install the .NET SDK
run: bash shared-scripts/tools/quality-checks-csharp.sh install
- name: Run the checks
run: bash shared-scripts/tools/quality-checks-csharp.sh run
+14
View File
@@ -20,6 +20,20 @@ Each release lists its changes in these groups, in this order:
## [Unreleased] ## [Unreleased]
### Added
- Reusable workflow `quality-checks-cpp.yml` (ADR-0008): `clang-format --dry-run
-Werror` and `clang-tidy` on the tracked C and C++ files, at exact versions
(inputs `clang-format-version`, `clang-tidy-version`), with the inputs
`working-directory`, `std`, `compile-commands-dir` and `tools-ref`. The
repository needs a `.clang-format`; without a `.clang-tidy` the checks
`clang-diagnostic-*` and `clang-analyzer-*` run, and every clang-tidy finding
is an error (`--warnings-as-errors=*`).
- Reusable workflow `quality-checks-csharp.yml` (ADR-0008): `dotnet format
--verify-no-changes` and `dotnet build -warnaserror` on an exact .NET SDK 10
or later (input `dotnet-sdk-version`, default `10.0.401`), with the inputs
`working-directory`, `project` and `tools-ref`.
### Changed ### Changed
- Every job has a `timeout-minutes` (5 to 15), so a hung step no longer holds a - Every job has a `timeout-minutes` (5 to 15), so a hung step no longer holds a
+95 -2
View File
@@ -17,17 +17,19 @@ A collection of reusable Gitea Actions workflows for DevOps professionals and so
This repository is the central collection of reusable automation for TirSystem repositories. The primary repository lives at `git.tirsystem.com` (Gitea) and is push-mirrored to GitHub. This repository is the central collection of reusable automation for TirSystem repositories. The primary repository lives at `git.tirsystem.com` (Gitea) and is push-mirrored to GitHub.
It contains six workflows: metadata sync to the GitHub mirror, wiki publishing, shared quality checks, a release workflow, the publishing of accepted milestones and the repository's own validation. They are listed with their purpose and a diagram under [Workflows](#-workflows). It contains eight workflows: metadata sync to the GitHub mirror, wiki publishing, shared quality checks for Python and shell, for C and C++ and for C#, a release workflow, the publishing of accepted milestones and the repository's own validation. They are listed with their purpose and a diagram under [Workflows](#-workflows).
## 🔧 Workflows ## 🔧 Workflows
Six workflows live in this repository. A **scoped** workflow is delivered by the instance to every repository of the TirSystem organizations and needs nothing in the repository; a **reusable** workflow is called by a repository with `uses:`; the others run only here. The diagrams are PlantUML source. Eight workflows live in this repository. A **scoped** workflow is delivered by the instance to every repository of the TirSystem organizations and needs nothing in the repository; a **reusable** workflow is called by a repository with `uses:`; the others run only here. The diagrams are PlantUML source.
| Workflow | File | Kind | Starts on | Purpose | | Workflow | File | Kind | Starts on | Purpose |
| --- | --- | --- | --- | --- | | --- | --- | --- | --- | --- |
| Sync GitHub mirror metadata | [`sync-github-metadata.yml`](.gitea/scoped_workflows/sync-github-metadata.yml) | Scoped | push to `main`, manual, daily 03:17 UTC | Copies the description and topics of a Gitea repository to its GitHub push mirror | | Sync GitHub mirror metadata | [`sync-github-metadata.yml`](.gitea/scoped_workflows/sync-github-metadata.yml) | Scoped | push to `main`, manual, daily 03:17 UTC | Copies the description and topics of a Gitea repository to its GitHub push mirror |
| Publish wiki | [`publish-wiki.yml`](.gitea/scoped_workflows/publish-wiki.yml) | Scoped, opt-in with `wiki/.publish` | push to `main` that changes `wiki/**`, manual | Publishes the pages in `wiki/` to the repository wiki | | Publish wiki | [`publish-wiki.yml`](.gitea/scoped_workflows/publish-wiki.yml) | Scoped, opt-in with `wiki/.publish` | push to `main` that changes `wiki/**`, manual | Publishes the pages in `wiki/` to the repository wiki |
| Quality checks | [`quality-checks.yml`](.gitea/workflows/quality-checks.yml) | Reusable (`workflow_call`) | a call from another repository | Runs ruff, mypy, shellcheck and shfmt on the tracked files and changes nothing | | Quality checks | [`quality-checks.yml`](.gitea/workflows/quality-checks.yml) | Reusable (`workflow_call`) | a call from another repository | Runs ruff, mypy, shellcheck and shfmt on the tracked files and changes nothing |
| Quality checks C++ | [`quality-checks-cpp.yml`](.gitea/workflows/quality-checks-cpp.yml) | Reusable (`workflow_call`) | a call from another repository | Runs clang-format and clang-tidy at exact versions on the tracked C and C++ files and changes nothing |
| Quality checks C# | [`quality-checks-csharp.yml`](.gitea/workflows/quality-checks-csharp.yml) | Reusable (`workflow_call`) | a call from another repository | Runs `dotnet format` and `dotnet build` on an exact .NET SDK 10 or later and changes nothing |
| Release | [`release.yml`](.gitea/workflows/release.yml) | This repository only | manual | Creates the version tag, the release page and the major tag after the checks | | Release | [`release.yml`](.gitea/workflows/release.yml) | This repository only | manual | Creates the version tag, the release page and the major tag after the checks |
| Publish accepted milestones | [`sync-milestones.yml`](.gitea/workflows/sync-milestones.yml) | This repository only | push to `main` that changes `docs/milestones/**` or `docs/sqa/reviews/**`, manual (dry run by default) | Creates or updates the Gitea milestone and issues of every milestone that is Accepted with a Go review | | Publish accepted milestones | [`sync-milestones.yml`](.gitea/workflows/sync-milestones.yml) | This repository only | push to `main` that changes `docs/milestones/**` or `docs/sqa/reviews/**`, manual (dry run by default) | Creates or updates the Gitea milestone and issues of every milestone that is Accepted with a Go review |
| Validate workflows | [`validate-workflows.yml`](.gitea/workflows/validate-workflows.yml) | This repository only | pull request, push to `main`, manual | Parses every workflow and runs the offline tests | | Validate workflows | [`validate-workflows.yml`](.gitea/workflows/validate-workflows.yml) | This repository only | pull request, push to `main`, manual | Parses every workflow and runs the offline tests |
@@ -188,6 +190,96 @@ deactivate Workflow
@enduml @enduml
``` ```
### 🧱 Quality checks C++
A reusable workflow for C and C++, called with `uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1` (ADR-0008). The repository needs a `.clang-format`; a `.clang-tidy` and a compile database are optional.
#### 🔀 Workflow
```plantuml
@startuml
title Shared quality checks for C and C++ (reusable workflow)
autonumber
actor "Calling repository\nuses: ...quality-checks-cpp.yml@v1" as Caller
participant "Gitea Actions\nquality-checks-cpp" as Workflow
participant "PyPI" as PyPI
Caller -> Workflow: workflow_call with working-directory, std,\ncompile-commands-dir and tool versions
activate Workflow
Workflow -> Workflow: Check out the caller and the shared script
Workflow -> Workflow: Validate the inputs
alt an input is invalid or a version is not exact
Workflow --> Caller: Fail with [configuration]
end
Workflow -> PyPI: Install clang-format and clang-tidy at the exact versions
PyPI --> Workflow: Tools installed
alt no C or C++ file is tracked
Workflow --> Caller: Notice: nothing was checked, pass
else no .clang-format, or compile-commands-dir\nwithout compile_commands.json
Workflow --> Caller: Fail with [configuration]
else
Workflow -> Workflow: clang-format --dry-run -Werror on all files
Workflow -> Workflow: clang-tidy on the C++ files (-std=std)\nand on the C files (or with the compile database)
alt any tool failed
Workflow --> Caller: Fail with tool, file and line in the log
else
Workflow --> Caller: All selected checks passed
end
end
deactivate Workflow
@enduml
```
### 🟣 Quality checks C#
A reusable workflow for C#, called with `uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1` (ADR-0008). It installs the exact .NET SDK given by `dotnet-sdk-version` (10 or later) and needs the network for the package restore.
#### 🔀 Workflow
```plantuml
@startuml
title Shared quality checks for C# (reusable workflow)
autonumber
actor "Calling repository\nuses: ...quality-checks-csharp.yml@v1" as Caller
participant "Gitea Actions\nquality-checks-csharp" as Workflow
participant "dot.net\n(dotnet-install.sh)" as DotNet
Caller -> Workflow: workflow_call with working-directory,\nproject and dotnet-sdk-version
activate Workflow
Workflow -> Workflow: Check out the caller and the shared script
Workflow -> Workflow: Validate the inputs
alt an input is invalid or the SDK is not an exact\nstable version 10 or later
Workflow --> Caller: Fail with [configuration]
end
Workflow -> DotNet: Install the exact .NET SDK version
DotNet --> Workflow: SDK installed
alt no C# file is tracked
Workflow --> Caller: Notice: nothing was checked, pass
else no solution or project, or several without the project input
Workflow --> Caller: Fail with [configuration] that names them
else
Workflow -> Workflow: dotnet format --verify-no-changes
Workflow -> Workflow: dotnet build -warnaserror\n(package restore needs the network)
alt any tool failed
Workflow --> Caller: Fail with tool, file and line in the log
else
Workflow --> Caller: All selected checks passed
end
end
deactivate Workflow
@enduml
```
### 🏷️ Release ### 🏷️ Release
Started by hand by a maintainer; with `dry_run` `true` (the default) it only checks (see the [release process](guides/release-process.md)). Started by hand by a maintainer; with `dry_run` `true` (the default) it only checks (see the [release process](guides/release-process.md)).
@@ -366,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
+100
View File
@@ -0,0 +1,100 @@
# 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 the workflow runs the compiler diagnostics
and the static analyzer (`clang-diagnostic-*` and `clang-analyzer-*`),
because clang-tidy itself enables no check when there is no configuration.
- 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` (or of `clang-diagnostic-*` and `clang-analyzer-*` without one); `*.c` files are checked as C17, the other files as the C++ standard of `std`; every finding is an error (`--warnings-as-errors=*`), so a warning fails the run |
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"
) )
+722
View File
@@ -0,0 +1,722 @@
"""Offline tests for the reusable C++ and C# quality-check workflows (ADR-0008).
The shell steps run with stub tools in a throwaway git repository, so no
network, no clang and no .NET SDK are needed.
"""
import os
import re
import shutil
import subprocess
from pathlib import Path
from typing import Any
import pytest
import yaml
from workflow_source import REPO_ROOT
CPP_WORKFLOW = REPO_ROOT / ".gitea" / "workflows" / "quality-checks-cpp.yml"
CSHARP_WORKFLOW = REPO_ROOT / ".gitea" / "workflows" / "quality-checks-csharp.yml"
CPP_SCRIPT = REPO_ROOT / "tools" / "quality-checks-cpp.sh"
CSHARP_SCRIPT = REPO_ROOT / "tools" / "quality-checks-csharp.sh"
BASH = shutil.which("bash")
pytestmark = pytest.mark.skipif(BASH is None, reason="bash is needed to run the workflow steps")
# A script run: the finished process and the tool calls the stubs logged.
Run = tuple[subprocess.CompletedProcess[str], list[str]]
def load(path: Path) -> dict[str, Any]: # parsed YAML has no fixed shape
return yaml.safe_load(path.read_text(encoding="utf-8"))
def inputs_of(path: Path) -> dict[str, Any]:
return load(path)[True]["workflow_call"]["inputs"] # PyYAML reads `on` as True
@pytest.mark.parametrize(
"workflow, script, job",
[
(CPP_WORKFLOW, "quality-checks-cpp.sh", "quality-checks-cpp"),
(CSHARP_WORKFLOW, "quality-checks-csharp.sh", "quality-checks-csharp"),
],
ids=["cpp", "csharp"],
)
class TestDefinition:
def test_has_least_privilege_and_needs_no_secret(self, workflow: Path, script: str, job: str) -> None:
document = load(workflow)
assert document["jobs"][job]["permissions"] == {"contents": "read"}
assert "secrets" not in workflow.read_text(encoding="utf-8").replace("needs no secret", "")
def test_embeds_no_script_and_runs_the_file_in_three_steps(
self,
workflow: Path,
script: str,
job: str,
) -> None:
steps = load(workflow)["jobs"][job]["steps"]
commands = [step["run"] for step in steps if "run" in step]
assert commands == [f"bash shared-scripts/tools/{script} {c}" for c in ("validate", "install", "run")]
def test_fetches_the_script_at_the_tools_ref_input(self, workflow: Path, script: str, job: str) -> None:
steps = load(workflow)["jobs"][job]["steps"]
fetch = next(step for step in steps if step.get("name") == "Fetch the shared script")
assert fetch["with"] == {
"repository": "TirSystem/github-action",
"ref": "${{ inputs.tools-ref }}",
"path": "shared-scripts",
}
assert inputs_of(workflow)["tools-ref"]["default"] == "v1"
def test_inputs_reach_the_script_only_through_the_environment(
self,
workflow: Path,
script: str,
job: str,
) -> None:
for step in load(workflow)["jobs"][job]["steps"]:
assert "${{" not in step.get("run", "")
def test_script_is_a_file_that_parses(self, workflow: Path, script: str, job: str) -> None:
result = subprocess.run(
[BASH, "-n", str(REPO_ROOT / "tools" / script)], text=True, capture_output=True
)
assert result.returncode == 0, result.stderr
def test_unknown_command_is_refused(self, workflow: Path, script: str, job: str) -> None:
result = subprocess.run(
[BASH, str(REPO_ROOT / "tools" / script), "bogus"], text=True, capture_output=True
)
assert result.returncode == 2
def test_cpp_inputs_and_exact_defaults() -> None:
inputs = inputs_of(CPP_WORKFLOW)
assert set(inputs) == {
"working-directory",
"std",
"compile-commands-dir",
"clang-format-version",
"clang-tidy-version",
"tools-ref",
}
assert inputs["std"]["default"] == "c++20"
assert inputs["compile-commands-dir"]["default"] == ""
assert inputs["clang-format-version"]["default"] == "23.1.3"
assert inputs["clang-tidy-version"]["default"] == "22.1.8"
def test_csharp_inputs_and_exact_sdk_default() -> None:
inputs = inputs_of(CSHARP_WORKFLOW)
assert set(inputs) == {"working-directory", "project", "dotnet-sdk-version", "tools-ref"}
assert inputs["dotnet-sdk-version"]["default"] == "10.0.401"
def test_cpp_script_and_workflow_do_not_mention_cppcheck() -> None:
for path in (CPP_SCRIPT, CPP_WORKFLOW):
assert "cppcheck" not in path.read_text(encoding="utf-8").lower(), path.name
# ----------------------------------------------------------------- helpers
def make_repo(tmp_path: Path) -> Path:
root = tmp_path / "repo"
root.mkdir()
subprocess.run(["git", "init", "-q"], cwd=root, check=True)
return root
def add_files(root: Path, *relative: str) -> None:
for name in relative:
path = root / name
path.parent.mkdir(parents=True, exist_ok=True)
path.write_text("x\n", encoding="utf-8", newline="\n")
subprocess.run(["git", "add", "-A"], cwd=root, check=True)
def stub(directory: Path, name: str) -> Path:
path = directory / name
path.write_text(
"#!/usr/bin/env bash\n"
'name="$(basename "$0")"\n'
'[ "$name" = dotnet ] && name="dotnet $1"\n'
'echo "$name :: $*" >> "$STUB_LOG"\n'
'case ",${STUB_FAIL}," in\n'
' *",$name,"*) echo "src/a.cpp:3:1: stub finding from $name"; exit 1 ;;\n'
"esac\n"
"exit 0\n",
encoding="utf-8",
newline="\n",
)
path.chmod(0o755)
return path
def run_script(script: Path, command: str, cwd: Path, tmp_path: Path, **env: str) -> Run:
log = tmp_path / "tools.log"
environment = dict(os.environ)
environment.update({"STUB_LOG": log.as_posix(), "STUB_FAIL": ""})
environment.update(env)
result = subprocess.run(
[BASH, str(script), command], cwd=cwd, env=environment, text=True, capture_output=True
)
calls = log.read_text(encoding="utf-8").splitlines() if log.exists() else []
return result, calls
# --------------------------------------------------------------------- C++
@pytest.fixture
def cpp_bin(tmp_path: Path) -> Path:
directory = tmp_path / "bin"
directory.mkdir()
for tool in ("clang-format", "clang-tidy"):
stub(directory, tool)
return directory
def cpp_env(cpp_bin: Path, **extra: str) -> dict[str, str]:
values = {
"WORKING_DIRECTORY": ".",
"STD": "c++20",
"COMPILE_COMMANDS_DIR": "",
"CLANG_FORMAT_VERSION": "23.1.3",
"CLANG_TIDY_VERSION": "22.1.8",
"QC_VENV": "/nonexistent",
"QC_BIN": cpp_bin.as_posix(),
}
values.update(extra)
return values
class TestCppValidate:
def run(self, tmp_path: Path, cpp_bin: Path, **extra: str) -> Run:
return run_script(CPP_SCRIPT, "validate", tmp_path, tmp_path, **cpp_env(cpp_bin, **extra))
def test_accepts_the_defaults(self, tmp_path: Path, cpp_bin: Path) -> None:
result, _ = self.run(tmp_path, cpp_bin)
assert result.returncode == 0, result.stdout
@pytest.mark.parametrize("std", ["c++17", "c++23", "gnu++20"])
def test_accepts_a_cpp_standard(self, tmp_path: Path, cpp_bin: Path, std: str) -> None:
assert self.run(tmp_path, cpp_bin, STD=std)[0].returncode == 0
@pytest.mark.parametrize("std", ["", "c17", "c++", "latest", "c++20; rm"])
def test_rejects_a_value_that_is_not_a_cpp_standard(
self,
tmp_path: Path,
cpp_bin: Path,
std: str,
) -> None:
result, _ = self.run(tmp_path, cpp_bin, STD=std)
assert result.returncode == 1 and "[configuration]" in result.stdout
@pytest.mark.parametrize("directory", ["/etc", "..", "../x", "a/../..", ""])
def test_rejects_a_working_directory_outside_the_repository(
self,
tmp_path: Path,
cpp_bin: Path,
directory: str,
) -> None:
result, _ = self.run(tmp_path, cpp_bin, WORKING_DIRECTORY=directory)
assert result.returncode == 1 and "working-directory" in result.stdout
@pytest.mark.parametrize("directory", ["/tmp/build", "../build"])
def test_rejects_a_compile_commands_dir_outside_the_repository(
self,
tmp_path: Path,
cpp_bin: Path,
directory: str,
) -> None:
result, _ = self.run(tmp_path, cpp_bin, COMPILE_COMMANDS_DIR=directory)
assert result.returncode == 1 and "compile-commands-dir" in result.stdout
@pytest.mark.parametrize("name", ["CLANG_FORMAT_VERSION", "CLANG_TIDY_VERSION"])
@pytest.mark.parametrize("version", ["", "latest", "23", ">=23", "23.1.3 --pre"])
def test_rejects_a_version_that_is_not_exact(
self,
tmp_path: Path,
cpp_bin: Path,
name: str,
version: str,
) -> None:
result, _ = self.run(tmp_path, cpp_bin, **{name: version})
assert result.returncode == 1 and "exact version" in result.stdout
class TestCppRun:
@pytest.fixture
def repo(self, tmp_path: Path) -> Path:
root = make_repo(tmp_path)
add_files(root, ".clang-format")
return root
def run(self, repo: Path, tmp_path: Path, cpp_bin: Path, **extra: str) -> Run:
return run_script(CPP_SCRIPT, "run", repo, tmp_path, **cpp_env(cpp_bin, **extra))
def test_runs_clang_format_once_and_clang_tidy_per_language(
self,
repo: Path,
tmp_path: Path,
cpp_bin: Path,
) -> None:
add_files(repo, "src/a.cpp", "src/a.hpp", "lib/c.c")
result, calls = self.run(repo, tmp_path, cpp_bin)
assert result.returncode == 0, result.stdout + result.stderr
assert [c.split(" :: ")[0] for c in calls] == ["clang-format", "clang-tidy", "clang-tidy"]
assert "--dry-run -Werror" in calls[0]
assert "src/a.cpp" in calls[0] and "lib/c.c" in calls[0]
assert "-- -std=c++20" in calls[1] and "lib/c.c" not in calls[1]
assert "-- -std=c17" in calls[2] and "lib/c.c" in calls[2]
assert "All selected checks passed." in result.stdout
def test_the_std_input_reaches_clang_tidy(self, repo: Path, tmp_path: Path, cpp_bin: Path) -> None:
add_files(repo, "a.cpp")
_, calls = self.run(repo, tmp_path, cpp_bin, STD="c++17")
assert "-- -std=c++17" in calls[1]
def test_a_compile_database_is_used_instead_of_a_standard(
self,
repo: Path,
tmp_path: Path,
cpp_bin: Path,
) -> None:
add_files(repo, "a.cpp", "build/compile_commands.json")
result, calls = self.run(repo, tmp_path, cpp_bin, COMPILE_COMMANDS_DIR="build")
assert result.returncode == 0, result.stdout
assert len(calls) == 2
database = re.search(r"-p (\S+)", calls[1])
assert database is not None and database.group(1).endswith(f"/{repo.name}/build")
assert "-std=" not in calls[1]
def test_clang_tidy_gets_default_checks_without_a_clang_tidy_file(
self,
repo: Path,
tmp_path: Path,
cpp_bin: Path,
) -> None:
add_files(repo, "a.cpp")
_, calls = self.run(repo, tmp_path, cpp_bin)
assert "--checks=clang-diagnostic-*,clang-analyzer-*" in calls[1]
assert "--checks=" not in calls[0]
def test_no_default_checks_when_a_clang_tidy_file_is_in_the_repository_root(
self,
repo: Path,
tmp_path: Path,
cpp_bin: Path,
) -> None:
add_files(repo, "a.cpp", ".clang-tidy")
_, calls = self.run(repo, tmp_path, cpp_bin)
assert len(calls) == 2
assert not any("--checks=" in call for call in calls)
@pytest.mark.parametrize(
("files", "extra", "tidy_calls"),
[
(("a.cpp", "lib/c.c"), {}, 2),
(("a.cpp", ".clang-tidy"), {}, 1),
(("a.cpp", "build/compile_commands.json"), {"COMPILE_COMMANDS_DIR": "build"}, 1),
],
ids=["no-clang-tidy-file", "clang-tidy-file", "compile-database"],
)
def test_every_clang_tidy_call_treats_warnings_as_errors(
self,
repo: Path,
tmp_path: Path,
cpp_bin: Path,
files: tuple[str, ...],
extra: dict[str, str],
tidy_calls: int,
) -> None:
add_files(repo, *files)
_, calls = self.run(repo, tmp_path, cpp_bin, **extra)
tidy = [c for c in calls if c.startswith("clang-tidy")]
assert len(tidy) == tidy_calls
assert all("--warnings-as-errors=*" in call for call in tidy)
assert "--warnings-as-errors" not in calls[0] and calls[0].startswith("clang-format")
def test_no_default_checks_when_a_clang_tidy_file_is_above_the_working_directory(
self,
repo: Path,
tmp_path: Path,
cpp_bin: Path,
) -> None:
add_files(repo, "service/a.cpp", ".clang-tidy")
_, calls = self.run(repo, tmp_path, cpp_bin, WORKING_DIRECTORY="service")
assert len(calls) == 2
assert not any("--checks=" in call for call in calls)
def test_a_compile_database_is_resolved_from_the_repository_root(
self,
repo: Path,
tmp_path: Path,
cpp_bin: Path,
) -> None:
add_files(repo, "service/a.cpp", "build/compile_commands.json")
result, calls = self.run(
repo, tmp_path, cpp_bin, WORKING_DIRECTORY="service", COMPILE_COMMANDS_DIR="build"
)
assert result.returncode == 0, result.stdout
database = re.search(r"-p (\S+)", calls[1])
assert database is not None and database.group(1).endswith(f"/{repo.name}/build")
def test_a_compile_database_only_inside_the_working_directory_is_not_found(
self,
repo: Path,
tmp_path: Path,
cpp_bin: Path,
) -> None:
add_files(repo, "service/a.cpp", "service/build/compile_commands.json")
result, calls = self.run(
repo, tmp_path, cpp_bin, WORKING_DIRECTORY="service", COMPILE_COMMANDS_DIR="build"
)
assert result.returncode == 1 and "[configuration]" in result.stdout
assert calls == []
def test_a_missing_compile_database_is_a_configuration_error(
self,
repo: Path,
tmp_path: Path,
cpp_bin: Path,
) -> None:
add_files(repo, "a.cpp")
result, calls = self.run(repo, tmp_path, cpp_bin, COMPILE_COMMANDS_DIR="build")
assert result.returncode == 1 and "compile_commands.json" in result.stdout
assert calls == []
def test_a_missing_clang_format_file_is_a_configuration_error(
self,
tmp_path: Path,
cpp_bin: Path,
) -> None:
repo = make_repo(tmp_path)
add_files(repo, "a.cpp")
result, calls = self.run(repo, tmp_path, cpp_bin)
assert result.returncode == 1
assert "[configuration]" in result.stdout and ".clang-format" in result.stdout
assert calls == []
def test_a_clang_format_file_above_the_working_directory_is_found(
self,
repo: Path,
tmp_path: Path,
cpp_bin: Path,
) -> None:
add_files(repo, "service/a.cpp")
result, _ = run_script(
CPP_SCRIPT,
"run",
repo,
tmp_path,
**cpp_env(cpp_bin, WORKING_DIRECTORY="service"),
)
assert result.returncode == 0, result.stdout
def test_a_failing_tool_fails_the_job_and_the_other_still_runs(
self,
repo: Path,
tmp_path: Path,
cpp_bin: Path,
) -> None:
add_files(repo, "src/a.cpp")
result, calls = self.run(repo, tmp_path, cpp_bin, STUB_FAIL="clang-format")
assert result.returncode == 1
assert len(calls) == 2, "clang-tidy runs after clang-format failed"
assert "::group::clang-format" in result.stdout
assert "src/a.cpp:3:1: stub finding from clang-format" in result.stdout
assert "FAIL clang-format" in result.stdout and "PASS clang-tidy (C++)" in result.stdout
assert "Quality checks failed: clang-format" in result.stdout
def test_a_repository_without_c_or_cpp_files_passes_with_a_notice(
self,
tmp_path: Path,
cpp_bin: Path,
) -> None:
repo = make_repo(tmp_path)
add_files(repo, "README.md")
result, calls = self.run(repo, tmp_path, cpp_bin)
assert result.returncode == 0 and calls == []
assert "No C or C++ files" in result.stdout
def test_only_tracked_files_under_the_working_directory_are_checked(
self,
repo: Path,
tmp_path: Path,
cpp_bin: Path,
) -> None:
add_files(repo, "top.cpp", "service/api.cpp")
(repo / "service" / "untracked.cpp").write_text("x\n", encoding="utf-8")
_, calls = self.run(repo, tmp_path, cpp_bin, WORKING_DIRECTORY="service")
text = "\n".join(calls)
assert "api.cpp" in text and "top.cpp" not in text and "untracked" not in text
def test_no_file_is_changed(self, repo: Path, tmp_path: Path, cpp_bin: Path) -> None:
add_files(repo, "a.cpp")
def snapshot() -> dict[str, bytes]:
return {p.name: p.read_bytes() for p in repo.iterdir() if p.is_file()}
before = snapshot()
self.run(repo, tmp_path, cpp_bin, STUB_FAIL="clang-tidy (C++)")
assert snapshot() == before
def test_a_missing_working_directory_is_a_configuration_error(
self,
repo: Path,
tmp_path: Path,
cpp_bin: Path,
) -> None:
result, _ = self.run(repo, tmp_path, cpp_bin, WORKING_DIRECTORY="nope")
assert result.returncode == 1 and "[configuration]" in result.stdout
def test_cpp_install_pins_both_tools_to_the_exact_versions(tmp_path: Path) -> None:
"""`install` creates the venv and installs `==` versions; checked with a fake pip."""
venv = tmp_path / "venv"
fake_python = tmp_path / "bin"
fake_python.mkdir()
log = tmp_path / "pip.log"
python3 = fake_python / "python3"
python3.write_text(
"#!/usr/bin/env bash\n"
'mkdir -p "$3/bin"\n'
"printf '#!/usr/bin/env bash\\necho \"$*\" >> \"%s\"\\n' > \"$3/bin/pip\"\n" % log.as_posix()
+ 'chmod +x "$3/bin/pip"\n',
encoding="utf-8",
newline="\n",
)
python3.chmod(0o755)
environment = dict(os.environ)
environment["PATH"] = f"{fake_python.as_posix()}:{environment['PATH']}"
environment.update(
{
"QC_VENV": venv.as_posix(),
"CLANG_FORMAT_VERSION": "23.1.3",
"CLANG_TIDY_VERSION": "22.1.8",
}
)
result = subprocess.run(
[BASH, str(CPP_SCRIPT), "install"], env=environment, text=True, capture_output=True
)
assert result.returncode == 0, result.stdout + result.stderr
installed = log.read_text(encoding="utf-8")
assert "clang-format==23.1.3" in installed
assert "clang-tidy==22.1.8" in installed
# --------------------------------------------------------------------- C#
@pytest.fixture
def dotnet_stub(tmp_path: Path) -> Path:
directory = tmp_path / "dotnet-bin"
directory.mkdir()
return stub(directory, "dotnet")
def csharp_env(dotnet_stub: Path, tmp_path: Path, **extra: str) -> dict[str, str]:
values = {
"WORKING_DIRECTORY": ".",
"PROJECT": "",
"DOTNET_SDK_VERSION": "10.0.401",
"DOTNET_ROOT": (tmp_path / "dotnet-root").as_posix(),
"QC_DOTNET": dotnet_stub.as_posix(),
}
values.update(extra)
return values
class TestCsharpValidate:
def run(self, tmp_path: Path, dotnet_stub: Path, **extra: str) -> Run:
return run_script(
CSHARP_SCRIPT, "validate", tmp_path, tmp_path, **csharp_env(dotnet_stub, tmp_path, **extra)
)
@pytest.mark.parametrize("version", ["10.0.401", "10.0.100", "11.0.100", "100.1.2"])
def test_accepts_an_exact_sdk_of_version_10_or_later(
self,
tmp_path: Path,
dotnet_stub: Path,
version: str,
) -> None:
assert self.run(tmp_path, dotnet_stub, DOTNET_SDK_VERSION=version)[0].returncode == 0
@pytest.mark.parametrize(
"version",
["", "8.0.425", "9.0.100", "10.0", "10", "10.0.x", "latest", "10.0.401-rc.1", "10.0.401 --verbose"],
)
def test_rejects_an_old_or_inexact_sdk(self, tmp_path: Path, dotnet_stub: Path, version: str) -> None:
result, _ = self.run(tmp_path, dotnet_stub, DOTNET_SDK_VERSION=version)
assert result.returncode == 1
assert "[configuration]" in result.stdout and "dotnet-sdk-version" in result.stdout
@pytest.mark.parametrize("directory", ["/etc", "..", "../x", ""])
def test_rejects_a_working_directory_outside_the_repository(
self,
tmp_path: Path,
dotnet_stub: Path,
directory: str,
) -> None:
result, _ = self.run(tmp_path, dotnet_stub, WORKING_DIRECTORY=directory)
assert result.returncode == 1 and "working-directory" in result.stdout
@pytest.mark.parametrize("project", ["/etc/x.sln", "../x.sln"])
def test_rejects_a_project_outside_the_working_directory(
self,
tmp_path: Path,
dotnet_stub: Path,
project: str,
) -> None:
result, _ = self.run(tmp_path, dotnet_stub, PROJECT=project)
assert result.returncode == 1 and "project" in result.stdout
class TestCsharpInstall:
def test_installs_the_exact_version_with_the_official_script(
self,
tmp_path: Path,
dotnet_stub: Path,
) -> None:
root = tmp_path / "dotnet-root"
installer = tmp_path / "dotnet-install.sh"
installer.write_text(
"#!/usr/bin/env bash\n"
'echo "$*" >> "$STUB_LOG"\n'
'dir=""\n'
'while [ "$#" -gt 0 ]; do [ "$1" = --install-dir ] && dir="$2"; shift; done\n'
'mkdir -p "$dir"\n'
"printf '#!/usr/bin/env bash\\necho 10.0.401\\n' > \"$dir/dotnet\"\n"
'chmod +x "$dir/dotnet"\n',
encoding="utf-8",
newline="\n",
)
result, calls = run_script(
CSHARP_SCRIPT,
"install",
tmp_path,
tmp_path,
**csharp_env(dotnet_stub, tmp_path, QC_DOTNET_INSTALL_SCRIPT=installer.as_posix()),
)
assert result.returncode == 0, result.stdout + result.stderr
assert calls and "--version 10.0.401" in calls[0]
assert f"--install-dir {root.as_posix()}" in calls[0]
assert "10.0.401" in result.stdout
class TestCsharpRun:
@pytest.fixture
def repo(self, tmp_path: Path) -> Path:
return make_repo(tmp_path)
def run(self, repo: Path, tmp_path: Path, dotnet_stub: Path, **extra: str) -> Run:
return run_script(
CSHARP_SCRIPT, "run", repo, tmp_path, **csharp_env(dotnet_stub, tmp_path, **extra)
)
def test_runs_format_and_build_on_the_single_solution(
self,
repo: Path,
tmp_path: Path,
dotnet_stub: Path,
) -> None:
add_files(repo, "App.sln", "src/App.csproj", "src/Program.cs")
result, calls = self.run(repo, tmp_path, dotnet_stub)
assert result.returncode == 0, result.stdout + result.stderr
assert [c.split(" :: ")[0] for c in calls] == ["dotnet format", "dotnet build"]
assert "App.sln" in calls[0] and "--verify-no-changes" in calls[0]
assert "App.sln" in calls[1] and "-warnaserror" in calls[1]
assert "All selected checks passed." in result.stdout
def test_uses_the_single_project_when_there_is_no_solution(
self,
repo: Path,
tmp_path: Path,
dotnet_stub: Path,
) -> None:
add_files(repo, "src/App.csproj", "src/Program.cs")
_, calls = self.run(repo, tmp_path, dotnet_stub)
assert "src/App.csproj" in calls[0]
def test_several_projects_without_a_solution_need_the_project_input(
self,
repo: Path,
tmp_path: Path,
dotnet_stub: Path,
) -> None:
add_files(repo, "a/A.csproj", "b/B.csproj", "a/P.cs")
result, calls = self.run(repo, tmp_path, dotnet_stub)
assert result.returncode == 1 and calls == []
assert "[configuration]" in result.stdout
assert "a/A.csproj" in result.stdout and "b/B.csproj" in result.stdout
def test_the_project_input_picks_one(self, repo: Path, tmp_path: Path, dotnet_stub: Path) -> None:
add_files(repo, "a/A.csproj", "b/B.csproj", "a/P.cs")
result, calls = self.run(repo, tmp_path, dotnet_stub, PROJECT="b/B.csproj")
assert result.returncode == 0 and "b/B.csproj" in calls[0]
def test_a_missing_project_file_is_a_configuration_error(
self,
repo: Path,
tmp_path: Path,
dotnet_stub: Path,
) -> None:
add_files(repo, "a/P.cs")
result, calls = self.run(repo, tmp_path, dotnet_stub, PROJECT="nope.csproj")
assert result.returncode == 1 and "does not exist" in result.stdout and calls == []
def test_csharp_files_without_a_project_are_a_configuration_error(
self,
repo: Path,
tmp_path: Path,
dotnet_stub: Path,
) -> None:
add_files(repo, "Program.cs")
result, calls = self.run(repo, tmp_path, dotnet_stub)
assert result.returncode == 1 and calls == []
assert "[configuration]" in result.stdout and "no solution or project" in result.stdout
def test_a_repository_without_csharp_files_passes_with_a_notice(
self,
repo: Path,
tmp_path: Path,
dotnet_stub: Path,
) -> None:
add_files(repo, "README.md")
result, calls = self.run(repo, tmp_path, dotnet_stub)
assert result.returncode == 0 and calls == []
assert "No C# files" in result.stdout
def test_a_failing_tool_fails_the_job_and_the_other_still_runs(
self,
repo: Path,
tmp_path: Path,
dotnet_stub: Path,
) -> None:
add_files(repo, "App.sln", "Program.cs")
result, calls = self.run(repo, tmp_path, dotnet_stub, STUB_FAIL="dotnet format")
assert result.returncode == 1 and len(calls) == 2
assert "::group::dotnet format --verify-no-changes" in result.stdout
assert "FAIL dotnet format --verify-no-changes" in result.stdout
assert "PASS dotnet build -warnaserror" in result.stdout
assert "Quality checks failed: dotnet format --verify-no-changes" in result.stdout
def test_only_files_under_the_working_directory_are_considered(
self,
repo: Path,
tmp_path: Path,
dotnet_stub: Path,
) -> None:
add_files(repo, "Top.sln", "svc/Svc.csproj", "svc/P.cs", "Top.cs")
result, calls = self.run(repo, tmp_path, dotnet_stub, WORKING_DIRECTORY="svc")
assert result.returncode == 0
assert "Svc.csproj" in calls[0] and "Top.sln" not in calls[0]
def test_a_missing_working_directory_is_a_configuration_error(
self,
repo: Path,
tmp_path: Path,
dotnet_stub: Path,
) -> None:
result, _ = self.run(repo, tmp_path, dotnet_stub, WORKING_DIRECTORY="nope")
assert result.returncode == 1 and "[configuration]" in result.stdout
+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"
+163
View File
@@ -0,0 +1,163 @@
#!/usr/bin/env bash
# Steps of the reusable workflow .gitea/workflows/quality-checks-cpp.yml
# (ADR-0008). The workflow checks out the calling repository, fetches this file
# into shared-scripts/ and runs one command per step:
#
# quality-checks-cpp.sh validate check the inputs, before anything is installed
# quality-checks-cpp.sh install install the exact clang tool versions into a venv
# quality-checks-cpp.sh run run clang-format and clang-tidy on the tracked files
#
# Settings come from the environment, never from interpolated expressions:
# WORKING_DIRECTORY, STD, COMPILE_COMMANDS_DIR, CLANG_FORMAT_VERSION,
# CLANG_TIDY_VERSION, QC_VENV (and QC_BIN for tests).
# Every failure is printed as ::error::[category] message.
C_STANDARD="${C_STANDARD:-c17}"
DEFAULT_TIDY_CHECKS="clang-diagnostic-*,clang-analyzer-*"
validate_inputs() {
set -u
case "$WORKING_DIRECTORY" in
"" | /* | .. | ../* | */.. | */../*)
echo "::error::[configuration] working-directory must be a relative path inside the repository."
exit 1
;;
esac
if ! [[ "$STD" =~ ^(c\+\+|gnu\+\+)[0-9]{2}$ ]]; then
echo "::error::[configuration] std '$STD' is not a C++ standard such as c++20 or gnu++20."
exit 1
fi
case "$COMPILE_COMMANDS_DIR" in
/* | .. | ../* | */.. | */../*)
echo "::error::[configuration] compile-commands-dir must be a relative path inside the repository."
exit 1
;;
esac
local name version
for name in CLANG_FORMAT_VERSION CLANG_TIDY_VERSION; do
version="${!name}"
if ! [[ "$version" =~ ^[0-9]+(\.[0-9]+){1,3}$ ]]; then
echo "::error::[configuration] ${name,,} '$version' is not an exact version such as 23.1.3."
exit 1
fi
done
echo "Checking C and C++ in ${WORKING_DIRECTORY} with std ${STD}"
}
install_tools() {
set -eu
python3 -m venv "$QC_VENV"
"$QC_VENV/bin/pip" install --quiet \
"clang-format==${CLANG_FORMAT_VERSION}" "clang-tidy==${CLANG_TIDY_VERSION}"
}
# Succeeds when one of the named files exists in the working directory or above
# it, up to the top of the repository: clang-format and clang-tidy find their
# configuration the same way.
find_config_upwards() {
local top dir parent name
top="$(cd "$(git rev-parse --show-toplevel)" && pwd -P)"
dir="$(pwd -P)"
while true; do
for name in "$@"; do
if [ -f "$dir/$name" ]; then
return 0
fi
done
parent="$(dirname "$dir")"
# stop at the top of the repository, or at the file system root
if [ "$dir" = "$top" ] || [ "$parent" = "$dir" ]; then
return 1
fi
dir="$parent"
done
}
run_checks() {
set -u
QC_BIN="${QC_BIN:-$QC_VENV/bin}"
if [ ! -d "$WORKING_DIRECTORY" ]; then
echo "::error::[configuration] working-directory '$WORKING_DIRECTORY' does not exist."
exit 1
fi
# compile-commands-dir is relative to the repository root, not to the working directory
local repo_top compile_db=""
repo_top="$(cd "$(git rev-parse --show-toplevel)" && pwd -P)"
if [ -n "$COMPILE_COMMANDS_DIR" ]; then
compile_db="$repo_top/$COMPILE_COMMANDS_DIR"
fi
cd "$WORKING_DIRECTORY"
local all_files cpp_files c_files
mapfile -t all_files < <(git ls-files -- '*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx')
if [ "${#all_files[@]}" -eq 0 ]; then
echo "::notice::No C or C++ files in '$WORKING_DIRECTORY'; nothing was checked."
echo "All selected checks passed."
exit 0
fi
if ! find_config_upwards .clang-format _clang-format; then
echo "::error::[configuration] No .clang-format found in '$WORKING_DIRECTORY' or above it; add the style of the project."
exit 1
fi
if [ -n "$compile_db" ] && [ ! -f "$compile_db/compile_commands.json" ]; then
echo "::error::[configuration] compile-commands-dir '$COMPILE_COMMANDS_DIR' has no compile_commands.json; build it before the call."
exit 1
fi
# .c files are C; everything else (including headers) is checked as C++.
mapfile -t c_files < <(git ls-files -- '*.c')
mapfile -t cpp_files < <(git ls-files -- '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx')
local failed=()
run_tool() {
local name="$1"
shift
echo "::group::$name"
if "$@"; then
echo "::endgroup::"
echo "PASS $name"
else
echo "::endgroup::"
echo "FAIL $name"
failed+=("$name")
fi
}
run_tool "clang-format" "$QC_BIN/clang-format" --dry-run -Werror "${all_files[@]}"
# Without a .clang-tidy, clang-tidy enables no check and refuses to run, so
# the project gets the compiler diagnostics and the static analyzer.
# clang-tidy exits 0 on a warning, so every finding is made an error: a
# finding must fail the check, as a failing tool does for the other languages.
local tidy_args=(--quiet "--warnings-as-errors=*")
if ! find_config_upwards .clang-tidy _clang-tidy; then
tidy_args+=("--checks=${DEFAULT_TIDY_CHECKS}")
fi
if [ -n "$compile_db" ]; then
run_tool "clang-tidy" "$QC_BIN/clang-tidy" "${tidy_args[@]}" -p "$compile_db" "${all_files[@]}"
else
if [ "${#cpp_files[@]}" -gt 0 ]; then
run_tool "clang-tidy (C++)" "$QC_BIN/clang-tidy" "${tidy_args[@]}" "${cpp_files[@]}" -- "-std=${STD}"
fi
if [ "${#c_files[@]}" -gt 0 ]; then
run_tool "clang-tidy (C)" "$QC_BIN/clang-tidy" "${tidy_args[@]}" "${c_files[@]}" -- "-std=${C_STANDARD}"
fi
fi
if [ "${#failed[@]}" -gt 0 ]; then
echo "::error::Quality checks failed: ${failed[*]}"
exit 1
fi
echo "All selected checks passed."
}
case "${1:-}" in
validate) validate_inputs ;;
install) install_tools ;;
run) run_checks ;;
*)
echo "::error::[configuration] usage: quality-checks-cpp.sh validate|install|run" >&2
exit 2
;;
esac
+124
View File
@@ -0,0 +1,124 @@
#!/usr/bin/env bash
# Steps of the reusable workflow .gitea/workflows/quality-checks-csharp.yml
# (ADR-0008). The workflow checks out the calling repository, fetches this file
# into shared-scripts/ and runs one command per step:
#
# quality-checks-csharp.sh validate check the inputs, before anything is installed
# quality-checks-csharp.sh install install the exact .NET SDK version
# quality-checks-csharp.sh run run dotnet format and dotnet build on the project
#
# Settings come from the environment, never from interpolated expressions:
# WORKING_DIRECTORY, PROJECT, DOTNET_SDK_VERSION, DOTNET_ROOT (and
# QC_DOTNET_INSTALL_SCRIPT, QC_DOTNET for tests).
# Every failure is printed as ::error::[category] message.
DOTNET_INSTALL_URL="https://dot.net/v1/dotnet-install.sh"
validate_inputs() {
set -u
case "$WORKING_DIRECTORY" in
"" | /* | .. | ../* | */.. | */../*)
echo "::error::[configuration] working-directory must be a relative path inside the repository."
exit 1
;;
esac
case "$PROJECT" in
/* | .. | ../* | */.. | */../*)
echo "::error::[configuration] project must be a relative path inside the working directory."
exit 1
;;
esac
# An exact stable version of the .NET SDK, 10 or later (no channel, no range).
if ! [[ "$DOTNET_SDK_VERSION" =~ ^([1-9][0-9]+)\.[0-9]+\.[0-9]+$ ]] || [ "${BASH_REMATCH[1]}" -lt 10 ]; then
echo "::error::[configuration] dotnet-sdk-version '$DOTNET_SDK_VERSION' is not an exact stable version 10 or later, such as 10.0.401."
exit 1
fi
echo "Checking C# in ${WORKING_DIRECTORY} with .NET SDK ${DOTNET_SDK_VERSION}"
}
install_sdk() {
set -eu
local script="${QC_DOTNET_INSTALL_SCRIPT:-}"
if [ -z "$script" ]; then
script="$(mktemp)"
curl -fsSL "$DOTNET_INSTALL_URL" -o "$script"
fi
bash "$script" --version "$DOTNET_SDK_VERSION" --install-dir "$DOTNET_ROOT" --no-path
"$DOTNET_ROOT/dotnet" --version
}
run_checks() {
set -u
if [ ! -d "$WORKING_DIRECTORY" ]; then
echo "::error::[configuration] working-directory '$WORKING_DIRECTORY' does not exist."
exit 1
fi
cd "$WORKING_DIRECTORY"
local dotnet="${QC_DOTNET:-$DOTNET_ROOT/dotnet}"
local sources
mapfile -t sources < <(git ls-files -- '*.cs')
if [ "${#sources[@]}" -eq 0 ]; then
echo "::notice::No C# files in '$WORKING_DIRECTORY'; nothing was checked."
echo "All selected checks passed."
exit 0
fi
local target="$PROJECT" candidates
if [ -z "$target" ]; then
mapfile -t candidates < <(git ls-files -- '*.sln' '*.slnx')
if [ "${#candidates[@]}" -eq 0 ]; then
mapfile -t candidates < <(git ls-files -- '*.csproj')
fi
case "${#candidates[@]}" in
0)
echo "::error::[configuration] C# files exist but no solution or project was found in '$WORKING_DIRECTORY'; add one or set the input project."
exit 1
;;
1) target="${candidates[0]}" ;;
*)
echo "::error::[configuration] Several solutions or projects were found (${candidates[*]}); set the input project."
exit 1
;;
esac
elif [ ! -f "$target" ]; then
echo "::error::[configuration] project '$target' does not exist in '$WORKING_DIRECTORY'."
exit 1
fi
echo "Checking $target"
export DOTNET_CLI_TELEMETRY_OPTOUT=1 DOTNET_NOLOGO=1
local failed=()
run_tool() {
local name="$1"
shift
echo "::group::$name"
if "$@"; then
echo "::endgroup::"
echo "PASS $name"
else
echo "::endgroup::"
echo "FAIL $name"
failed+=("$name")
fi
}
run_tool "dotnet format --verify-no-changes" "$dotnet" format "$target" --verify-no-changes
run_tool "dotnet build -warnaserror" "$dotnet" build "$target" --nologo -warnaserror
if [ "${#failed[@]}" -gt 0 ]; then
echo "::error::Quality checks failed: ${failed[*]}"
exit 1
fi
echo "All selected checks passed."
}
case "${1:-}" in
validate) validate_inputs ;;
install) install_sdk ;;
run) run_checks ;;
*)
echo "::error::[configuration] usage: quality-checks-csharp.sh validate|install|run" >&2
exit 2
;;
esac
+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)) |
+95 -3
View File
@@ -1,4 +1,4 @@
<!-- translation of Home.md, source sha256 c9c04abaf4ae --> <!-- translation of Home.md, source sha256 5751829e99af -->
> Dette er en oversættelse af [`Home`](Home). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres. > Dette er en oversættelse af [`Home`](Home). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
@@ -13,18 +13,20 @@ En samling af genbrugelige Gitea Actions-workflows til DevOps-professionelle og
Dette repository er den centrale samling af genbrugelig automatisering til TirSystems repositories. Det primære repository ligger på `git.tirsystem.com` (Gitea) og spejles med push til GitHub. Dette repository er den centrale samling af genbrugelig automatisering til TirSystems repositories. Det primære repository ligger på `git.tirsystem.com` (Gitea) og spejles med push til GitHub.
Det indeholder seks workflows: synkronisering af metadata til GitHub-spejlet, publicering af wiki, fælles kvalitetskontrol, et udgivelsesworkflow, publicering af accepterede milepæle og repositoryets egen validering. De er listet med formål og diagram under [Workflows](#workflows). Det indeholder otte workflows: synkronisering af metadata til GitHub-spejlet, publicering af wiki, fælles kvalitetskontrol for Python og shell, for C og C++ og for C#, et udgivelsesworkflow, publicering af accepterede milepæle og repositoryets egen validering. De er listet med formål og diagram under [Workflows](#workflows).
## Workflows ## Workflows
Der er seks workflows i dette repository. Et **scoped** workflow leveres af instansen til alle repositories i TirSystem-organisationerne og kræver intet i repositoryet; et **genbrugeligt** workflow kaldes fra et repository med `uses:`; de øvrige kører kun her. Diagrammerne er PlantUML-kildekode og er på engelsk. Der er otte workflows i dette repository. Et **scoped** workflow leveres af instansen til alle repositories i TirSystem-organisationerne og kræver intet i repositoryet; et **genbrugeligt** workflow kaldes fra et repository med `uses:`; de øvrige kører kun her. Diagrammerne er PlantUML-kildekode og er på engelsk.
| Workflow | Fil | Type | Starter ved | Formål | | Workflow | Fil | Type | Starter ved | Formål |
| --- | --- | --- | --- | --- | | --- | --- | --- | --- | --- |
| Sync GitHub mirror metadata | [`sync-github-metadata.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/sync-github-metadata.yml) | Scoped | push til `main`, manuelt, dagligt kl. 03:17 UTC | Kopierer beskrivelsen og emnerne for et Gitea-repository til dets GitHub push-spejl | | Sync GitHub mirror metadata | [`sync-github-metadata.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/sync-github-metadata.yml) | Scoped | push til `main`, manuelt, dagligt kl. 03:17 UTC | Kopierer beskrivelsen og emnerne for et Gitea-repository til dets GitHub push-spejl |
| Publish wiki | [`publish-wiki.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/publish-wiki.yml) | Scoped, tilmelding med `wiki/.publish` | push til `main`, der ændrer `wiki/**`, manuelt | Publicerer siderne i `wiki/` til repositoryets wiki | | Publish wiki | [`publish-wiki.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/publish-wiki.yml) | Scoped, tilmelding med `wiki/.publish` | push til `main`, der ændrer `wiki/**`, manuelt | Publicerer siderne i `wiki/` til repositoryets wiki |
| Quality checks | [`quality-checks.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks.yml) | Genbrugeligt (`workflow_call`) | et kald fra et andet repository | Kører ruff, mypy, shellcheck og shfmt på de sporede filer og ændrer intet | | Quality checks | [`quality-checks.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks.yml) | Genbrugeligt (`workflow_call`) | et kald fra et andet repository | Kører ruff, mypy, shellcheck og shfmt på de sporede filer og ændrer intet |
| Quality checks C++ | [`quality-checks-cpp.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks-cpp.yml) | Genbrugeligt (`workflow_call`) | et kald fra et andet repository | Kører clang-format og clang-tidy i præcise versioner på de sporede C- og C++-filer og ændrer intet |
| Quality checks C# | [`quality-checks-csharp.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks-csharp.yml) | Genbrugeligt (`workflow_call`) | et kald fra et andet repository | Kører `dotnet format` og `dotnet build` på et præcist .NET SDK 10 eller nyere og ændrer intet |
| Release | [`release.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/release.yml) | Kun dette repository | manuelt | Opretter versionstagget, udgivelsessiden og major-tagget efter kontrollerne | | Release | [`release.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/release.yml) | Kun dette repository | manuelt | Opretter versionstagget, udgivelsessiden og major-tagget efter kontrollerne |
| Publicering af accepterede milepæle | [`sync-milestones.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/sync-milestones.yml) | Kun dette repository | push til `main`, der ændrer `docs/milestones/**` eller `docs/sqa/reviews/**`, manuelt (tørkørsel som standard) | Opretter eller opdaterer Gitea-milepælen og issues for hver milepæl, der er Accepted med en Go-gennemgang | | Publicering af accepterede milepæle | [`sync-milestones.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/sync-milestones.yml) | Kun dette repository | push til `main`, der ændrer `docs/milestones/**` eller `docs/sqa/reviews/**`, manuelt (tørkørsel som standard) | Opretter eller opdaterer Gitea-milepælen og issues for hver milepæl, der er Accepted med en Go-gennemgang |
| Validate workflows | [`validate-workflows.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/validate-workflows.yml) | Kun dette repository | pull request, push til `main`, manuelt | Læser hvert workflow som YAML og kører offline-testene | | Validate workflows | [`validate-workflows.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/validate-workflows.yml) | Kun dette repository | pull request, push til `main`, manuelt | Læser hvert workflow som YAML og kører offline-testene |
@@ -185,6 +187,96 @@ deactivate Workflow
@enduml @enduml
``` ```
### Kvalitetskontrol C++
Et genbrugeligt workflow til C og C++, kaldt med `uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1` (ADR-0008). Repositoryet skal have en `.clang-format`; en `.clang-tidy` og en compile-database er valgfrie.
#### Workflow
```plantuml
@startuml
title Shared quality checks for C and C++ (reusable workflow)
autonumber
actor "Calling repository\nuses: ...quality-checks-cpp.yml@v1" as Caller
participant "Gitea Actions\nquality-checks-cpp" as Workflow
participant "PyPI" as PyPI
Caller -> Workflow: workflow_call with working-directory, std,\ncompile-commands-dir and tool versions
activate Workflow
Workflow -> Workflow: Check out the caller and the shared script
Workflow -> Workflow: Validate the inputs
alt an input is invalid or a version is not exact
Workflow --> Caller: Fail with [configuration]
end
Workflow -> PyPI: Install clang-format and clang-tidy at the exact versions
PyPI --> Workflow: Tools installed
alt no C or C++ file is tracked
Workflow --> Caller: Notice: nothing was checked, pass
else no .clang-format, or compile-commands-dir\nwithout compile_commands.json
Workflow --> Caller: Fail with [configuration]
else
Workflow -> Workflow: clang-format --dry-run -Werror on all files
Workflow -> Workflow: clang-tidy on the C++ files (-std=std)\nand on the C files (or with the compile database)
alt any tool failed
Workflow --> Caller: Fail with tool, file and line in the log
else
Workflow --> Caller: All selected checks passed
end
end
deactivate Workflow
@enduml
```
### Kvalitetskontrol C#
Et genbrugeligt workflow til C#, kaldt med `uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1` (ADR-0008). Det installerer det præcise .NET SDK, som `dotnet-sdk-version` angiver (10 eller nyere), og skal bruge netværket til pakkegendannelsen.
#### Workflow
```plantuml
@startuml
title Shared quality checks for C# (reusable workflow)
autonumber
actor "Calling repository\nuses: ...quality-checks-csharp.yml@v1" as Caller
participant "Gitea Actions\nquality-checks-csharp" as Workflow
participant "dot.net\n(dotnet-install.sh)" as DotNet
Caller -> Workflow: workflow_call with working-directory,\nproject and dotnet-sdk-version
activate Workflow
Workflow -> Workflow: Check out the caller and the shared script
Workflow -> Workflow: Validate the inputs
alt an input is invalid or the SDK is not an exact\nstable version 10 or later
Workflow --> Caller: Fail with [configuration]
end
Workflow -> DotNet: Install the exact .NET SDK version
DotNet --> Workflow: SDK installed
alt no C# file is tracked
Workflow --> Caller: Notice: nothing was checked, pass
else no solution or project, or several without the project input
Workflow --> Caller: Fail with [configuration] that names them
else
Workflow -> Workflow: dotnet format --verify-no-changes
Workflow -> Workflow: dotnet build -warnaserror\n(package restore needs the network)
alt any tool failed
Workflow --> Caller: Fail with tool, file and line in the log
else
Workflow --> Caller: All selected checks passed
end
end
deactivate Workflow
@enduml
```
### Udgivelse ### Udgivelse
Startes manuelt af en vedligeholder; med `dry_run` `true` (standard) kontrollerer det kun (se [udgivelsesprocessen](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/release-process.md)). Startes manuelt af en vedligeholder; med `dry_run` `true` (standard) kontrollerer det kun (se [udgivelsesprocessen](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/release-process.md)).
+94 -2
View File
@@ -13,18 +13,20 @@ A collection of reusable Gitea Actions workflows for DevOps professionals and so
This repository is the central collection of reusable automation for TirSystem repositories. The primary repository lives at `git.tirsystem.com` (Gitea) and is push-mirrored to GitHub. This repository is the central collection of reusable automation for TirSystem repositories. The primary repository lives at `git.tirsystem.com` (Gitea) and is push-mirrored to GitHub.
It contains six workflows: metadata sync to the GitHub mirror, wiki publishing, shared quality checks, a release workflow, the publishing of accepted milestones and the repository's own validation. They are listed with their purpose and a diagram under [Workflows](#workflows). It contains eight workflows: metadata sync to the GitHub mirror, wiki publishing, shared quality checks for Python and shell, for C and C++ and for C#, a release workflow, the publishing of accepted milestones and the repository's own validation. They are listed with their purpose and a diagram under [Workflows](#workflows).
## Workflows ## Workflows
Six workflows live in this repository. A **scoped** workflow is delivered by the instance to every repository of the TirSystem organizations and needs nothing in the repository; a **reusable** workflow is called by a repository with `uses:`; the others run only here. The diagrams are PlantUML source. Eight workflows live in this repository. A **scoped** workflow is delivered by the instance to every repository of the TirSystem organizations and needs nothing in the repository; a **reusable** workflow is called by a repository with `uses:`; the others run only here. The diagrams are PlantUML source.
| Workflow | File | Kind | Starts on | Purpose | | Workflow | File | Kind | Starts on | Purpose |
| --- | --- | --- | --- | --- | | --- | --- | --- | --- | --- |
| Sync GitHub mirror metadata | [`sync-github-metadata.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/sync-github-metadata.yml) | Scoped | push to `main`, manual, daily 03:17 UTC | Copies the description and topics of a Gitea repository to its GitHub push mirror | | Sync GitHub mirror metadata | [`sync-github-metadata.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/sync-github-metadata.yml) | Scoped | push to `main`, manual, daily 03:17 UTC | Copies the description and topics of a Gitea repository to its GitHub push mirror |
| Publish wiki | [`publish-wiki.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/publish-wiki.yml) | Scoped, opt-in with `wiki/.publish` | push to `main` that changes `wiki/**`, manual | Publishes the pages in `wiki/` to the repository wiki | | Publish wiki | [`publish-wiki.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/publish-wiki.yml) | Scoped, opt-in with `wiki/.publish` | push to `main` that changes `wiki/**`, manual | Publishes the pages in `wiki/` to the repository wiki |
| Quality checks | [`quality-checks.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks.yml) | Reusable (`workflow_call`) | a call from another repository | Runs ruff, mypy, shellcheck and shfmt on the tracked files and changes nothing | | Quality checks | [`quality-checks.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks.yml) | Reusable (`workflow_call`) | a call from another repository | Runs ruff, mypy, shellcheck and shfmt on the tracked files and changes nothing |
| Quality checks C++ | [`quality-checks-cpp.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks-cpp.yml) | Reusable (`workflow_call`) | a call from another repository | Runs clang-format and clang-tidy at exact versions on the tracked C and C++ files and changes nothing |
| Quality checks C# | [`quality-checks-csharp.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks-csharp.yml) | Reusable (`workflow_call`) | a call from another repository | Runs `dotnet format` and `dotnet build` on an exact .NET SDK 10 or later and changes nothing |
| Release | [`release.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/release.yml) | This repository only | manual | Creates the version tag, the release page and the major tag after the checks | | Release | [`release.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/release.yml) | This repository only | manual | Creates the version tag, the release page and the major tag after the checks |
| Publish accepted milestones | [`sync-milestones.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/sync-milestones.yml) | This repository only | push to `main` that changes `docs/milestones/**` or `docs/sqa/reviews/**`, manual (dry run by default) | Creates or updates the Gitea milestone and issues of every milestone that is Accepted with a Go review | | Publish accepted milestones | [`sync-milestones.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/sync-milestones.yml) | This repository only | push to `main` that changes `docs/milestones/**` or `docs/sqa/reviews/**`, manual (dry run by default) | Creates or updates the Gitea milestone and issues of every milestone that is Accepted with a Go review |
| Validate workflows | [`validate-workflows.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/validate-workflows.yml) | This repository only | pull request, push to `main`, manual | Parses every workflow and runs the offline tests | | Validate workflows | [`validate-workflows.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/validate-workflows.yml) | This repository only | pull request, push to `main`, manual | Parses every workflow and runs the offline tests |
@@ -185,6 +187,96 @@ deactivate Workflow
@enduml @enduml
``` ```
### Quality checks C++
A reusable workflow for C and C++, called with `uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1` (ADR-0008). The repository needs a `.clang-format`; a `.clang-tidy` and a compile database are optional.
#### Workflow
```plantuml
@startuml
title Shared quality checks for C and C++ (reusable workflow)
autonumber
actor "Calling repository\nuses: ...quality-checks-cpp.yml@v1" as Caller
participant "Gitea Actions\nquality-checks-cpp" as Workflow
participant "PyPI" as PyPI
Caller -> Workflow: workflow_call with working-directory, std,\ncompile-commands-dir and tool versions
activate Workflow
Workflow -> Workflow: Check out the caller and the shared script
Workflow -> Workflow: Validate the inputs
alt an input is invalid or a version is not exact
Workflow --> Caller: Fail with [configuration]
end
Workflow -> PyPI: Install clang-format and clang-tidy at the exact versions
PyPI --> Workflow: Tools installed
alt no C or C++ file is tracked
Workflow --> Caller: Notice: nothing was checked, pass
else no .clang-format, or compile-commands-dir\nwithout compile_commands.json
Workflow --> Caller: Fail with [configuration]
else
Workflow -> Workflow: clang-format --dry-run -Werror on all files
Workflow -> Workflow: clang-tidy on the C++ files (-std=std)\nand on the C files (or with the compile database)
alt any tool failed
Workflow --> Caller: Fail with tool, file and line in the log
else
Workflow --> Caller: All selected checks passed
end
end
deactivate Workflow
@enduml
```
### Quality checks C#
A reusable workflow for C#, called with `uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1` (ADR-0008). It installs the exact .NET SDK given by `dotnet-sdk-version` (10 or later) and needs the network for the package restore.
#### Workflow
```plantuml
@startuml
title Shared quality checks for C# (reusable workflow)
autonumber
actor "Calling repository\nuses: ...quality-checks-csharp.yml@v1" as Caller
participant "Gitea Actions\nquality-checks-csharp" as Workflow
participant "dot.net\n(dotnet-install.sh)" as DotNet
Caller -> Workflow: workflow_call with working-directory,\nproject and dotnet-sdk-version
activate Workflow
Workflow -> Workflow: Check out the caller and the shared script
Workflow -> Workflow: Validate the inputs
alt an input is invalid or the SDK is not an exact\nstable version 10 or later
Workflow --> Caller: Fail with [configuration]
end
Workflow -> DotNet: Install the exact .NET SDK version
DotNet --> Workflow: SDK installed
alt no C# file is tracked
Workflow --> Caller: Notice: nothing was checked, pass
else no solution or project, or several without the project input
Workflow --> Caller: Fail with [configuration] that names them
else
Workflow -> Workflow: dotnet format --verify-no-changes
Workflow -> Workflow: dotnet build -warnaserror\n(package restore needs the network)
alt any tool failed
Workflow --> Caller: Fail with tool, file and line in the log
else
Workflow --> Caller: All selected checks passed
end
end
deactivate Workflow
@enduml
```
### Release ### Release
Started by hand by a maintainer; with `dry_run` `true` (the default) it only checks (see the [release process](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/release-process.md)). Started by hand by a maintainer; with `dry_run` `true` (the default) it only checks (see the [release process](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/release-process.md)).
+95 -3
View File
@@ -1,4 +1,4 @@
<!-- translation of Home.md, source sha256 c9c04abaf4ae --> <!-- translation of Home.md, source sha256 5751829e99af -->
> Ini ialah terjemahan [`Home`](Home). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya. > Ini ialah terjemahan [`Home`](Home). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
@@ -13,18 +13,20 @@ Koleksi aliran kerja (workflow) Gitea Actions yang boleh digunakan semula untuk
Repositori ini ialah koleksi pusat bagi automasi yang boleh digunakan semula untuk repositori TirSystem. Repositori utama berada di `git.tirsystem.com` (Gitea) dan dicerminkan dengan push ke GitHub. Repositori ini ialah koleksi pusat bagi automasi yang boleh digunakan semula untuk repositori TirSystem. Repositori utama berada di `git.tirsystem.com` (Gitea) dan dicerminkan dengan push ke GitHub.
Ia mengandungi enam aliran kerja: penyegerakan metadata ke cermin GitHub, penerbitan wiki, semakan kualiti bersama, aliran kerja keluaran, penerbitan pencapaian (milestone) yang diterima dan pengesahan repositori sendiri. Ia disenaraikan dengan tujuan dan rajah di bawah [Aliran kerja](#aliran-kerja). Ia mengandungi lapan aliran kerja: penyegerakan metadata ke cermin GitHub, penerbitan wiki, semakan kualiti bersama untuk Python dan shell, untuk C dan C++ serta untuk C#, aliran kerja keluaran, penerbitan pencapaian (milestone) yang diterima dan pengesahan repositori sendiri. Ia disenaraikan dengan tujuan dan rajah di bawah [Aliran kerja](#aliran-kerja).
## Aliran kerja ## Aliran kerja
Terdapat enam aliran kerja dalam repositori ini. Aliran kerja **scoped** dihantar oleh instans ke setiap repositori organisasi TirSystem dan tidak memerlukan apa-apa dalam repositori; aliran kerja **boleh guna semula** dipanggil oleh sebuah repositori dengan `uses:`; yang lain hanya berjalan di sini. Rajah ialah kod sumber PlantUML dan dalam bahasa Inggeris. Terdapat lapan aliran kerja dalam repositori ini. Aliran kerja **scoped** dihantar oleh instans ke setiap repositori organisasi TirSystem dan tidak memerlukan apa-apa dalam repositori; aliran kerja **boleh guna semula** dipanggil oleh sebuah repositori dengan `uses:`; yang lain hanya berjalan di sini. Rajah ialah kod sumber PlantUML dan dalam bahasa Inggeris.
| Aliran kerja | Fail | Jenis | Bermula apabila | Tujuan | | Aliran kerja | Fail | Jenis | Bermula apabila | Tujuan |
| --- | --- | --- | --- | --- | | --- | --- | --- | --- | --- |
| Sync GitHub mirror metadata | [`sync-github-metadata.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/sync-github-metadata.yml) | Scoped | push ke `main`, manual, setiap hari 03:17 UTC | Menyalin penerangan dan topik repositori Gitea ke push mirror GitHub-nya | | Sync GitHub mirror metadata | [`sync-github-metadata.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/sync-github-metadata.yml) | Scoped | push ke `main`, manual, setiap hari 03:17 UTC | Menyalin penerangan dan topik repositori Gitea ke push mirror GitHub-nya |
| Publish wiki | [`publish-wiki.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/publish-wiki.yml) | Scoped, pilih menyertai dengan `wiki/.publish` | push ke `main` yang mengubah `wiki/**`, manual | Menerbitkan halaman dalam `wiki/` ke wiki repositori | | Publish wiki | [`publish-wiki.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/publish-wiki.yml) | Scoped, pilih menyertai dengan `wiki/.publish` | push ke `main` yang mengubah `wiki/**`, manual | Menerbitkan halaman dalam `wiki/` ke wiki repositori |
| Quality checks | [`quality-checks.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks.yml) | Boleh guna semula (`workflow_call`) | panggilan daripada repositori lain | Menjalankan ruff, mypy, shellcheck dan shfmt pada fail yang dijejaki dan tidak mengubah apa-apa | | Quality checks | [`quality-checks.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks.yml) | Boleh guna semula (`workflow_call`) | panggilan daripada repositori lain | Menjalankan ruff, mypy, shellcheck dan shfmt pada fail yang dijejaki dan tidak mengubah apa-apa |
| Quality checks C++ | [`quality-checks-cpp.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks-cpp.yml) | Boleh guna semula (`workflow_call`) | panggilan daripada repositori lain | Menjalankan clang-format dan clang-tidy pada versi tepat pada fail C dan C++ yang dijejaki dan tidak mengubah apa-apa |
| Quality checks C# | [`quality-checks-csharp.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks-csharp.yml) | Boleh guna semula (`workflow_call`) | panggilan daripada repositori lain | Menjalankan `dotnet format` dan `dotnet build` pada .NET SDK 10 atau lebih baharu yang tepat dan tidak mengubah apa-apa |
| Release | [`release.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/release.yml) | Repositori ini sahaja | manual | Mencipta tag versi, halaman keluaran dan tag major selepas semakan | | Release | [`release.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/release.yml) | Repositori ini sahaja | manual | Mencipta tag versi, halaman keluaran dan tag major selepas semakan |
| Menerbitkan milestone yang diterima | [`sync-milestones.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/sync-milestones.yml) | Repositori ini sahaja | push ke `main` yang mengubah `docs/milestones/**` atau `docs/sqa/reviews/**`, manual (larian percubaan secara lalai) | Mencipta atau mengemas kini milestone Gitea dan isu bagi setiap milestone yang Accepted dengan semakan Go | | Menerbitkan milestone yang diterima | [`sync-milestones.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/sync-milestones.yml) | Repositori ini sahaja | push ke `main` yang mengubah `docs/milestones/**` atau `docs/sqa/reviews/**`, manual (larian percubaan secara lalai) | Mencipta atau mengemas kini milestone Gitea dan isu bagi setiap milestone yang Accepted dengan semakan Go |
| Validate workflows | [`validate-workflows.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/validate-workflows.yml) | Repositori ini sahaja | pull request, push ke `main`, manual | Menghurai setiap aliran kerja sebagai YAML dan menjalankan ujian luar talian | | Validate workflows | [`validate-workflows.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/validate-workflows.yml) | Repositori ini sahaja | pull request, push ke `main`, manual | Menghurai setiap aliran kerja sebagai YAML dan menjalankan ujian luar talian |
@@ -185,6 +187,96 @@ deactivate Workflow
@enduml @enduml
``` ```
### Semakan kualiti C++
Aliran kerja boleh guna semula untuk C dan C++, dipanggil dengan `uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1` (ADR-0008). Repositori mesti mempunyai `.clang-format`; `.clang-tidy` dan pangkalan data kompilasi adalah pilihan.
#### Aliran kerja
```plantuml
@startuml
title Shared quality checks for C and C++ (reusable workflow)
autonumber
actor "Calling repository\nuses: ...quality-checks-cpp.yml@v1" as Caller
participant "Gitea Actions\nquality-checks-cpp" as Workflow
participant "PyPI" as PyPI
Caller -> Workflow: workflow_call with working-directory, std,\ncompile-commands-dir and tool versions
activate Workflow
Workflow -> Workflow: Check out the caller and the shared script
Workflow -> Workflow: Validate the inputs
alt an input is invalid or a version is not exact
Workflow --> Caller: Fail with [configuration]
end
Workflow -> PyPI: Install clang-format and clang-tidy at the exact versions
PyPI --> Workflow: Tools installed
alt no C or C++ file is tracked
Workflow --> Caller: Notice: nothing was checked, pass
else no .clang-format, or compile-commands-dir\nwithout compile_commands.json
Workflow --> Caller: Fail with [configuration]
else
Workflow -> Workflow: clang-format --dry-run -Werror on all files
Workflow -> Workflow: clang-tidy on the C++ files (-std=std)\nand on the C files (or with the compile database)
alt any tool failed
Workflow --> Caller: Fail with tool, file and line in the log
else
Workflow --> Caller: All selected checks passed
end
end
deactivate Workflow
@enduml
```
### Semakan kualiti C#
Aliran kerja boleh guna semula untuk C#, dipanggil dengan `uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1` (ADR-0008). Ia memasang .NET SDK tepat yang diberikan oleh `dotnet-sdk-version` (10 atau lebih baharu) dan memerlukan rangkaian untuk pemulihan pakej.
#### Aliran kerja
```plantuml
@startuml
title Shared quality checks for C# (reusable workflow)
autonumber
actor "Calling repository\nuses: ...quality-checks-csharp.yml@v1" as Caller
participant "Gitea Actions\nquality-checks-csharp" as Workflow
participant "dot.net\n(dotnet-install.sh)" as DotNet
Caller -> Workflow: workflow_call with working-directory,\nproject and dotnet-sdk-version
activate Workflow
Workflow -> Workflow: Check out the caller and the shared script
Workflow -> Workflow: Validate the inputs
alt an input is invalid or the SDK is not an exact\nstable version 10 or later
Workflow --> Caller: Fail with [configuration]
end
Workflow -> DotNet: Install the exact .NET SDK version
DotNet --> Workflow: SDK installed
alt no C# file is tracked
Workflow --> Caller: Notice: nothing was checked, pass
else no solution or project, or several without the project input
Workflow --> Caller: Fail with [configuration] that names them
else
Workflow -> Workflow: dotnet format --verify-no-changes
Workflow -> Workflow: dotnet build -warnaserror\n(package restore needs the network)
alt any tool failed
Workflow --> Caller: Fail with tool, file and line in the log
else
Workflow --> Caller: All selected checks passed
end
end
deactivate Workflow
@enduml
```
### Keluaran ### Keluaran
Dimulakan secara manual oleh penyelenggara; dengan `dry_run` `true` (lalai) ia hanya menyemak (lihat [proses keluaran](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/release-process.md)). Dimulakan secara manual oleh penyelenggara; dengan `dry_run` `true` (lalai) ia hanya menyemak (lihat [proses keluaran](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/release-process.md)).
+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 baf659e82523 -->
> 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 workflowet compilerdiagnostik og den statiske analysator (`clang-diagnostic-*` og `clang-analyzer-*`), fordi clang-tidy selv ikke aktiverer nogen kontrol uden konfiguration.
- 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` (eller fra `clang-diagnostic-*` og `clang-analyzer-*` uden en); `*.c`-filer kontrolleres som C17, de øvrige filer som C++-standarden i `std`; hvert fund er en fejl (`--warnings-as-errors=*`), så en advarsel får kørslen til at fejle |
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) |
+106
View File
@@ -0,0 +1,106 @@
<!-- 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 the workflow runs the compiler diagnostics
and the static analyzer (`clang-diagnostic-*` and `clang-analyzer-*`),
because clang-tidy itself enables no check when there is no configuration.
- 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` (or of `clang-diagnostic-*` and `clang-analyzer-*` without one); `*.c` files are checked as C17, the other files as the C++ standard of `std`; every finding is an error (`--warnings-as-errors=*`), so a warning fails the run |
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 baf659e82523 -->
> 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 aliran kerja menjalankan diagnostik pengkompil dan penganalisis statik (`clang-diagnostic-*` dan `clang-analyzer-*`), kerana clang-tidy sendiri tidak mengaktifkan sebarang semakan tanpa konfigurasi.
- 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` (atau `clang-diagnostic-*` dan `clang-analyzer-*` tanpanya); fail `*.c` disemak sebagai C17, fail lain sebagai piawaian C++ dalam `std`; setiap dapatan ialah ralat (`--warnings-as-errors=*`), jadi amaran menggagalkan larian |
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)