flaky installation on ci server

[geyuqiu]

$ ./mvnw com.github.eirslett:frontend-maven-plugin:install-node-and-npm -DnodeVersion=v12.13.1 -DnpmVersion=6.13.4 -Dmaven.repo.local=$MAVEN_USER_HOME
[ERROR] The archive file .../.maven/com/github/eirslett/node/12.13.1/node-12.13.1-linux-x64.tar.gz
is corrupted and will be deleted. Please try the build again.
[ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.8.0:
install-node-and-npm (default-cli) on project cbkop-gui-unified: Could not extract the Node archive:
Could not extract archive: '.../.maven/com/github/eirslett/node/12.13.1/node-12.13.1-linux-x64.tar.gz': EOFException -> [Help 1]

Do you want to request a feature or report a bug?
bug
What is the current behavior?
because of a "failure" ci-setup, every push is built under the same directory
flaky behavior: most of the time successfully
suggested fix
the archive maybe corrupted before
and reinstallation should be clearing the old outdated / corrupted files?
question: try rm -rf .maven before installation ?
If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
runs smoothly every time
Please mention your frontend-maven-plugin and operating system version.
Red hat linux: 7
frontend-maven-plugin: 1.8.0

[SystemOutPrint]

+1

[grafvonb]

I have a similar problem when jobs run in parallel on the same agent:

08:11:47  [ERROR] The archive file /home/jenkins/.m2/repository/com/github/eirslett/node/12.22.7/node-12.22.7-linux-x64.tar.gz is corrupted and will be deleted. Please try the build again.
08:11:47  [INFO] ------------------------------------------------------------------------
08:11:47  [INFO] BUILD FAILURE
08:11:47  [INFO] ------------------------------------------------------------------------
08:11:47  [INFO] Total time:  5.177 s
08:11:47  [INFO] Finished at: 2021-10-22T06:11:46Z
08:11:47  [INFO] ------------------------------------------------------------------------
08:11:47  [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.12.0:install-node-and-npm (install node and npm) on project mvn-node: Could not extract the Node archive: Could not extract archive: '/home/jenkins/.m2/repository/com/github/eirslett/node/12.22.7/node-12.22.7-linux-x64.tar.gz': EOFException -> [Help 1]

It seems to be a sort of a race condition. Is there an option to change the place where .tar.gz is saved before it gets extracted? If no we definitely need one.

[simontunnat]

I have the same issue in our GitLab CI environment.

It only happens from time to time:
09:11:11:813 [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.12.0:install-node-and-npm (install node and npm) on project one-ebmpapst.ui.frontend: Could not extract the Node archive: Could not extract archive: '/builds/it.ics.epm/one-intranet/one-ebmpapst/.m2/repository/com/github/eirslett/node/16.14.2/node-16.14.2-linux-x64.tar.gz': EOFException -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.12.0:install-node-and-npm (install node and npm) on project one-ebmpapst.ui.frontend: Could not extract the Node archive: Could not extract archive: '/builds/it.ics.epm/one-intranet/one-ebmpapst/.m2/repository/com/github/eirslett/node/16.14.2/node-16.14.2-linux-x64.tar.gz'

[adamenveil]

Any fix for this?

[ryanrupp]

Relates to #807 which looks like when this scenario happens it will at least auto-delete the corrupted download, you can see this in the original post above

[ERROR] The archive file .../.maven/com/github/eirslett/node/12.13.1/node-12.13.1-linux-x64.tar.gz
is corrupted and will be deleted. Please try the build again.

That said, it doesn't actually automatically retry the download then (maybe it should?) - there's a comment on the PR actually about this here.

[ryanrupp]

I think possibly the download logic here should be changed so that it downloads to a temp directory and then uses move (atomic) once the download has completed. Currently, it's just writing the response to the destination directly. If writing to a temp location you don't have to worry about the corrupt download really as much.

[seregamorph]

@ryanrupp you are right, such enhancement makes sense. And yes, initially not to complicate the change too much, the simple strategy with deletion of corrupted archive was used, the simple retry should eventually solve the problem. This solution is not perfect, also it can be not an option in some CI/CD environments, but for my team it was enough at the moment. I guess the best what you can do here is to submit the PR with proposed change.

[melloware]

Same happening here on GitHub Actions started happening constantly after latest 1.14.0 release.

Edit: Had to delete all my GitHub Caches to get it to start working again.

[pranavbhole]

@eirslett any update on this issue?