-
Notifications
You must be signed in to change notification settings - Fork 37
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
Upgrading from 3.0.1 to 3.0.2 breaks amd64 builds #40
Comments
It's strange. The error message says "No such file or directory" but it seems that |
|
|
I was able to make some general progress based on the above, but it is not ideal given how our CI/CD pipeline is setup. I had to delete the Prior to the 3.0.2 version change, what would happen is our CI/CD pipeline would add both the I currently have an environment locally where this is reproducible, so let me know what all information I can potentially provide to help debug/diagnose. |
I take that back, there are some others that place the shared objects within the |
Could you show your |
How did you do this? |
Correct
I included both versions pre and post CI. The only differences between them in each case are 1) the addition of the Pre CI the only difference is the strscan version being locked. https://gist.github.com/tenpaiyomi/4ebc96e851700a9c7a741fb8fcce7000 |
I'm also currently pinning the gem to different commit versions since 3.0.1 and deploying it out through our CI to a staging environment to find the commit in question where things started breaking to help narrow down the changes. |
So, interestingly, building directly from the git ref seems to work perfectly fine. I'm currently on SHA 5da2432 which is tagged as the last commit for 3.0.2. I'm going to try unpinning and going to the latest version (3.0.3 as of this moment) and see if it breaks again or not. If so, that would I believe point to some sort of issue with the actual built gem itself? |
Going to the latest 3.0.3 built gem resulted in the same broken behavior. Going to the latest 3.0.3 SHA, bbfd6d1, works without issue. |
Thanks. Could you show the command lines to install gems with the |
For the CI
For Production
|
Umm... I couldn't get source "https://rubygems.org/"
gem "strscan"
gem "nokogiri" Command lines: bundle lock --add-platform ruby
bundle lock --add-platform x86_64-linux
bundle lock --add-platform aarch64-linux
Can you get |
To note, that was after I had to forcible remove the folder at
error and won't let me install any gems. |
Can you reproduce this with source "https://rubygems.org/"
gem "strscan"
gem "nokogiri" or similar? |
Referring to just a minimally viable Gemfile? If so I can attempt such in the morning, I'll have to get a new blank app setup and go through the various steps to try and recreate the setup between an x86 machine and arm64 machine without going through the CI. |
Yes. It seems that we don't need Rails to reproduce this. |
Fair enough, that will simplify it a bit but I'll still have to coordinate back and forth between my x86 and arm64 machine to ensure it goes through the same process. |
I'm not sure if this
So AFAIK a gem home only supports a single architecture currently, not multiple. |
Mmh, it does seems supported at least in theory: https://bundler.io/v1.12/bundle_package.html |
For what it is worth @eregon, this is a setup that, up until this most recent gem update, has been working for months without an issue. The reason for the need to do the |
This might not be relevant, as I just realized that my x86 machine and amd64 machines were on different ruby versions. Installing same versions and retrying. |
So, a few things of note that I've found interesting (and a little confusing). When going through a fresh install, nothing gets installed in I'm not sure of the logic for when code is placed in |
@deivid-rodriguez Could you take a look at this? It seems that this is a Bundler's resolver related problem. Here is a summary of this problem:
|
Thanks for the ping @kou, I will try to have a look. Obviously a way to reproduce would go a long way towards fixing this. |
@tenpaiyomi You have shared the |
@deivid-rodriguez https://gist.github.com/tenpaiyomi/d7a916180b85c2498fa67bf52f18454b Unfortunately things have been so busy with work recently that I have not had much extraneous time continue trying to debug this right now. Once I do have the time, I'll see what else I can find. |
Had an unexpected downtime today when updating Rails from
7.0.2.4
to7.0.3
. Went digging and noticed that as part of the update, 2 other gems were updated. Finally nailed down the break to the update ofstrscan
from3.0.1
to3.0.2
, and was able to get this error when attempting to start the application on a local amd64 machine.This is on Ruby
3.1.1
, Rails7.0.3
At this point I have every other gem that was being updated fully updated and my application is back up and running with
strscan
pinned in my Gemfile to3.0.1
, but as soon as I updatestrscan
to3.0.2
the application will break again.Something interesting I noticed as well is that, despite this one single gem being updated and being the only change in the
Gemfile.lock
, a large number of related gems are affected on the filesystem when my CD process updates everything changed. Also interesting to note is that the change directly involves deleting of anything aarch64/amd64 related.These files which are updated also correspond to the files which are stated to be missing when my application in production attempts to start:
The text was updated successfully, but these errors were encountered: