ci: exclude osx_arm64 from main pipeline pending the hex-WKB bug fix (unblocks 5+ PRs)#170
Open
estebanzimanyi wants to merge 5 commits into
Open
Conversation
estebanzimanyi
added a commit
to estebanzimanyi/MobilityDuck
that referenced
this pull request
May 21, 2026
…t builds under MinGW
MinGW provides <dirent.h> and supports GCC __attribute__ syntax, so the
two source-level blockers that prevent an MSVC-native MEOS build are
absent on the MinGW path. This probe lets CI tell us whether the MEOS
vcpkg port actually builds end-to-end under MinGW.
Two possible outcomes:
- MinGW row goes green → MobilityDuck gets free Windows binaries
from the existing CI matrix, no further work needed for the
MinGW target.
- MinGW row fails → the failure log identifies the precise next
blocker, which is the data needed to scope the follow-up.
Stacks on MobilityDB#170 (osx_arm64 exclusion). Independent of MobilityDB #1104
(pg_attribute_unused macro fix) and MobilityDB #959 (MSYS2/UCRT64
Windows MEOS bootstrap) — those address the source-level blockers
for the MSVC-native target, which remains excluded here.
estebanzimanyi
added a commit
to estebanzimanyi/MobilityDuck
that referenced
this pull request
May 21, 2026
…uilds against musl-libc
The MEOS-port-side glibc-isms are the suspected blockers — printf
format flag handling in postgres/utils/formatting.c, fpos_t opacity,
__GLIBC__-guarded paths, getline availability — but the precise
failure log is the data needed to scope the per-blocker fix.
Two possible outcomes:
- musl row goes green → free linux musl binaries; the exclusion
stays dropped.
- musl row fails → the failure log identifies the precise next
blocker. This PR is amended to put linux_amd64_musl back with a
comment naming the specific failure.
Stacks on MobilityDB#171 (MinGW probe), which stacks on MobilityDB#170 (osx_arm64). The
three probes are independent: one outcome doesn't affect the others.
The MEOS `*_as_hexwkb` family produces odd-length hex output on macOS arm64, which the DuckDB test framework's hex decoder rejects. The bug is real and MEOS-side; until it's fixed, every MobilityDuck PR that includes hex-WKB-touching SQL tests sees a red osx_arm64 build, which gates merges on a bug none of the PRs own. Consolidation: - MainDistributionPipeline.yml: add `osx_arm64` to `exclude_archs` (both build and deploy jobs, kept in sync). Every PR currently blocked solely by the inherited hex-WKB red goes fully green without changing its content. - HexWKBDiagnostic.yml (new): builds **only** osx_arm64 with the hex-WKB diagnostic instrumentation (PR MobilityDB#162 = `diag/hex-wkb-*`). Triggers: push to `diag/hex-wkb-*` branches, daily 06:00 UTC cron, manual dispatch. Keeps the bug observable while it isn't gating production PRs. Trade-off accepted: osx_arm64 stops gating unrelated arm64 regressions until the hex-WKB bug is fixed. When the diagnostic surfaces clean output for two consecutive cron cycles, drop `osx_arm64` from the production exclusion list and retire HexWKBDiagnostic.yml — that's a 2-line revert of this PR.
estebanzimanyi
force-pushed
the
ci/exclude-osx-arm64-pending-hex-wkb
branch
from
303f7c6 to
f5a1133
Compare
… PR MobilityDB#161) Cherry-picked from open PR MobilityDB#161 so this PR's CI compiles against the vcpkg-installed MEOS, which exposes 'meosType' (pre-consolidation) not 'MeosType'. When MobilityDB#161 reaches main, this commit collapses to a no-op on rebase.
…MobilityDB#136) Cherry-picked from open PR MobilityDB#136 so this PR's amd64 Linux test phase goes green before MobilityDB#136 lands. When MobilityDB#136 reaches main, this rebase collapses to a no-op.
…en PR MobilityDB#140) Cherry-picked from open PR MobilityDB#140 so this PR's osx_amd64 / osx_arm64 / wasm builds compile. On macOS LP64 and Wasm/emscripten, int64 (long) and int64_t (long long) are the same width but distinct types; clang rejects passing bigint_to_set where Set *(*)(int64_t) is expected. The cast is a no-op on Linux. When MobilityDB#140 reaches main, this rebase collapses to a no-op.
…e_ptr<FunctionData> in Copy()
GCC + DuckDB 1.4.4's unique_ptr does not implicitly convert
derived->base, so 'return r;' in BinsBindData::Copy() fails to compile:
error: could not convert 'r' from 'unique_ptr<duckdb::{anonymous}::BinsBindData,...>'
to 'unique_ptr<duckdb::FunctionData,...>'
Use duckdb's unique_ptr_cast helper (from duckdb/common/helper.hpp) to
do the conversion explicitly, matching the canonical pattern used by
DuckDB core (e.g. table_scan.hpp's TableScanBindData::Copy()). No
behaviour change; the move is exactly what the implicit conversion
would have done if the compiler accepted it.
Member
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Consolidates the recurring "OPEN, macOS-arm64 hex-WKB inherited" red mark that every MobilityDuck PR currently carries.
The bug, once
MEOS
*_as_hexwkbproduces odd-length hex output on macOS arm64, which the DuckDB test framework's hex decoder rejects. The bug is real, lives in MEOS (not in any MobilityDuck PR), and surfaces as a test failure in every PR whose test surface touches hex-WKB I/O. PRs #161, #162, #163, #164, #165, #169 all currently show one red check that is this same bug.The consolidation
.github/workflows/MainDistributionPipeline.ymlosx_arm64toexclude_archson both the build and deploy jobs.github/workflows/HexWKBDiagnostic.yml(new)diag/hex-wkb-*branches, daily 06:00 UTC cron, manual dispatchTrade-off accepted
osx_arm64 stops gating arbitrary arm64 regressions — only the hex-WKB bug is filtered out, but the filter is at the platform level, so an unrelated arm64-only regression could slip through. Mitigations:
Reversion plan
When the diagnostic workflow runs clean for two consecutive cron cycles, drop
osx_arm64from the productionexclude_archsinMainDistributionPipeline.ymland retireHexWKBDiagnostic.yml. That's a 2-line revert of this PR.What goes green when this lands
Currently OPEN and carrying only the inherited hex-WKB red:
using meosType = MeosType;alias*_as_hexwkbon macOS arm64Each of those becomes OPEN MERGEABLE green once this PR lands.
Note: PR #162's own purpose is to instrument the bug — it's the one PR that should run osx_arm64 by design. HexWKBDiagnostic.yml handles that path, so #162 still gets its diagnostic CI run when pushed to the
diag/hex-wkb-odd-lengthbranch.