tiny_tds
tiny_tds copied to clipboard
Update CI/Cross compile Ruby version support
Add Ruby 3.0 to CI and cross compile list. This also drops any rubies below 2.6 from CI and cross compile since they are now EOL. This is based on the changes in #456 to add Ruby 2.7
Closes: #503
The code change itself looks reasonable, however we'll want to make sure the automated tests are passing before we merge this PR
Since i have no working knowledge of AppVeyor I cannot contribute much to it. But looking at the log
error: '/var/cache/pacman/pkg/zstd-1.4.7-1-x86_64.pkg.tar.xz': invalid or corrupted package (PGP signature) loading packages... Command exited with code 1
It looks like the environment itself has issues. https://help.appveyor.com/discussions/problems/27815-build-failing-due-to-key-error and https://www.msys2.org/news/#2020-06-29-new-packagers
Hi, It looks like some work has been done on preparing the Tiny_tds for Ruby 3, However when Can I expect a release of https://github.com/rails-sqlserver/tiny_tds/pull/509/files. Please advice, Thanks!
Hi,
We have an organization that uses this gem to manage desired state on MS SQL Servers via Chef. However, the latest release of Chef 17 runs Ruby version 3. This means unfortunately that tiny_tds is not currently compatible with this latest major release of Chef and that we are blocked from moving to Chef 17.
Is there news on this pr? I would be happy to try and move it forward. But I cannot tell just by looking at the project what would be best, as the last merged pr was May '21, and this one seemed blocked.
Is there anything I can do? Is it only a matter of passing the tests?
Is there anything I can do? Is it only a matter of passing the tests?
Yes, that is the basic problem, but it comes in two forms:
- The current CI job is failing. if you can figure out how to fix the CI job, then we can verify that the tests pass on the supported versions of ruby, including ruby 3
- The overall CI config for this repo is fairly out of date. I don't love that we have to run separate CI services to test linux/windows, and we don't test on macos. I believe it'd be better if we could remove the existing CI config and consolidate on CircleCI. I started an experimental branch to try that last year, here: https://github.com/veracross/tiny_tds/pull/1, but there is a problem (as currently seen here) but more generally here, where
bundle exec rake ports:libiconv
times out. I don't know why it times out, but the theory was it's missing a dependency but that isn't being logged. If someone can crack what's wrong and get the CircleCI job running, then we can bring the conclusion of that experiment over here to this repo. Feel free to make a fork of my fork if you want to pick up that work, or just copy/paste my CI config from that branch.
Figuring out CI is the prerequisite, and then fixing any ruby 3 compatibility issues would come second. I don't think it's a good idea to cut a new version of the gem announcing ruby 3 support without CI jobs for at least linux & windows to verify that the tests are passing on ruby 3.
This makes sense to me, I understand. I've never used CircleCI, but I was looking the other branch over yesterday and it seems straightforward enough. You have already done a lot of work, too.
I'll start on that branch and see what I can do to help.
Since CircleCI was merged can this check be ran again against the new CI?
perhaps we can just give them a little time as i think they still have to finish setting up circleci integration
- Something is going wrong clicking the button to start the CircleCI integration; I have a support issue in with them to figure it out
- Once that's working, this branch will either need to be rebased on the latest changes (or closed, and a new branch opened with the appropriate change for CircleCI)
i'll be happy to pick it up when it's ready, thank you @aharpervc
@aharpervc , I hope you are doing well. :)
Is there any news on the circle ci support ticket for tiny_tds?
Is there any news on the circle ci support ticket for tiny_tds?
It remains unclear why we were unable to manually add the project or have the workflows run on master. However, creating a new branch IS running the jobs (see this pr -> this workflow)
Therefore I assume we're good to go with incrementing forward the supported ruby versions, starting with rebasing (or re-creating) this branch as I said above.
indeed, i noticed that too, it runs on branches at least.
any specific next step we would like for the next pr?
i seem to recall there were other issues created for changes presumably needed for ruby 3.0 compatibility. i personally lean to a new branch for this
i just want to make sure i start on the right thing. let me know and i'll spin it up
oh, i see, let us start with incrementing forward the existing supported versions. ok
This PR can be closed.
that's correct, #530 and #533 addressed this.