Skip to content
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

Merged
merged 9 commits into from
Dec 9, 2024

Conversation

andyundso
Copy link
Member

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:

  • Installation of MSSQL 2017 on Windows works again (see Switch to GitHub Actions #556).
  • It would be compatible with the new Ubuntu 24.04 runner. We currently do not use it since MSSQL 2017 in Docker does not work with Ubuntu 24.04.
  • It allows to force an encrypted connection to the MSSQL server.

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:

  • OpenSSL: From v1.1.1s to v3.4.0
  • libiconv: From v1.15 to v1.17
  • freetds: From v1.1.24 to v1.4.23

In this process, I also dropped the 32-bit build for Windows. It was untested and in very low demand (see #552 for details).

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.
@andyundso andyundso requested a review from aharpervc November 19, 2024 15:23
Copy link
Contributor

@aharpervc aharpervc left a 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

.github/workflows/ci.yml Outdated Show resolved Hide resolved
* 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. 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?
  2. Any concern doing this large of a version jump for OpenSSL?

Copy link
Member Author

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.

Copy link
Contributor

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?

Copy link
Member Author

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
Copy link
Contributor

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?

Copy link
Member Author

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.

Comment on lines 223 to 224
- "false"
- "true"
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, receiver's end.

@andyundso
Copy link
Member Author

@aharpervc normally there is a button that should show all artifacts generated during a workflow run, but it appears to be broken.

image

this would be the download link for the Windows gem that works for Ruby 3.1+:
https://github.com/rails-sqlserver/tiny_tds/actions/runs/11915239939/artifacts/2207840602

and this is the one for Ruby 2.7 and 3.0:
https://github.com/rails-sqlserver/tiny_tds/actions/runs/11915239939/artifacts/2207843215

@andyundso andyundso merged commit d94efe6 into rails-sqlserver:master Dec 9, 2024
63 checks passed
@andyundso andyundso deleted the update-dependencies branch December 9, 2024 19:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Compatibility with OpenSSL v3
2 participants