CI: ci.yml Windows-matrix uitlijnen met release.yml — windows-2022-pin mogelijk overbodig na dartcv4 2.x (#870) #888

New issue

Closed

opened 2026-07-26 13:13:11 +00:00 by brenno · 1 comment

brenno commented

2026-07-26 13:13:11 +00:00

Owner

Wat

Na de migratie naar dartcv4 2.x (#870, gemerged via #873) spreken de twee
GitHub-workflows elkaar tegen over de Windows-runner:

.github/workflows/release.yml (regel 40): pin opgeheven naar
runs-on: windows-latest. De bijbehorende comment (regels 37-39) stelt dat
dartcv4 2.x OpenCV via native-assets build-hooks (CMake) levert i.p.v. een
voorgebouwd pack, "dus de MSVC-compatibiliteit die de windows-2022 pin
noodzakelijk maakte is niet meer van toepassing (#870)".
.github/workflows/ci.yml (regel 274): matrix staat nog op
os: [macos-latest, windows-2022]. De comment daarboven (regels 265-273) zegt
juist: "Los deze pin pas wanneer upstream dartcv een pakket voor nieuwere
MSVC's uitbrengt — dat pad (migratie naar dartcv4 2.x) is afzonderlijk
getrackt." Dat pad is nu net geland.

Hoe dit ontstond: de dartcv4-tak liftte de pin in release.yml, maar raakte de
matrix in ci.yml niet; de windows-2022-pin in ci.yml kwam via een parallelle
main-wijziging binnen. Bij de rebase/merge van #873 is dat niet samengebracht.

Waarom het ertoe doet

Eén van beide comments is nu onjuist, en de twee workflows bouwen Windows op
verschillende images. Of windows-latest echt veilig is, is nog niet
aantoonbaar: release.yml draait alleen op release/tag, dus die "probe" op
windows-latest heeft mogelijk nog niet groen gedraaid. ci.yml blind naar
windows-latest tillen kan de Windows-PR-CI op de GitHub-spiegel breken als de
build daar toch valt op "Found OpenCV Windows Pack but it has no binaries
compatible with your configuration".

Voorstel

Bevestig dat flutter build windows --debug op windows-latest met
dartcv4 2.x daadwerkelijk slaagt (een release-probe of een tijdelijke
test-run op de spiegel).
Als groen: zet ci.yml's matrix ook op windows-latest en verwijder de
verouderde pin-comment (regels 265-273), zodat beide workflows overeenkomen.
Als niet groen: draai release.yml terug naar windows-2022 en scherp
beide comments aan, zodat ze elkaar niet tegenspreken.

Verwijzingen

ci.yml: .github/workflows/ci.yml regels 265-274
release.yml: .github/workflows/release.yml regels 37-40
Migratie: #870 (issue), #873 (PR), oorspronkelijke pin: #788

Aangemaakt als opvolging van de merge van #873.

## Wat Na de migratie naar dartcv4 2.x (#870, gemerged via #873) spreken de twee GitHub-workflows elkaar tegen over de Windows-runner: - **`.github/workflows/release.yml`** (regel 40): pin **opgeheven** naar `runs-on: windows-latest`. De bijbehorende comment (regels 37-39) stelt dat dartcv4 2.x OpenCV via native-assets build-hooks (CMake) levert i.p.v. een voorgebouwd pack, "dus de MSVC-compatibiliteit die de windows-2022 pin noodzakelijk maakte is niet meer van toepassing (#870)". - **`.github/workflows/ci.yml`** (regel 274): matrix staat nog op `os: [macos-latest, windows-2022]`. De comment daarboven (regels 265-273) zegt juist: "Los deze pin pas wanneer upstream dartcv een pakket voor nieuwere MSVC's uitbrengt — dat pad (migratie naar dartcv4 2.x) is afzonderlijk getrackt." Dat pad is nu net geland. Hoe dit ontstond: de dartcv4-tak liftte de pin in release.yml, maar raakte de matrix in ci.yml niet; de `windows-2022`-pin in ci.yml kwam via een parallelle main-wijziging binnen. Bij de rebase/merge van #873 is dat niet samengebracht. ## Waarom het ertoe doet Eén van beide comments is nu onjuist, en de twee workflows bouwen Windows op verschillende images. Of `windows-latest` echt veilig is, is nog niet aantoonbaar: release.yml draait alleen op release/tag, dus die "probe" op `windows-latest` heeft mogelijk nog niet groen gedraaid. ci.yml blind naar `windows-latest` tillen kan de Windows-PR-CI op de GitHub-spiegel breken als de build daar toch valt op "Found OpenCV Windows Pack but it has no binaries compatible with your configuration". ## Voorstel 1. Bevestig dat `flutter build windows --debug` op **windows-latest** met dartcv4 2.x daadwerkelijk slaagt (een release-probe of een tijdelijke test-run op de spiegel). 2. **Als groen:** zet ci.yml's matrix ook op `windows-latest` en verwijder de verouderde pin-comment (regels 265-273), zodat beide workflows overeenkomen. 3. **Als niet groen:** draai release.yml terug naar `windows-2022` en scherp beide comments aan, zodat ze elkaar niet tegenspreken. ## Verwijzingen - ci.yml: `.github/workflows/ci.yml` regels 265-274 - release.yml: `.github/workflows/release.yml` regels 37-40 - Migratie: #870 (issue), #873 (PR), oorspronkelijke pin: #788 _Aangemaakt als opvolging van de merge van #873._

brenno added the

triage

label

2026-07-26 13:13:11 +00:00

brenno referenced this issue from a commit

2026-07-26 13:18:11 +00:00

test(ci): probe windows-latest voor de dartcv4 2.x Windows-build (#888)

brenno referenced this issue

2026-07-26 14:10:08 +00:00

fix(ci): vind de macOS dartcv-frameworkbinary i.p.v. een niet-bestaand pad #891

brenno commented

2026-07-26 14:27:12 +00:00

Author

Owner

Verificatie: windows-latest bouwt groen (pin is liftbaar).

Een probe-tak (ci.yml-matrix op windows-latest, vanaf main mét dartcv4 2.x) op de GitHub-spiegel:

Test (windows-latest): 6631 geslaagd, 15 gefaald, 5 overgeslagen — de build slaagt en de OpenCV/dartcv4-laag laadt.
Test (windows-2022) (baseline, zelfde commit): identiek 6631/15/5.

De dartcv4 2.x native-assets-build haalt het MSVC-compat-probleem weg dat de pin nodig maakte; windows-latest en -2022 bouwen aantoonbaar identiek. De lift in release.yml is daarmee gevalideerd.

De 15 falende tests zijn image-onafhankelijk (identiek op beide) — een aparte Windows-pad/portabiliteitskwestie, geen reden om de pin te houden.

Besluit voorlopig: de pin niet nu liften; meenemen bij de bredere CV/CI-rework (zie ook de macOS-native-laag-bevinding). Dit ticket blijft open als vastlegging dat het kán.

**Verificatie: windows-latest bouwt groen (pin is liftbaar).** Een probe-tak (ci.yml-matrix op `windows-latest`, vanaf main mét dartcv4 2.x) op de GitHub-spiegel: - `Test (windows-latest)`: **6631 geslaagd, 15 gefaald, 5 overgeslagen** — de build slaagt en de OpenCV/dartcv4-laag laadt. - `Test (windows-2022)` (baseline, zelfde commit): **identiek** 6631/15/5. De dartcv4 2.x native-assets-build haalt het MSVC-compat-probleem weg dat de pin nodig maakte; windows-latest en -2022 bouwen aantoonbaar identiek. De lift in `release.yml` is daarmee gevalideerd. De 15 falende tests zijn **image-onafhankelijk** (identiek op beide) — een aparte Windows-pad/portabiliteitskwestie, geen reden om de pin te houden. **Besluit voorlopig:** de pin niet nu liften; meenemen bij de bredere CV/CI-rework (zie ook de macOS-native-laag-bevinding). Dit ticket blijft open als vastlegging dat het kán.

brenno closed this issue

2026-07-26 16:06:49 +00:00