forked from heroku/heroku-buildpack-ruby
-
Notifications
You must be signed in to change notification settings - Fork 14
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
Sync with upstream v284 #86
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Update Node.js default to 22.11.0 * Update changelog for Node.js defaults * Add missing dot! Co-authored-by: Ed Morley <501702+edmorley@users.noreply.github.com> * Node yarn changelog for heroku#1503 (heroku#1514) --------- Co-authored-by: Ed Morley <501702+edmorley@users.noreply.github.com> Co-authored-by: Richard Schneeman <rschneeman@salesforce.com>
Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>
There's an issue with the way that yarn is packaged that caused heroku#1516 due to behavior introduced in heroku#1503. This commit reverts to the old node/yarn versions until we can fix the underlying bug.
* Emit log order Issue heroku#1505 spells out a problem where it appears ci-queue does not fail even when the test suite is broken. I'm unsure why this happens. To debug I'm emitting the tests that run so I can audit to make sure `rspec ./spec/helpers/yarn_installer_spec.rb:6` is executed. If it's not, then I need to diagnose why. If it is, then perhaps there some ordering bug that's affecting the outcome. * Update CI-queue * Update redis version * Use branch of ci-queue
* Fix failure installing yarn 1.22.22 In heroku#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.
Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>
Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>
Superseded by #89 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to #85