Sync with upstream v287 #89
Merged
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>
…ault (heroku#1523) * Set UV_USE_IO_URING=0 by default Default `UV_USE_IO_URING=0` due to build timeouts This mirrors a change by the nodejs buildpack: heroku/heroku-buildpack-nodejs#1347 The Ruby buildpack needs this because we can install node/yarn without the `heroku/nodejs` buildpack, however this behavior triggers a warning and is generally advised against. * Only set UV_USE_IO_URING=0 at build (not runtime) * Make UV_USE_IO_URING=0 available for other buildpacks
Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>
* Update bundler version for jruby app Fixes: ``` Hatchet::App::FailedDeployError Could not deploy 'hatchet-t-741ea26fdf' (default_ruby) using 'Hatchet::GitApp' at path: './repos/rack/default_ruby' if this was expected add `allow_failure: true` to your deploy hash. Buildpack: nil Repo: https://git.heroku.com/hatchet-t-741ea26fdf.git output: remote: Updated 5 paths from 3dac5f9 remote: Compressing source files... done. remote: Building source: remote: remote: -----> Building on the Heroku-20 stack remote: -----> Using buildpack: https://github.com/heroku/heroku-buildpack-ruby#schneems/ci-queue-dec3 remote: -----> Ruby app detected remote: remote: ## Warning: Your app needs java remote: remote: The Ruby buildpack determined your app needs java installed remote: we recommend you add the jvm buildpack to your application: remote: remote: $ heroku buildpacks:add heroku/jvm --index=1 remote: remote: -----> Installing Java remote: remote: -----> Downloading Buildpack: heroku/jvm remote: -----> Detected Framework: JVM Common remote: remote: ! WARNING: No OpenJDK version specified remote: Your application does not explicitly specify an OpenJDK remote: version. OpenJDK 1.8 will be installed. remote: remote: This default version will change at some point. Your remote: application might fail to build with the new version. We remote: recommend explicitly setting the required OpenJDK version for remote: your application. remote: remote: To set the OpenJDK version, add or edit the system.properties remote: file in the root directory of your application to contain: remote: remote: java.runtime.version = 1.8 remote: remote: remote: -----> Installing OpenJDK 1.8... done remote: -----> Installing bundler 1.17.3 remote: -----> Removing BUNDLED WITH version in the Gemfile.lock remote: -----> Compiling Ruby/Rack remote: -----> Using Ruby version: ruby-2.5.7-jruby-9.2.13.0 remote: -----> Installing dependencies using bundler 1.17.3 remote: Running: BUNDLE_WITHOUT='development:test' BUNDLE_PATH=vendor/bundle BUNDLE_BIN=vendor/bundle/bin BUNDLE_DEPLOYMENT=1 BUNDLE_GLOBAL_PATH_APPENDS_RUBY_SCOPE=1 bundle install -j4 remote: You are trying to install in deployment mode after changing remote: your Gemfile. Run `bundle install` elsewhere and add the remote: updated Gemfile.lock to version control. remote: remote: If this is a development machine, remove the /tmp/build_3b0d62e8/Gemfile freeze remote: by running `bundle install --no-deployment`. remote: remote: Bundler is unlocking ruby remote: remote: You have added to the Gemfile: remote: * webrick remote: Bundler Output: You are trying to install in deployment mode after changing remote: your Gemfile. Run `bundle install` elsewhere and add the remote: updated Gemfile.lock to version control. remote: remote: If this is a development machine, remove the /tmp/build_3b0d62e8/Gemfile freeze remote: by running `bundle install --no-deployment`. remote: remote: Bundler is unlocking ruby remote: remote: You have added to the Gemfile: remote: * webrick remote: remote: ! remote: ! Failed to install gems via Bundler. remote: ! remote: ! Push rejected, failed to compile Ruby app. remote: remote: ! Push failed remote: ! remote: ! ## Warning - The same version of this code has already been built: df7a92f56ea636831f28033356791f2ba6ba0ef0 remote: ! remote: ! We have detected that you have triggered a build from source code with version df7a92f56ea636831f28033356791f2ba6ba0ef0 remote: ! at least twice. One common cause of this behavior is attempting to deploy code from a different branch. remote: ! remote: ! If you are developing on a branch and deploying via git you must run: remote: ! remote: ! git push heroku <branchname>:main remote: ! remote: ! This article goes into details on the behavior: remote: ! https://devcenter.heroku.com/articles/duplicate-build-version remote: remote: Verifying deploy... remote: remote: ! Push rejected to hatchet-t-741ea26fdf. remote: To https://git.heroku.com/hatchet-t-741ea26fdf.git ! [remote rejected] HEAD -> main (pre-receive hook declined) error: failed to push some refs to 'https://git.heroku.com/hatchet-t-741ea26fdf.git' /app/vendor/bundle/ruby/3.1.0/gems/heroku_hatchet-8.0.4/lib/hatchet/git_app.rb:36:in `git_push_heroku_yall' /app/vendor/bundle/ruby/3.1.0/gems/heroku_hatchet-8.0.4/lib/hatchet/git_app.rb:13:in `block in push_without_retry!' /app/vendor/bundle/ruby/3.1.0/gems/heroku_hatchet-8.0.4/lib/hatchet/shell_throttle.rb:28:in `block (2 levels) in call' /app/vendor/bundle/ruby/3.1.0/gems/heroku_hatchet-8.0.4/lib/hatchet/shell_throttle.rb:27:in `catch' /app/vendor/bundle/ruby/3.1.0/gems/heroku_hatchet-8.0.4/lib/hatchet/shell_throttle.rb:27:in `block in call' ``` https://dashboard.heroku.com/pipelines/ac057663-170b-4bdd-99d0-87560eb3a570/tests/2165 * Update jruby version for bundler support ``` remote: -----> Installing dependencies using bundler 2.5.6 remote: Running: BUNDLE_WITHOUT='development:test' BUNDLE_PATH=vendor/bundle BUNDLE_BIN=vendor/bundle/bin BUNDLE_DEPLOYMENT=1 bundle install -j4 remote: NoMethodError: undefined method `union' for ["BUNDLE_JOBS"]:Array remote: all at /tmp/build_0e08ea51/vendor/bundle/jruby/2.5.0/gems/bundler-2.5.6/lib/bundler/settings.rb:169 remote: report at /tmp/build_0e08ea51/vendor/bundle/jruby/2.5.0/gems/bundler-2.5.6/lib/bundler/env.rb:20 remote: request_issue_report_for at /tmp/build_0e08ea51/vendor/bundle/jruby/2.5.0/gems/bundler-2.5.6/lib/bundler/friendly_errors.rb:71 remote: log_error at /tmp/build_0e08ea51/vendor/bundle/jruby/2.5.0/gems/bundler-2.5.6/lib/bundler/friendly_errors.rb:50 remote: with_friendly_errors at /tmp/build_0e08ea51/vendor/bundle/jruby/2.5.0/gems/bundler-2.5.6/lib/bundler/friendly_errors.rb:123 remote: <main> at /tmp/build_0e08ea51/vendor/bundle/jruby/2.5.0/gems/bundler-2.5.6/exe/bundle:20 remote: load at org/jruby/RubyKernel.java:1009 remote: <main> at /tmp/build_0e08ea51/vendor/bundle/jruby/2.5.0/bin/bundle:25 remote: Bundler Output: NoMethodError: undefined method `union' for ["BUNDLE_JOBS"]:Array remote: all at /tmp/build_0e08ea51/vendor/bundle/jruby/2.5.0/gems/bundler-2.5.6/lib/bundler/settings.rb:169 remote: report at /tmp/build_0e08ea51/vendor/bundle/jruby/2.5.0/gems/bundler-2.5.6/lib/bundler/env.rb:20 remote: request_issue_report_for at /tmp/build_0e08ea51/vendor/bundle/jruby/2.5.0/gems/bundler-2.5.6/lib/bundler/friendly_errors.rb:71 remote: log_error at /tmp/build_0e08ea51/vendor/bundle/jruby/2.5.0/gems/bundler-2.5.6/lib/bundler/friendly_errors.rb:50 remote: with_friendly_errors at /tmp/build_0e08ea51/vendor/bundle/jruby/2.5.0/gems/bundler-2.5.6/lib/bundler/friendly_errors.rb:123 remote: <main> at /tmp/build_0e08ea51/vendor/bundle/jruby/2.5.0/gems/bundler-2.5.6/exe/bundle:20 remote: load at org/jruby/RubyKernel.java:1009 remote: <main> at /tmp/build_0e08ea51/vendor/bundle/jruby/2.5.0/bin/bundle:25 ``` * Update test to not be on deprecated stack * Update gem versions * Inspect ruby version instead of jar file From https://github.com/heroku/heroku-buildpack-java/blob/b3c51f94de6a43bc656b777bc84ef2a9451371aa/test/spec/java_spec.rb#L78 > OpenJDK versions > 9 do not have the jre/lib/ext directory where we drop the pgconfig.jar This test was added by Joe in heroku@248b30a later I moved to not having a separate track for installing JVM heroku@648a149 so I removed the logic for installing a pgconfig.jar and relied on the buildpack. According to the JVM buildpack it's no longer in this updated version. It seems the original PR was using this to test that installation logic. While we no longer need to do that (as the logic is part of the `heroku/jvm` buildpack) I wanted to preserve calling a `heroku run` to assert something about the dyno that would indicate that jruby was installed as we expect.
Should work on hosted redis now Shopify/ci-queue#294
* Ruby 3.4.0-rc1 * Update CHANGELOG.md Co-authored-by: Rune Soerensen <runesoerensen@gmail.com> --------- Co-authored-by: Rune Soerensen <runesoerensen@gmail.com>
Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>
* Stage Ruby 3.4.0 Ruby 3.4.0 will be released on Christmas. This PR is for pre-approval. It will be held for merge until December 25th, 2024. * Update CHANGELOG.md
Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>
Closed
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
Tested here: https://fku-ror.osc-st-fr1.apps.st-sc.fr/