Skip to content

Conversation

@schneems
Copy link
Contributor

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:

@schneems schneems force-pushed the schneems/yarn-failure-fix branch from 43063b5 to d54b7af Compare November 13, 2024 19:17
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:
```
@schneems schneems force-pushed the schneems/yarn-failure-fix branch from d54b7af to bfe76db Compare November 13, 2024 19:19
@schneems
Copy link
Contributor Author

From CI run 2148 node 1 you can observe that the yarn test was executed:

-----> Running test command `bundle exec rspec-queue --max-requeues=3 --timeout 180 --queue $REDIS_URL --format documentation || { cat log/test_order.log;  $(exit 1); }`...
Hatchet setup: "hatchet-t-a75b4dbf88" for "minimal_webpacker"
Destroying "hatchet-t-a75b4dbf88": 245ded29-9cee-46bf-b7b9-71374d3f1603, (0/100) reason: teardown
works without the node buildpack
Hatchet setup: "hatchet-t-fd04255870" for "default_ruby"
Destroying "hatchet-t-fd04255870": e6133e1e-75ee-49e0-a008-d47acef26bc4, (0/100) reason: teardown
handles PATH with a newline in it correctly
removes files if they go over the limit
should extract the yarn package
checks local sha and remote sha match
Detects java for jruby detection
detects when a package does not exist
remote sha
doesn't error on empty directories
local_commit_sha
checks multiple things
Hatchet setup: "hatchet-t-59e726449f" for "default_with_rakefile"
Destroying "hatchet-t-59e726449f": 450120d5-56a8-4091-b1ab-4526e87d6262, (0/100) reason: teardown
runs a rake task if the gem exists
reports false on bundler prior to 2.2
Hatchet setup: "hatchet-t-46a0618db8" for "rails42_default_ruby"
.Destroying "hatchet-t-46a0618db8": ba072c13-7c29-4baf-8a76-20ccaf50772a, (0/100) reason: teardown
should skip asset compilation when deployed with OLD manifest file
.
Finished in 3 minutes 28.4 seconds (files took 0.39213 seconds to load)
14 examples, 0 failures
-----> test command `bundle exec rspec-queue --max-requeues=3 --timeout 180 --queue $REDIS_URL --format documentation || { cat log/test_order.log;  $(exit 1); }` completed successfully

@schneems schneems marked this pull request as ready for review November 13, 2024 19:35
@schneems schneems requested a review from a team as a code owner November 13, 2024 19:35
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 schneems merged commit 55ee089 into main Nov 14, 2024
2 checks passed
@schneems schneems deleted the schneems/yarn-failure-fix branch November 14, 2024 15:49
@heroku-linguist heroku-linguist bot mentioned this pull request Nov 14, 2024
schneems added a commit that referenced this pull request Apr 24, 2025
* 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.
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.

2 participants