having issues with heroku/ruby after latest yarn version bump #1516
Comments
|
@schneems this is breaking our ability to deploy 😢 |
|
Seems like a packaging mistake? Previously $ curl https://heroku-nodebin.s3.us-east-1.amazonaws.com/yarn/release/yarn-v1.22.19.tar.gz -so - | tar xzf -would have a folder named Now curl https://heroku-nodebin.s3.us-east-1.amazonaws.com/yarn/release/yarn-v1.22.22.tar.gz -so - | tar xzf -has a folder named |
|
FWIW I fixed this temporarily by
|
|
Sorry about that. It seems the layout of the nodejs packaging changed in that patch release (as mentioned by @mlarraz). I rolled back the buildpack change at approx 3:00pm CST (20:00 UTC). I've indicated on the changelog that the behavior is rolled back https://devcenter.heroku.com/changelog-items/3054. As @dzfolio recommends. I highly suggest not relying on the default node and yarn versions from the Ruby buildpack https://devcenter.heroku.com/articles/ruby-support-reference#node-js-support. This issue should be fixed using the deployed |
I've forked the buildpack and reverted a few commits back and now it works. Feel free to use it (just replace the original buildpack to this one and back when it's fixed): |
|
@landovsky I've already rolled back the change some 3 days ago. Are you still seeing failures using |
|
We facing the same issue here, is there any way to manually change the yarn version? |
|
Hoping this get merged ASAP, we have our production instance down because of this issue and we can't deploy a fix for the build is failing |
|
@rodmac-fetchly I edited the issue description with mitigation instructions on how to avoid this issue entirely (use |
|
Btw we are deploying with dokku (https://github.com/dokku/dokku) to deploy |
|
I've rolled back the node and yarn versions on main so that it's now deployable. It looks like the issue this wasn't caught is deeper and might take more time to fix than I was hoping #1505. I want to free up main to allow for quickly deploying future changes like new binary releases so I reverted to the old yarn and nodejs versions. @rodmac-fetchly While this would fix the Dokku case for you I would also guess that dokku has the ability to run multiple buildpacks, in which case my first suggestion to use the |
|
Thanks a lot, we were able to deploy it after your fix was merged! We did try the other solution you mentionened but we weren't able to make it work. You saved the day! |
It’s possible to specify a specific version of a buildpack in Dokku. I’ve resolved this by using the latest stable version, referencing it directly as follows: FYI, this approach also works on Heroku, allowing you to lock in a specific buildpack version there too. Anyway, thank you @schneems for the rollback 👍 |
In #1516 there were reported build failures: ``` remote: -----> Installing node-v22.11.0-linux-x64 remote: -----> Installing yarn-v1.22.22 remote: remote: ! remote: ! No such file or directory @ rb_file_s_rename - (/tmp/d20241108-1032-vggdc3/yarn-v1.22.22, yarn-v1.22.22) remote: ! remote: /tmp/tmp.l8hWafbPfJ/lib/ruby/3.1.0/fileutils.rb:541:in `rename': No such file or directory @ rb_file_s_rename - (/tmp/d20241108-1032-vggdc3/yarn-v1.22.22, yarn-v1.22.22) (Errno::ENOENT) remote: from /tmp/tmp.l8hWafbPfJ/lib/ruby/3.1.0/fileutils.rb:541:in `block in mv' remote: from /tmp/tmp.l8hWafbPfJ/lib/ruby/3.1.0/fileutils.rb:1577:in `block in fu_each_src_dest' remote: from /tmp/tmp.l8hWafbPfJ/lib/ruby/3.1.0/fileutils.rb:1593:in `fu_each_src_dest0' remote: from /tmp/tmp.l8hWafbPfJ/lib/ruby/3.1.0/fileutils.rb:1575:in `fu_each_src_dest' remote: from /tmp/tmp.l8hWafbPfJ/lib/ruby/3.1.0/fileutils.rb:532:in `mv' remote: from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/helpers/yarn_installer.rb:27:in `block in install' remote: from /tmp/tmp.l8hWafbPfJ/lib/ruby/3.1.0/tmpdir.rb:96:in `mktmpdir' ``` This is because older versions of the yarn package have a top level directory that looks like this: ``` yarn-v1.22.19/ ``` But yarn 1.22.22 has a directory named "package" instead: ``` package/ ``` To work around this naming issue we can use `--strip 1` tar flag to remove the top level directory. From gnutar manfiles https://www.gnu.org/software/tar/manual/tar.html: ``` ‘--strip-components=number’ Strip given number of leading components from file names before extraction. For example, suppose you have archived whole ‘/usr’ hierarchy to a tar archive named ‘usr.tar’. Among other files, this archive contains ‘usr/include/stdlib.h’, which you wish to extract to the current working directory. To do so, you type: $ tar -xf usr.tar --strip=2 usr/include/stdlib.h The option ‘--strip=2’ instructs tar to strip the two leading components (‘usr/’ and ‘include/’) off the file name. If you add the ‘--verbose’ (‘-v’) option to the invocation above, you will note that the verbose listing still contains the full file name, with the two removed components still in place. This can be inconvenient, so tar provides a special option for altering this behavior: ```
* Fix failure installing yarn 1.22.22 In #1516 there were reported build failures: ``` remote: -----> Installing node-v22.11.0-linux-x64 remote: -----> Installing yarn-v1.22.22 remote: remote: ! remote: ! No such file or directory @ rb_file_s_rename - (/tmp/d20241108-1032-vggdc3/yarn-v1.22.22, yarn-v1.22.22) remote: ! remote: /tmp/tmp.l8hWafbPfJ/lib/ruby/3.1.0/fileutils.rb:541:in `rename': No such file or directory @ rb_file_s_rename - (/tmp/d20241108-1032-vggdc3/yarn-v1.22.22, yarn-v1.22.22) (Errno::ENOENT) remote: from /tmp/tmp.l8hWafbPfJ/lib/ruby/3.1.0/fileutils.rb:541:in `block in mv' remote: from /tmp/tmp.l8hWafbPfJ/lib/ruby/3.1.0/fileutils.rb:1577:in `block in fu_each_src_dest' remote: from /tmp/tmp.l8hWafbPfJ/lib/ruby/3.1.0/fileutils.rb:1593:in `fu_each_src_dest0' remote: from /tmp/tmp.l8hWafbPfJ/lib/ruby/3.1.0/fileutils.rb:1575:in `fu_each_src_dest' remote: from /tmp/tmp.l8hWafbPfJ/lib/ruby/3.1.0/fileutils.rb:532:in `mv' remote: from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/helpers/yarn_installer.rb:27:in `block in install' remote: from /tmp/tmp.l8hWafbPfJ/lib/ruby/3.1.0/tmpdir.rb:96:in `mktmpdir' ``` This is because older versions of the yarn package have a top level directory that looks like this: ``` yarn-v1.22.19/ ``` But yarn 1.22.22 has a directory named "package" instead: ``` package/ ``` To work around this naming issue we can use `--strip 1` tar flag to remove the top level directory. From gnutar manfiles https://www.gnu.org/software/tar/manual/tar.html: ``` ‘--strip-components=number’ Strip given number of leading components from file names before extraction. For example, suppose you have archived whole ‘/usr’ hierarchy to a tar archive named ‘usr.tar’. Among other files, this archive contains ‘usr/include/stdlib.h’, which you wish to extract to the current working directory. To do so, you type: $ tar -xf usr.tar --strip=2 usr/include/stdlib.h The option ‘--strip=2’ instructs tar to strip the two leading components (‘usr/’ and ‘include/’) off the file name. If you add the ‘--verbose’ (‘-v’) option to the invocation above, you will note that the verbose listing still contains the full file name, with the two removed components still in place. This can be inconvenient, so tar provides a special option for altering this behavior: ``` * Default to strip 0 instead of true From the feedback: > Minor - maybe the default for strip_components should be 0 instead of false? From this signature, I would expect that if I want it to strip components I would pass true instead of false but that would produce an invalid command.
@schneems Update: You can manually set your node and yarn version following the docs here https://devcenter.heroku.com/articles/ruby-support-reference#node-js-support. Further, I recommend using the
heroku/rubybuildpack and recommend against using the github url on your app.Original report:
after the newest heroku/ruby buildpack was released, we are having issues with this. what can we do?
The text was updated successfully, but these errors were encountered: