New GitHub Actions workflow. by fdcastel · Pull Request #245 · FirebirdSQL/firebird-odbc-driver

fdcastel · 2025-05-31T19:09:29Z

Initial work to solve #231. Based on @asfernandes work on Firebird project. 🚀

GitHub releases can be found here.

v1: Original PR

Changes

The release workflow is now triggered when a tag starting with v is pushed.
Replaced pguyot/arm-runner-action with native ubuntu-22.04-arm runners
Fixed build paths from Builds/Msvc2019 to Builds/MsVc2022.win
Unified artifact naming: firebird-odbc-{platform}-{arch}
Single workflow file instead of separate per-platform workflows

Advantages over previous pipeline

✅ Native ARM64 Execution: No more Raspberry Pi emulation
✅ Faster Builds: Native runners are much faster than emulated ones
✅ Simplified Maintenance: Matrix strategy reduces code duplication
✅ Better Reliability: No complex emulation dependencies
✅ Consistent Environment: Same OS versions across architectures
✅ Automatic Releases: GitHub releases created automatically with all artifacts

v2: New workflows:

1. Build Workflow (`build.yml`)

Trigger: Every push and pull request on any branch (including forks)
Purpose: Continuous Integration - validates that code compiles
Runs on: All repositories (official and forks)

2. Release Workflow (`release.yml`)

Trigger: Only when tags starting with v* are pushed (e.g., v1.0.0)
Purpose: Creates official releases with packaged binaries
Runs on: Only the official repository (FirebirdSQL/firebird-odbc-driver)

ToDo

RFC @irodushka @asfernandes @mrotteveel

mrotteveel · 2025-05-31T19:15:07Z

@fdcastel You can convert a PR to a draft, then it can't be accidentally merged (see right menu bar, "Convert to draft").

.github/workflows/release.yml

mrotteveel · 2025-05-31T19:47:49Z

I have not looked at the jobs themselves in-depth, as I'm not that well-versed in C++ builds.

fdcastel · 2025-05-31T20:12:39Z

I have not looked at the jobs themselves in-depth, as I'm not that well-versed in C++ builds.

Same here 🤣.

That said, I didn’t touch the build scripts, just the YAML workflow. So I doubt I broke anything there.

In a past life, I had quite a bit of experience with Inno Setup. I intend to help out on that front soon.

irodushka · 2025-05-31T20:15:39Z

Great job! I will take a look next week! сб, 31 мая 2025 г., 22:48 Mark Rotteveel ***@***.***>:

…

*mrotteveel* left a comment (FirebirdSQL/firebird-odbc-driver#245) <#245 (comment)> I have not looked at the jobs themselves in-depth, as I'm not that well-versed in C++ builds. — Reply to this email directly, view it on GitHub <#245 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKZQLQ6N7TQIERHM3CEURD3BIBPXAVCNFSM6AAAAAB6KFWROKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMRVGY3DIMZWHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

fdcastel · 2025-05-31T21:02:34Z

@irodushka Before I can make changes to Install\Win32\OdbcJdbcSetup.iss, I need to know the encoding it was saved with.

The file contains some Russian translations, so I want to ensure it's correctly converted to UTF-8 without corrupting the text.

In VSCode, when opened with the "Windows 1251" encoding, it displays as:

fdcastel · 2025-05-31T21:10:45Z

Can we remove these old Windows build environments?

Builds\MsSDK64.win
Builds\MsVc60.win
Builds\MsVc70.win
Builds\MsVc80.win
Builds\MsVc90.win

Actually, it seems like quite a few files in /Builds might no longer be needed.

fdcastel · 2025-06-01T08:54:06Z

Something seems off with the MSBuild project configuration.

Even when invoking msbuild with /p:Configuration=Release,
The linker is still being executed with /DEBUG /PDB:"x64/Release/FirebirdODBC.pdb".

That’s why .pdb files are being generated.

P.s.: The latest release build shows the same issue. ~~Are the currently distributed binaries actually DEBUG builds? Or am I missing something?~~

Answering my own question: No. The binaries are actually RELEASE binaries, but they do include debug symbols in separate .pdb files.

According to this:

The /DEBUG option puts the debugging information from linked object and library files into a program database (PDB) file. (...)

The linker uses the base name of the program and the extension .pdb (...). To override this default, set the /PDB option and specify a different file name.

In other words:

The /DEBUG option here is what actually causes the .pdb files to be generated (not tied to whether the build is a DEBUG build); and
The /PDB option simply specifies the name of the .pdb file.

mrotteveel · 2025-06-01T10:11:11Z

Something seems off with the MSBuild project configuration.

Even when invoking msbuild with /p:Configuration=Release,

The linker is still being executed with /DEBUG /PDB:"x64/Release/FirebirdODBC.pdb".

That’s why .pdb files are being generated.

This is caused by <GenerateDebugInformation>true</GenerateDebugInformation> in the definitions in OdbcFb.vcxproj for Release|Win32 and Release|x64

irodushka · 2025-06-02T11:49:31Z

What's the point of excluding pdb files from the Release build?.. The package size economy?
You should understand that debug & release binaries are very different, and not just in terms of debug information. Pdb file may be extremely useful. Or you think that the Release builds never crash?))

