-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update dependencies for Windows build and drop 32-bit support #567
Update dependencies for Windows build and drop 32-bit support #567
Conversation
The new action allows us to specify if the MSSQL server should enforce encryption at all times. This helps us to verify that our precompiled build on Windows, where we compile OpenSSL ourselves, will work as expected.
Also bump the cache key to force a recompilation of freetds against the new OpenSSL version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work, I left a couple inconsequential comments. Also, can you remind me where to find built gems in the gh actions maze for this PR? I want to smoke test the dependency updates by installing the .gem manually
* Raise error if FreeTDS is unable to sent command buffer to the server | ||
* Use freetds v1.4.23, libiconv v1.17 and OpenSSL v3.4.0 for Windows builds |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- extconts sets these versions for all platforms, right? And it's that their statically linked for Windows. But building for other platforms would also use these versions?
- Any concern doing this large of a version jump for OpenSSL?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extconts sets these versions for all platforms, right? And it's that their statically linked for Windows. But building for other platforms would also use these versions?
If you would build tiny_tds using our "ports" mechanic, you will also get these versions. Our Linux CI build actually also uses these versions. For installations outside of our CI, the discovered freetds version is used, which could be anything.
Any concern doing this large of a version jump for OpenSSL?
There is a chance that something breaks. As mentioned on the PR, I wanted to make sure that tiny_tds
generally works when using encrypted connections by adding this new scenario on CI. But I can imagine that there are some configurations that will no longer work with this new OpenSSL version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you would build tiny_tds using our "ports" mechanic, you will also get these versions. Our Linux CI build actually also uses these versions. For installations outside of our CI, the discovered freetds version is used, which could be anything.
Right, exactly. That's what most people will be using across all OS's since we go from CI artifact -> rubygems.org, right? So it seems more accurate to drop the "for Windows" part of the sentence is what I'm saying
There is a chance that something breaks. As mentioned on the PR, I wanted to make sure that tiny_tds generally works when using encrypted connections by adding this new scenario on CI. But I can imagine that there are some configurations that will no longer work with this new OpenSSL version.
Is there any other consideration to add to the changelog? Minimum OS version, minimum glibc version, etc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what most people will be using across all OS's since we go from CI artifact -> rubygems.org, right?
Not exactly.
When you install tiny_tds
on Linux or Mac OS, Rubygems will discover that we have some C code in the gem and will try to compile it. In order for tiny_tds
to compile, it tries to discover an installation of freetds
. This process does not invoke our ports
mechanic in case freetds
is missing, but fails instead.
So all people on non-Windows machines will compile freetds
on their own first, likely according to our installation instructions.
Mid-term I would like to explore if we could provide precompiled versions of tiny_tds
for all platforms, similar as Nokogiri did a while back. It would simplify the installation for the end-user.
Is there any other consideration to add to the changelog? Minimum OS version, minimum glibc version, etc?
Don't think so. I still would like to release the next version as v3 just to signal that there might be breaking changes.
with: | ||
install: sqlengine, sqlclient | ||
components: sqlcmd,sqlengine |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be a yaml list instead of a comma delimited string?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are different types of custom GitHub Actions you can build: Composite, Docker and JavaScript. The last one is the only one that supports other types than strings, see discussion here.
Means the setup-mssql
action will receive this comma-separated list as string. The action is a composite action and uses PowerShell behind the scenes. This comma-separated list format is easier to parse from PowerShell.
.github/workflows/ci.yml
Outdated
- "false" | ||
- "true" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are these strings instead of actual true/false?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same reason as with the input array: since setup-mssql
is a composite action, it will coerce any value to be a string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's on the receiver side though right? I'm thinking of it from our side, the user side, where normal values seem more ergonomic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, receiver's end.
@aharpervc normally there is a button that should show all artifacts generated during a workflow run, but it appears to be broken. this would be the download link for the Windows gem that works for Ruby 3.1+: and this is the one for Ruby 2.7 and 3.0: |
Closes #526
Relates to #552
The main goal of this PR is to update dependencies for the precompiled Windows build. However, it also contains a few other changes.
I replaced the action we use to setup the MSSQL server for testing. I developed the new action myself. It contains three advantages over the previous action:
The last point is relevant since I planned to update the OpenSSL version in the Windows build. I wanted to make sure that such a major upgrade will not cause any issues for the end users. Connections to MSSQL servers are unencrypted by default, so I suspected that even if freetds will compile against OpenSSL v3, the relevant encryption code is not used at all. By adjusting our CI to force encryption to the MSSQL server, I think this scenario is covered well. This is only done on Windows, as on Linux, everybody compiles freetds on their own.
The dependency updates for the Windows build are:
In this process, I also dropped the 32-bit build for Windows. It was untested and in very low demand (see #552 for details).