MSI installer, semantic versioning, and GitHub Releases#286
MSI installer, semantic versioning, and GitHub Releases#286irodushka merged 13 commits intoFirebirdSQL:masterfrom
Conversation
|
Test builds available at https://github.com/fdcastel/firebird-odbc-driver/releases/tag/v3.5.0-rc1 |
…add release workflow - Add WiX v4 installer (installer/Product.wxs) for x64 ODBC driver registration - Support Debug builds with alternate driver name for side-by-side install - Add release.yml workflow: triggered on v* tags, creates GitHub Release with MSI, ZIP (Windows) and tar.gz (Linux) assets; detects pre-release tags - Update build-and-test.yml: add workflow_call trigger, run on all branches, use consistent artifact names (windows-x64-binaries, linux-x64-binaries) - Update GetVersionFromGit.cmake to handle pre-release tags (e.g. v3.5.0-rc1) - Update SetupAttributes.h to use Version.h instead of WriteBuildNo.h - Remove old InnoSetup installer (Install/Win32/) - Remove old msbuild.yml and msbuild_arm64.yaml workflows - Remove WriteBuildNo.h (version now comes entirely from git tags)
Add tags-ignore to build-and-test.yml so tag pushes only trigger the Release workflow (which calls build-and-test via workflow_call).
- Remove Builds/MsVc2022.win/ (old MSBuild solution, superseded by CMake) - Update README.md: replace v3.0 header/intro with current description, replace old Downloads section (InnoSetup zip + MSBuild badge) with GitHub Releases link, fix VS build instructions to use CMake-generated solution instead of deleted Builds/MsVc2022.win/OdbcFb.sln - Update tests/README.md: replace MsVc2022.win build reference with Invoke-Build install instruction - Clean up stale Install/Win32/install_image/ entry from .gitignore
|
Rebased onto the latest |
|
So, what about linux-arm64 & win32 builds? |
|
And another issue. Due to FB headers being loaded while CMake is running, I can't build the latest driver on an isolated host that doesn't have access to GitHub. This is not good... |
The same story with the google test. |
Run Invoke-Build test -Configuration Release -File ./firebird-odbc-driver.build.ps1 oh oh oh... |
|
This doesn’t look right. I must have made some mess. I’m currently abroad and can’t review it right now. Please hold. |
- Quote -DCMAKE_BUILD_TYPE arg in build script to fix PowerShell parameter parsing (was passing literal '\' instead of the resolved value, resulting in unoptimized 4MB .so on Linux) - Allow pre-installed Firebird headers via -DFIREBIRD_INCLUDE_DIR=path, skipping FetchContent download (enables air-gapped builds) - Use find_package(GTest) first, fall back to FetchContent only when not found (enables builds without internet access)
The current CI matrix builds x64 only (Windows + Linux). This matches the CMake build system scope: it produces
UPDATE: Adding linux-arm64 CI now. UPDATE 2: I’ve reconsidered and realized I was mistaken. Win32 support is necessary. Even though I haven’t personally encountered a 32-bit Windows system in over a decade, the ODBC driver may still be needed for legacy 32-bit applications. I will work on this later. |
Bug. Fixed. In PowerShell, bare tokens starting with After fix: |
|
Done. FetchContent is only used as a fallback when GTest is not installed: Air-gapped builds can pre-install GTest (e.g. |
This was the literal |
fdcastel
force-pushed
the
new-installer
branch
2 times, most recently
from
8a6b3b7 to
f6440b5
Compare
- Add ubuntu-22.04-arm runner to build-and-test.yml matrix
- Upload linux-arm64-binaries artifact from arm64 job
- Add package-linux-arm64 job to release.yml that packages
and uploads firebird-odbc-driver-{version}-linux-arm64.tar.gz
|
linux-arm64 is now included. The CI matrix builds and tests on 3 runners: Builds |
- Add Win32 and ARM64 matrix entries to build-and-test.yml (ARM64 is cross-compiled, build-only without tests) - Add -Architecture parameter to build script, passed as -A to cmake - Use CMAKE_SYSTEM_PROCESSOR for arch detection (correct for cross-compile) - Make Product.wxs arch-aware: SystemFolder for x86, System64Folder for x64/arm64, unique UpgradeCode per architecture for side-by-side install - Refactor release.yml package-windows into a matrix job (x64/x86/arm64) producing MSI + ZIP for each architecture
|
Release 8 release assets across 5 architectures:
Key changes:
|
- Win32 (x86): register driver under WOW6432Node for 32-bit ODBC Driver Manager; use PSFirebird win-x86 RID for x86 Firebird binaries - Windows ARM64: test on windows-11-arm with x64 build + x64 Firebird via emulation (no ARM64 Firebird Windows binaries exist yet); keep cross-compile on windows-latest for ARM64 release artifact - Add FirebirdRid mapping: Win32->win-x86, ARM64->win-x64 (emulation) - Require PSFirebird >= 1.1.0 (x86/ARM64 support)
CI matrix ({windows-2022/x64, windows-2022/x86, windows-11-arm/ARM64,
ubuntu-22.04/x64, ubuntu-22.04-arm/arm64} x {Firebird 5.0.3, master}):
- Remove cross-compile job (was: windows-latest ARM64 build-only)
- windows-11-arm now runs natively as ARM64; master branch only
(no official Firebird 5 win-arm64 binaries)
- FIREBIRD_VERSION / FIREBIRD_BRANCH env vars drive PSFirebird selection
- Require PSFirebird >= 1.2.1 (Bug 1-3, Suggestion 6-8 fixes)
Skip 19 tests broken on Firebird 6 (parameterized query regression):
- DataTypeTest: VarcharRoundTrip, ParameterizedInsertAndSelect
- ParamConversionsTest: CharToInteger/Smallint/Float/Double/Char,
SmallintMaxValue, CharWithQuotes, NumericAsCharParam
- PrepareTest: PrepareWithTextParam, PrepareInsert
- DataAtExecutionTest: SingleVarcharParam, TwoVarcharParams,
InsertWithDAE, PutDataMultipleChunks
- ArrayBindingTest: RowWiseInsert, RowWiseMultipleTypes,
ParamsetSizeOneIsNormal
Add SKIP_ON_FIREBIRD6() macro to test_helpers.h (queries SQL_DBMS_VER)
|
Enabled full native build+test CI for Windows x86 (Win32) and Windows ARM64. All jobs build and test the driver binary that actually runs on the target platform -- no cross-compilation, no emulation. CI Matrix (current)9 jobs × {architecture} × {Firebird version}:
All 9 jobs build and test the native binary. Artifacts are uploaded only from the stable-version jobs (Firebird 5.0.3). The Problem 1: Win32 (x86) — ODBC Driver Not FoundOn 64-bit Windows there are two separate ODBC Driver Managers:
Fix: Made $regBase = if ($Architecture -eq 'Win32') {
'HKLM:\SOFTWARE\WOW6432Node\ODBC\ODBCINST.INI'
} else {
'HKLM:\SOFTWARE\ODBC\ODBCINST.INI'
}The x86 test also requires a 32-bit Problem 2: Win ARM64 — No Firebird ARM64 Client Library (Official Releases)Firebird's official stable releases (5.0.x, 4.0.x, 3.0.x) do not include a functional Windows ARM64 server/client. The PSFirebird v1.2.0 added On the
The Problem 3: Win ARM64 — 19 Tests Skipped on Firebird 6When the ARM64 job first ran, 19 tests failed (356/375 passed): All 19 failures involve parameterized queries (
Root CauseThese tests fail against Firebird 6 (snapshot) and pass against Firebird 5.0.3. The ODBC driver's handling of parameterized statement descriptors (XSQLDA) is incompatible with a protocol or API change in Firebird 6. This is not an ARM64-specific bug — the same failures appear on This is a driver compatibility issue to be addressed separately. Fix: Added inline int GetServerMajorVersion(SQLHDBC hDbc) {
SQLCHAR version[32] = {};
SQLSMALLINT len = 0;
SQLGetInfo(hDbc, SQL_DBMS_VER, version, sizeof(version), &len);
return std::atoi((char*)version); // "06.00.1884" → 6
}
#define SKIP_ON_FIREBIRD6() \
do { \
if (GetServerMajorVersion(hDbc) >= 6) { \
GTEST_SKIP() << "Broken on Firebird 6 (parameterized query incompatibility - TODO: fix)"; \
} \
} while (0)Added On Firebird 5.0.3: all 375 tests pass. |
|
v3.5.0-rc4 is published at https://github.com/fdcastel/firebird-odbc-driver/releases/tag/v3.5.0-rc4 Changes made to release.yml:
|
|
Hi @fdcastel So many changes! Great job |
|
A few thoughts on the win32 driver. The reason I was so anxious about it is related to the prod INNOSETUP installer logic - the win x64 installer includes both x64 & win32 libs and it installs them simultaneously, to System32 and SysWOW64 resp. This means that, after this, both 32-bit and 64-bit Windows apps will use the same ODBC driver build version. This logic is expected and familiar. But, if I understand correctly, with the new approach the client will have to install drivers for x64 and win32 separately, right? And these changes in behavior may lead to misunderstanding and issues... |
|
That’s exactly why: a) You need a second pair of eyes 👀 @irodushka Yep, you are right: the 64-bit installer must install both drivers (32 and 64-bit). I've completely forgot this. I will fix this in a few hours. |
|
I'm also pleased to confirm that a manual Linux build configured to use the pre-installed FB headers and the gtest-devel package was successful. The test suite also ran without issue. |
|
I think we should run all our tests
It will help us to maintain the code purity. I just found a buffer overflow bug in legacy code (maybe it's already fixed in the futher PRs) while running tests with ASAN. P.S. Even 2 bugs) |
|
Nice! I was familiar with Valgrind, but I hadn’t heard of ASAN before. I’ll look into both. |
|
The best way is to add the custom cmake types (like DebugWithAsan & DebugWithValgrind), both with -O0, -g3 and no extra logging. It's ok to use simple Debug type for Valgrind run, if the extra logs aren't annoying. ASAN build is special due to the use of special flags & linkage. Perhaps it would be more efficient if I modify the CMake files and you handle the Windows installer?.. and of cause all that sanitizer stuff may be merged after this PR, no deps here. Do you expect any merge issues if I make changes to the master branch? |
UPDATE: Actually, on second thought… never mind. No need to touch this PR since it’s about the installers. Go ahead with the CMake changes, but please do it on a separate branch and open a PR: that’ll be much easier to manage than working directly on |
|
I’m working on merging the 32-bit and 64-bit installers, now. |
The x64 MSI now installs both the native 64-bit driver (System32) and the 32-bit driver (SysWOW64), matching the old InnoSetup behavior. Both 64-bit and WoW64 32-bit applications can use the ODBC driver after a single install. Changes: - Product.wxs: x64 builds include DriverPathX86 components with Bitness='always32' for the 32-bit DLL and WOW6432Node registry entries - release.yml: x64 package-windows job downloads both x64 and x86 artifacts; passes DriverPathX86 to WiX; includes x86/ subfolder in ZIP - release.yml: new test-installer job verifies MSI install/uninstall and checks both 64-bit and 32-bit ODBC driver registrations for x64 MSI
|
Done! 1. Installer bundle (32-bit and 64-bit versions in one .msi)The x64 MSI now installs both the native 64-bit and the 32-bit driver in a single install — matching the old InnoSetup behavior:
After installing the x64 MSI, both 64-bit native and WoW64 32-bit applications will find the driver via their respective ODBC Driver Managers. How it works
The x86-only and ARM64 MSI installers remain single-architecture (unchanged). 2. New test for WiX installerAdded a new
This doesn't test actual ODBC connectivity (no Firebird server in the packaging job), but it validates the MSI install/uninstall cycle and driver registration correctness — which is exactly what was missing. |
|
v3.5.0-rc5 is published at https://github.com/fdcastel/firebird-odbc-driver/releases/tag/v3.5.0-rc5 |
LGTM now. 🎉 |
|
Just tested the release-candidate CI. Fantastic. |
Glad to be of service! 😄 |
2 participants
Closes #258
Closes #231
Closes #277
Summary
This PR replaces the old InnoSetup-based installer and ad-hoc artifact uploads with a proper WiX v4 MSI installer, a GitHub Releases publishing pipeline, and semantic versioning driven entirely by git tags.
Changes
New: WiX MSI installer (
installer/Product.wxs)Install/Win32/OdbcJdbcSetup.iss(InnoSetup).HKLM\SOFTWARE\ODBC), so the driver appears inodbcad32automatically.Configuration=Debugregisters the driver as Firebird ODBC Driver (Debug) with a distinct component GUID.wix build -d ProductVersion=X.Y.Z.0 -d DriverPath=path\to\FirebirdODBC.dll -d Configuration=Release -arch x64 -o output.msi installer/Product.wxsNew:
release.ymlworkflowTriggered on any
v*tag (e.g.v3.5.0,v3.5.0-rc1):workflow_call.-(e.g.-rc1,-beta1) are created as pre-releases..tar.gzwith a sampleodbcinst.ini, and uploads it as a release asset.Release asset names:
firebird-odbc-driver-{version}-{os}-{arch}.{ext}firebird-odbc-driver-3.5.0-win-x64.msifirebird-odbc-driver-3.5.0-win-x64.zipfirebird-odbc-driver-3.5.0-linux-x64.tar.gzUpdated:
build-and-test.ymlworkflow_calltrigger (sorelease.ymlcan reuse it).tags-ignore: ['**']to prevent a duplicate run when a tag is pushed (the Release workflow already invokes it viaworkflow_call).windows-x64-binariesandlinux-x64-binaries.master.Updated:
cmake/GetVersionFromGit.cmakev3.5.0-rc1: the numeric version extracted is still3.5.0(MSIProductVersionrequires numeric-only parts).Updated:
SetupAttributes.h#include "WriteBuildNo.h"with#include "Version.h".MAJOR_VERSION,MINOR_VERSION,REVNO_VERSION,BUILDNUM_VERSIONnow map to the CMake-generatedODBC_VERSION_*defines from git tags.BUILDTYPE_VERSIONprefix fromFILE_VERSION_STR(matches v5-pr).Removed
.github/workflows/msbuild.ymlbuild-and-test.yml+release.yml.github/workflows/msbuild_arm64.yamlInstall/Win32/Builds/MsVc2022.win/WriteBuildNo.hVersion.hUpdated:
README.mdandtests/README.mdBuilds/MsVc2022.win/OdbcFb.sln; VS users are directed to the CMake-generated solution atbuild/firebird-odbc-driver.sln.Testing
Local MSI build & install/uninstall
Tested on this machine: install registers the driver, ODBC connection
1+1=2query succeeds, uninstall cleanly removes the 64-bit registration.End-to-end CI (tag
v3.5.0-rc1)All 5 Release workflow jobs passed on commit
5f5938e:build-and-test (ubuntu-22.04)— successbuild-and-test (windows-latest)— successrelease(create GitHub Release as pre-release) — successpackage-linux(upload.tar.gz) — successpackage-windows(build MSI, upload.msi+.zip) — successNo duplicate Build-and-Test run triggered by the tag push.
Notes for reviewers
OdbcJdbcSetup/directory is kept — it contains the ODBC connection dialog source code used by the CMake build, not InnoSetup scripts.v3.5.0tag should be pushed after this PR merges tomaster.v3.5.0-rc1test tag and its GitHub Release on the fork can be deleted once the PR is reviewed.