If we want to reduce the installation packages sizes, it's better to store pdb as a separate artefact for optional download/installation.
But I am strongly against excluding pdb files from the MSBuild process, both Debug and Release.

fdcastel · 2025-06-02T11:54:42Z

What's the point of excluding pdb files from the Release build?

Sorry for the confusion, @irodushka. I reverted this in later commits.

If we want to reduce the installation packages sizes, it's better to store pdb as a separate artefact for optional download/installation.

That's exactly what I did 😉 -- I added new packages with the -debug suffix. Please see them here.

irodushka · 2025-06-02T11:56:44Z

@irodushka Before I can make changes to Install\Win32\OdbcJdbcSetup.iss, I need to know the encoding it was saved with.

The file contains some Russian translations, so I want to ensure it's correctly converted to UTF-8 without corrupting the text.

In VSCode, when opened with the "Windows 1251" encoding, it displays as:

Yes, it's correct, win1251.
No problem to convert it to UTF8 if InnoSetup supports this properly.

irodushka · 2025-06-02T12:51:30Z

What's the point of excluding pdb files from the Release build?

Sorry for the confusion, @irodushka. I reverted this in later commits.

If we want to reduce the installation packages sizes, it's better to store pdb as a separate artefact for optional download/installation.

That's exactly what I did 😉 -- I added new packages with the -debug suffix. Please see them here.

Do I understand right that *-debug packages contain Debug build artefacts? Debug dll binary and a corresponding pdb?
What I want to say - debug and release dlls are different, and it's not just about debug info. The Release dll contains compiler optimizations, it just different binary code. So, a pdb file from a Debug build cannot be used to debug a Release dll.

fdcastel · 2025-06-02T13:32:57Z

I haven't modified the build scripts. Only the packaging.

The output binaries are built exactly as they were before.

As far as I understand, the current scripts produce RELEASE binaries (with optimizations). Along with a PDB file to support auxiliary debugging in production.

The confusion originated from my incorrect assumption that seeing /DEBUG in the LINK.EXE command line arguments meant the build was a DEBUG build (i.e., without optimizations). It is not.

The only difference between the -debug and main .zip files are that the -debug package includes the PDB file (and is significantly larger).

irodushka · 2025-06-02T15:09:17Z

Aaaa!... So the regular (wo suffix) windows package and the -debug package contain the same dll binary - the release one? And the only difference between the normal & debug packages is the pdb file inside?
Ok, I got it.
The confusing part is the -debug suffix, i.e. the naming issue) Let's use cmake style naming, it has a special build type "RelWithDebInfo" = release_with_debug_info.

irodushka · 2025-06-02T16:03:07Z

Well... and where's my favorite VirusTotal action?..)
It's not just for fun. There are sporadic troubles with InnoSetup - Windows antivirus detects malware in Inno binaries from time to time. It's a real headache.

fdcastel · 2025-06-02T16:15:18Z

So the regular (wo suffix) windows package and the -debug package contain the same dll binary - the release one?

Exactly! 👍🏻

And the only difference between the normal & debug packages is the pdb file inside?

Exactly! 👍🏻

Let's use cmake style naming, it has a special build type "RelWithDebInfo" = release_with_debug_info.

Sorry. Not totally clear on what you mean 😅. But if you can show me a few examples, I’ll tailor it exactly how you want.

irodushka · 2025-06-02T16:19:30Z

I mean to replace the package suffix _debug with _relwithdebinfo or _release_with_debuginfo пн, 2 июн. 2025 г., 19:15 F.D.Castel ***@***.***>:

…

