Skip to content
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
wants to merge 10 commits into from
Closed

Sync with upstream v284 #86

wants to merge 10 commits into from

Conversation

Frzk
Copy link

@Frzk Frzk commented Nov 19, 2024

Related to #85

joshwlewis and others added 10 commits November 8, 2024 12:03
* 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>
@Frzk Frzk self-assigned this Nov 19, 2024
@Frzk
Copy link
Author

Frzk commented Dec 30, 2024

Superseded by #89

@Frzk Frzk closed this Dec 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants