Skip to content

Commit 01f537c

Browse files
KSemenenkoKSemenenko
committed
Enforce warnaserror in CI build
1 parent 443ee45 commit 01f537c

File tree

3 files changed

+90
-5
lines changed

3 files changed

+90
-5
lines changed

‎.github/workflows/build-validation.yml‎

Lines changed: 0 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -39,10 +39,6 @@ jobs:
3939
run: dotnet format DotPilot.slnx --verify-no-changes
4040

4141
- name: Build
42-
shell: pwsh
43-
run: dotnet build DotPilot.slnx
44-
45-
- name: Analyze
4642
shell: pwsh
4743
run: dotnet build DotPilot.slnx -warnaserror
4844

‎AGENTS.md‎

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -120,7 +120,7 @@ Skill-management rules for this `.NET` solution:
120120

121121
### Commands
122122

123-
- `build`: `dotnet build DotPilot.slnx`
123+
- `build`: `dotnet build DotPilot.slnx -warnaserror`
124124
- `test`: `dotnet test DotPilot.slnx`
125125
- `format`: `dotnet format DotPilot.slnx --verify-no-changes`
126126
- `analyze`: `dotnet build DotPilot.slnx -warnaserror`
@@ -137,13 +137,15 @@ For this app:
137137
- desktop release publishing uses `dotnet publish DotPilot/DotPilot.csproj -c Release -f net10.0-desktop`; the validation workflow stays focused on build and automated tests, while the release workflow owns desktop publish outputs for macOS, Windows, and Linux
138138
- `LangVersion` is pinned to `latest` at the root
139139
- the repo-root lowercase `.editorconfig` is the source of truth for formatting, naming, style, and analyzer severity
140+
- local and CI build commands must pass `-warnaserror`; warnings are not an acceptable "green" build state in this repository
140141
- `Directory.Build.props` owns the shared analyzer and warning policy for future projects
141142
- `Directory.Packages.props` owns centrally managed package versions
142143
- `global.json` pins the .NET SDK and Uno SDK version used by the app and tests
143144
- `DotPilot/DotPilot.csproj` keeps `GenerateDocumentationFile=true` with `CS1591` suppressed so `IDE0005` stays enforceable in CI across all target frameworks without inventing command-line-only build flags
144145
- GitHub Actions workflows must use descriptive names and filenames that reflect their purpose; do not use a generic `ci.yml` catch-all because build validation and release automation are separate operator flows
145146
- GitHub Actions must be split into at least one validation workflow for normal builds/tests and one release workflow for CI-driven version resolution, release-note generation, desktop publishing, and GitHub Release publication
146147
- the release workflow must run automatically on pushes to `main`, build desktop apps, and publish the GitHub Release without requiring a manual dispatch
148+
- desktop app build or publish jobs must use native runners for their target OS: macOS artifacts on macOS runners, Windows artifacts on Windows runners, and Linux artifacts on Linux runners
147149
- desktop release versions must use the `ApplicationDisplayVersion` value in `DotPilot/DotPilot.csproj` as a manually maintained two-segment prefix, with CI appending the final segment from the build number (for example `0.0.<build-number>`)
148150
- the release workflow must not take ownership of the first two version segments; those remain manually edited in source, while CI supplies only the last numeric segment and matching release tag/application version values
149151
- for CI and release automation in this solution, prefer existing `dotnet` and `MSBuild` capabilities plus small workflow-native steps over Python or adding a separate helper project for simple versioning and release-note tasks

‎github-actions-yaml-review.plan.md‎

Lines changed: 87 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
# GitHub Actions YAML Review Plan
2+
3+
## Goal
4+
5+
Review the current GitHub Actions validation and release workflows, record concrete risks with line-level evidence, and capture any durable CI policy that emerged from the user conversation, including mandatory `-warnaserror` enforcement for local and CI builds.
6+
7+
## Scope
8+
9+
### In Scope
10+
11+
- `.github/workflows/build-validation.yml`
12+
- `.github/workflows/release-publish.yml`
13+
- shared workflow assumptions from `.github/steps/install_dependencies/action.yml`
14+
- root governance updates needed to capture durable CI runner policy and mandatory `-warnaserror` build usage
15+
16+
### Out Of Scope
17+
18+
- application code changes unrelated to CI/CD
19+
- release-note content changes
20+
- speculative platform changes without a concrete workflow finding
21+
22+
## Constraints And Risks
23+
24+
- The review must focus on real failure or operability risks, not styling-only nits.
25+
- Findings must use exact file references and line numbers.
26+
- Desktop builds must stay on native OS runners for the target artifact.
27+
28+
## Testing Methodology
29+
30+
- Static review of workflow logic, trigger model, runner selection, packaging steps, and rerun behavior
31+
- Validation commands for any touched YAML or policy file:
32+
- `dotnet build DotPilot.slnx -warnaserror`
33+
- `actionlint .github/workflows/build-validation.yml`
34+
- `actionlint .github/workflows/release-publish.yml`
35+
- Quality bar:
36+
- every reported finding must describe a user-visible or operator-visible failure mode
37+
- no finding should rely on vague “could be cleaner” arguments
38+
39+
## Ordered Plan
40+
41+
- [x] Step 1: Read the current workflows, shared composite action, and relevant governance/docs.
42+
Verification:
43+
- inspect the workflow YAML and shared action with line numbers
44+
- inspect the nearest architecture/ADR references for the intended CI split
45+
Done when: the current workflow intent and boundaries are clear.
46+
47+
- [x] Step 2: Record durable policy from the latest user instruction.
48+
Verification:
49+
- update `AGENTS.md` with the native-runner rule for desktop build/publish jobs
50+
- update `AGENTS.md` with mandatory `-warnaserror` usage for local and CI builds
51+
Done when: the rules are present in root governance.
52+
53+
- [x] Step 3: Apply the explicitly requested CI warning-policy fix.
54+
Verification:
55+
- `build-validation.yml` runs the build step with `-warnaserror`
56+
- no duplicate non-value build step remains after the change
57+
Done when: CI and local build policy both require `-warnaserror`.
58+
59+
- [x] Step 4: Produce the workflow review findings.
60+
Verification:
61+
- findings reference exact files and lines
62+
- findings are ordered by severity
63+
Done when: the user can act on the review without needing another pass to discover the real problems.
64+
65+
- [x] Step 5: Validate touched YAML/policy files.
66+
Verification:
67+
- `dotnet build DotPilot.slnx -warnaserror`
68+
- `actionlint .github/workflows/build-validation.yml`
69+
- `actionlint .github/workflows/release-publish.yml`
70+
Done when: touched workflow files still parse cleanly.
71+
72+
## Full-Test Baseline Step
73+
74+
- [x] Capture the current workflow state before proposing changes.
75+
Done when: the review is grounded in the current checked-in YAML, not stale assumptions.
76+
77+
## Failing Tests And Checks Tracker
78+
79+
- [x] None currently tracked for this review-only pass.
80+
81+
## Final Validation Skills
82+
83+
1. `mcaf-ci-cd`
84+
Reason: review CI/release workflow structure and operator risks.
85+
86+
2. `mcaf-testing`
87+
Reason: ensure the review respects the repo verification model and required test gates.

0 commit comments

Comments
 (0)