*fdcastel* left a comment (FirebirdSQL/firebird-odbc-driver#245) <#245 (comment)> So the regular (wo suffix) windows package and the -debug package contain the same dll binary - the release one? Exactly! 👍🏻 And the only difference between the normal & debug packages is the pdb file inside? Exactly! 👍🏻 Let's use cmake style naming, it has a special build type "RelWithDebInfo" = release_with_debug_info. Sorry. Not totally clear on what you mean 😅. But if you can show me a few examples, I’ll tailor it exactly how you want. — Reply to this email directly, view it on GitHub <#245 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKZQLSL7YMQZ27PCKTW2AL3BR2CXAVCNFSM6AAAAAB6KFWROKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMZRGQ2DGNJQGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

fdcastel · 2025-06-02T16:24:10Z

There are sporadic troubles with InnoSetup...

InnoSetup is built with Delphi, which -- for reasons only antivirus developers seem to understand -- tends to attract these kinds of false positives like a magnet.

By the way, I'm also planning to replace InnoSetup with WIX, unless anyone has objections. WIX can generate MSI files, which are generally more suitable for enterprise environments.

fdcastel · 2025-06-02T16:30:09Z

I mean to replace the package suffix _debug with _relwithdebinfo or _release_with_debuginfo

I found the improvement a bit subtle, to be honest. 😄

I would lean toward following the approach used by the Firebird Project.

At first, -withDebugSymbols seemed a bit odd to me, but now I see it from a different perspective.

irodushka · 2025-06-02T16:32:10Z

I know) Not an objection but a benediction)) пн, 2 июн. 2025 г., 19:24 F.D.Castel ***@***.***>:

…

*fdcastel* left a comment (FirebirdSQL/firebird-odbc-driver#245) <#245 (comment)> There are sporadic troubles with InnoSetup... InnoSetup is built with Delphi, which -- for reasons only antivirus developers seem to understand -- tends to attract these kinds of false positives like a magnet. By the way, I'm also planning to replace InnoSetup with WIX <https://www.firegiant.com/wixtoolset/>, unless anyone has objections. WIX can generate MSI files, which are generally more suitable for enterprise environments. — Reply to this email directly, view it on GitHub <#245 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKZQLSLLIU6MWLFF7GVL533BR3EDAVCNFSM6AAAAAB6KFWROKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMZRGQ3TMMBXGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

irodushka · 2025-06-02T16:38:54Z

I mean to replace the package suffix _debug with _relwithdebinfo or _release_with_debuginfo

I found the improvement a bit subtle, to be honest. 😄

I would lean toward following the approach [used by the Firebird Project]

Yes, it' fine for me.

fdcastel · 2025-06-02T16:41:23Z

@irodushka Are there any tests for this project? If so, could you briefly explain how you've been handling them? I had a look at the code, but honestly, I couldn't make much sense of it.

fdcastel · 2025-06-02T16:45:28Z

@irodushka Did you give the ARM64 build a shot? If yes, how did it go?

irodushka · 2025-06-02T17:01:20Z

For Ubuntu only. Yes, tried the ARM build on Raspberry, and it worked fine. Last time I looked, there were no Windows ARM runners available on github. пн, 2 июн. 2025 г., 19:45 F.D.Castel ***@***.***>:

…

*fdcastel* left a comment (FirebirdSQL/firebird-odbc-driver#245) <#245 (comment)> @irodushka <https://github.com/irodushka> Did you give the ARM64 build a shot? If yes, how did it go? — Reply to this email directly, view it on GitHub <#245 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKZQLRWSJL2OYBDB323ATL3BR5T5AVCNFSM6AAAAAB6KFWROKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMZRGU2TCOJSHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

fdcastel · 2025-06-02T17:05:23Z

For Ubuntu only. Yes, tried the ARM build on Raspberry, and it worked fine.

🎉 Fantastic news! I'll investigate.

Last time I looked, there were no Windows ARM runners available on github.

Look again: 😄👀
https://github.blog/changelog/2025-04-14-windows-arm64-hosted-runners-now-available-in-public-preview/

irodushka · 2025-06-02T17:16:52Z

I can explain briefly - no) When I inherited this code, I also wondered - what about tests?) Nope, the answer was. Frankly speaking - I have some tests, it's impossible to maintain such a ... project without them, and it would be a good deal to put them in order and commit to the repo. Hope I can do this in some future. пн, 2 июн. 2025 г., 19:41 F.D.Castel ***@***.***>:

…

*fdcastel* left a comment (FirebirdSQL/firebird-odbc-driver#245) <#245 (comment)> @irodushka <https://github.com/irodushka> Are there any tests for this project? If so, could you briefly explain how you've been handling them? I had a look at the code, but honestly, I couldn't make much sense of it. — Reply to this email directly, view it on GitHub <#245 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKZQLXYSDUCEAZAG5XCFFL3BR5ERAVCNFSM6AAAAAB6KFWROKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMZRGU2DANBZHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

irodushka · 2025-06-03T10:30:21Z

@fdcastel

I would like to mention that it makes sense to retain the ability to do autobuilds for every commit into the master (not for releases only but for intermediate feature-branches merges).

Another interesting question - what happens when some of the builds in the strategy matrix fail? I mean - windows build is ok, linux ok, but ARM fails. Does this mean that the entire build failed? Or can we issue a warning that the build succeeded for some platforms and failed for the others?

fdcastel · 2025-06-03T11:13:12Z

I would like to mention that it makes sense to retain the ability to do autobuilds for every commit into the master (not for releases only but for intermediate feature-branches merges).

Sure! I was just talking about this with @asfernandes. Take a look at this new workflow proposal I suggested for another project.

Another interesting question - what happens when some of the builds in the strategy matrix fail? I mean - windows build is ok, linux ok, but ARM fails. Does this mean that the entire build failed?

Short answer: Yes.

The BUILD jobs are marked with fail-fast: false which means they WILL PROCEED in case some parts of matrix fail.

However, the RELEASE job requires all dependent jobs to complete successfully; otherwise, the packages will NOT be published.

Or can we issue a warning that the build succeeded for some platforms and failed for the others?

GitHub will let us know for sure.

irodushka · 2025-06-03T12:58:58Z

However, the RELEASE job [requires] all dependent jobs to complete successfully; otherwise, the packages will NOT be published.

It's okay

fdcastel · 2025-06-03T13:56:58Z

New commits:

Uses the -with-debug-symbols suffix. Unlike the main Firebird project, I adopted an all-lowercase naming convention for consistency.
New workflows:

1. Build Workflow (`build.yml`)

Trigger: Every push and pull request on any branch (including forks)
Purpose: Continuous Integration - validates that code compiles
Runs on: All repositories (official and forks)

2. Release Workflow (`release.yml`)

Trigger: Only when tags starting with v* are pushed (e.g., v1.0.0)
Purpose: Creates official releases with packaged binaries
Runs on: Only the official repository (FirebirdSQL/firebird-odbc-driver)

- Uses the tag version as a suffix in the filenames of published artifacts. - Consolidate Windows jobs with `strategy.matrix`. - Add ARM64 support to release workflow - Adds debug .zip files. - Removes MakePackage.bat and sed package. - Removes unused (commented) sections from OdbcJdbcSetup.iss.

- Adds build.yml (for builds after pushes/PR). - Restrict release.yml to run only on official repository. - Updates README.md build status badges.

fdcastel · 2026-02-02T09:27:14Z

Rebased with latest master.

Adds Windows ARM64 builds.

Unofficial binaries available at https://github.com/fdcastel/firebird-odbc-driver/releases/tag/v3.0.22-rc1

fdcastel · 2026-02-02T09:40:03Z

@irodushka Some time ago you said

Frankly speaking - I have some tests, it's impossible to maintain such a ... project without them, and it would be a good deal to put them in order and commit to the repo. Hope I can do this in some future.

Well... Future has arrived! Where are those tests? 🙂

I’m starting a new test suite for this project, and I’d like to fold in your tests along with a few others I’ve collected along the way.

irodushka · 2026-02-04T08:57:03Z

Hi @fdcastel !

It's great to see you again!
Those tests... afraid they will happen in some a bit more distant futurious future)

I shall try to do them in а week or two. Can you please tell me in what form should I give them to you?)

irodushka · 2026-02-04T09:19:06Z

Hi again @fdcastel

BTW I have a PR #248
It's a modern cmake for the ODBC driver build (for linux) replacing an ancient plain C-style makefile. At least smoke-tested, but definitly needs more research.
Maybe it's a good idea to merge it to your branch, what do you think about it?

fdcastel · 2026-02-04T20:37:47Z

It's great to see you again! Those tests... afraid they will happen in some a bit more distant futurious future)

Don’t waste time polishing them—just send them over. Any format is fine, even if they don’t work.

I’m building a brand-new test suite from the ground up. What I really need are the cases and the ideas. I’ll take care of the rest.

fdcastel · 2026-02-04T20:39:36Z

BTW I have a PR #248 It's a modern cmake for the ODBC driver build (for linux) replacing an ancient plain C-style makefile.

Fantastic! I’ll take a look at #248 as well.

It came at just the right time -- the current MSBuild is giving me some headaches, too.

irodushka · 2026-02-11T09:32:20Z

Hi @fdcastel !

Do I understand right that PR#275 includes this PR? And this PR can be closed?

Well, what about tests.

I have some tests for base ODBC functionality - sure you have such a tests in you 400+ suite, so you don't need them.
I have some specific tests related to ISC API->OOAPI migration. These tests target cases where the native FB field type differs from the type used in the ODBC binding—for example, an INTEGER ID is bound as a VARCHAR(32). The point is - OOAPI uses a plain data buffer instead of SQLDA structures. That means - the premilinary prepared OOAPI buffer sometimes becomes inconsistent due to client-side bindings) that which leads to truncnation errors and other misbehavior. So, if you need any detalization/explanation here, you're welcome.

fdcastel · 2026-02-12T02:13:38Z

Do I understand right that PR#275 includes this PR? And this PR can be closed?

Correct. This PR was superseded by #275. I'm closing this one.

Well, what about tests.

If you have additional useful tests to add, let’s continue that work in #275.

fdcastel marked this pull request as draft May 31, 2025 19:17

mrotteveel reviewed May 31, 2025

View reviewed changes

.github/workflows/release.yml Outdated Show resolved Hide resolved

mrotteveel reviewed May 31, 2025

View reviewed changes

.github/workflows/release.yml Outdated Show resolved Hide resolved

mrotteveel reviewed May 31, 2025

View reviewed changes

.github/workflows/release.yml Outdated Show resolved Hide resolved

fdcastel changed the title ~~[WIP/Do not merge] New GitHub Actions workflow.~~ New GitHub Actions workflow. May 31, 2025

fdcastel mentioned this pull request Jun 1, 2025

Manually update latest GitHub release to latest version #246

Open

balger mentioned this pull request Jul 30, 2025

Please MSI installer #259

Closed

mariuz marked this pull request as ready for review August 1, 2025 20:24

mariuz marked this pull request as draft August 1, 2025 20:25

fdcastel added 2 commits February 2, 2026 06:13

New GitHub Actions workflows for build and release processes.

ce29ec3

- Adds build.yml (for builds after pushes/PR). - Restrict release.yml to run only on official repository. - Updates README.md build status badges.

fdcastel force-pushed the new-releases branch from 1b1cdf8 to ce29ec3 Compare February 2, 2026 09:24

fdcastel mentioned this pull request Feb 10, 2026

V4 - Firebird ODBC Driver Modernization #275

Draft

fdcastel closed this Feb 12, 2026

Conversation

fdcastel commented May 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

v1: Original PR

Changes

Advantages over previous pipeline

v2: New workflows:

1. Build Workflow (build.yml)

2. Release Workflow (release.yml)

ToDo

Uh oh!

mrotteveel commented May 31, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mrotteveel commented May 31, 2025

Uh oh!

fdcastel commented May 31, 2025

Uh oh!

irodushka commented May 31, 2025 via email

Uh oh!

fdcastel commented May 31, 2025

Uh oh!

fdcastel commented May 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fdcastel commented Jun 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mrotteveel commented Jun 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

irodushka commented Jun 2, 2025

Uh oh!

fdcastel commented Jun 2, 2025

Uh oh!

irodushka commented Jun 2, 2025

Uh oh!

irodushka commented Jun 2, 2025

Uh oh!

fdcastel commented Jun 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

irodushka commented Jun 2, 2025

Uh oh!

irodushka commented Jun 2, 2025

Uh oh!

fdcastel commented Jun 2, 2025

Uh oh!

irodushka commented Jun 2, 2025 via email

Uh oh!

fdcastel commented Jun 2, 2025

Uh oh!

fdcastel commented Jun 2, 2025

Uh oh!

irodushka commented Jun 2, 2025 via email • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

irodushka commented Jun 2, 2025

Uh oh!

fdcastel commented Jun 2, 2025

Uh oh!

fdcastel commented Jun 2, 2025

Uh oh!

irodushka commented Jun 2, 2025 via email

Uh oh!

fdcastel commented Jun 2, 2025

Uh oh!

irodushka commented Jun 2, 2025 via email

Uh oh!

irodushka commented Jun 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fdcastel commented Jun 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

irodushka commented Jun 3, 2025

Uh oh!

fdcastel commented Jun 3, 2025

fdcastel commented May 31, 2025 •

edited

Loading

1. Build Workflow (`build.yml`)

2. Release Workflow (`release.yml`)

fdcastel commented May 31, 2025 •

edited

Loading

fdcastel commented Jun 1, 2025 •

edited

Loading

mrotteveel commented Jun 1, 2025 •

edited

Loading

fdcastel commented Jun 2, 2025 •

edited

Loading

irodushka commented Jun 2, 2025 via email •

edited

Loading

irodushka commented Jun 3, 2025 •

edited

Loading

fdcastel commented Jun 3, 2025 •

edited

Loading

1. Build Workflow (`build.yml`)

2. Release Workflow (`release.yml`)

irodushka commented Feb 4, 2026 •

edited

Loading