search

actions / setup-java

Set up your GitHub Actions workflow with a specific version of Java
MIT License
1.47k stars 708 forks source link

Gradle caching post-task consistently fails on Windows with "device or resource busy" #633

Open nhubbard opened 1 month ago

nhubbard commented 1 month ago

Description: On Windows runners, my setup-java consistently shows read errors for the following files in the .gradle folder:

It also happened in older builds with Gradle 8.6.

Task version:

actions/setup-java@v4

Workflow file is as follows:

name: Konf CI
on: [ push ]
jobs:
  build:
    name: Build on JDK ${{ matrix.java_version }} and ${{ matrix.os }}
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        # Only covers Java 21 because the publishing plugin doesn't work on lesser versions
        java_version: [ 21 ]
        os: [ ubuntu-latest, windows-latest, macOS-latest ]
    steps:
      - uses: actions/checkout@v4
      - name: Set up JDK ${{ matrix.java_version }}
        uses: actions/setup-java@v4
        with:
          distribution: "temurin"
          java-version: ${{ matrix.java_version }}
          cache: "gradle"
      - name: Build and Test with Gradle
        env:
          OSS_USER_TOKEN: ${{ secrets.OSS_USER_TOKEN }}
          OSS_USER_PASSWORD: ${{ secrets.OSS_USER_PASSWORD }}
        run: ./gradlew build
      - name: Report Coveralls (Linux)
        if: startsWith(runner.os, 'Linux')
        run: curl -sL https://coveralls.io/coveralls-linux.tar.gz | tar -xz && ./coveralls report build/reports/kover/report.xml
        env:
          COVERALLS_REPO_TOKEN: ${{ secrets.COVERALLS_REPO_TOKEN }}
      - name: Report Coveralls (Windows)
        if: startsWith(runner.os, 'Windows')
        run: |
          Invoke-WebRequest -Uri "https://github.com/coverallsapp/coverage-reporter/releases/latest/download/coveralls-windows.zip" -OutFile "coveralls-windows.zip"
          Add-Type -AssemblyName System.IO.Compression.FileSystem
          [System.IO.Compression.ZipFile]::ExtractToDirectory("coveralls-windows.zip", ".")
          Remove-Item "coveralls-windows.zip"
          Start-Process -FilePath ".\coveralls.exe" -ArgumentList "report build/reports/kover/report.xml" -NoNewWindow -Wait
        env:
          COVERALLS_REPO_TOKEN: ${{ secrets.COVERALLS_REPO_TOKEN }}
      - name: Report Coveralls (macOS)
        if: startsWith(runner.os, 'macOS')
        env:
          COVERALLS_REPO_TOKEN: ${{ secrets.COVERALLS_REPO_TOKEN }}
        run: |
          brew tap coverallsapp/coveralls --quiet
          brew install coveralls --quiet
          coveralls report build/reports/kover/report.xml

Platform:

Runner type:

Repro steps:

I already provided the exact workflow file above, but the repository is here: https://github.com/nhubbard/konf

Here are some example successful workflow runs where this issue is logged:

Expected behavior:

The cache is successfully generated for restoration on the next build with the Windows runner.

Actual behavior:

A tar error is reported under the "Post Set up JDK 21" action:

Post job cleanup.
"C:\Program Files\Git\usr\bin\tar.exe" --posix -cf cache.tzst --exclude cache.tzst -P -C D:/a/konf/konf --files-from manifest.txt --force-local --use-compress-program "zstd -T0"
/usr/bin/tar: C\:/Users/runneradmin/.gradle/caches/8.6/fileContent/fileContent.lock: Read error at byte 0, while reading 38 bytes: Device or resource busy
/usr/bin/tar: C\:/Users/runneradmin/.gradle/caches/8.6/fileHashes/fileHashes.lock: Read error at byte 0, while reading 38 bytes: Device or resource busy
/usr/bin/tar: C\:/Users/runneradmin/.gradle/caches/8.6/generated-gradle-jars/generated-gradle-jars.lock: Read error at byte 0, while reading 38 bytes: Device or resource busy
/usr/bin/tar: C\:/Users/runneradmin/.gradle/caches/8.6/javaCompile/javaCompile.lock: Read error at byte 0, while reading 38 bytes: Device or resource busy
/usr/bin/tar: C\:/Users/runneradmin/.gradle/caches/jars-9/jars-9.lock: Read error at byte 0, while reading 38 bytes: Device or resource busy
/usr/bin/tar: C\:/Users/runneradmin/.gradle/caches/journal-1/journal-1.lock: Read error at byte 0, while reading 38 bytes: Device or resource busy
/usr/bin/tar: C\:/Users/runneradmin/.gradle/caches/modules-[2](https://github.com/nhubbard/konf/actions/runs/9019442520/job/24782324790#step:7:2)/modules-2.lock: Read error at byte 0, while reading 38 bytes: Device or resource busy
/usr/bin/tar: Exiting with failure status due to previous errors
Warning: Failed to save: "C:\Program failed with error: The process 'C:\Program Files\Git\usr\bin\tar.exe' failed with exit code 2
Cache saved with the key: setup-java-Windows-gradle-0b89a5[3]

Despite the "cache saved with the key" message, it doesn't actually save the cache correctly.

aparnajyothi-y commented 1 month ago

Hello @nhubbard, Thank you for creating this issue and we will get back to you once we have some feedback on this :)

ayhanap commented 1 month ago

Not sure if it's related but I get occasional file access errors on Linux Maven. (because the FileSystem has been closed) Error happens on the actual phase, not the post job in my case. 

Error:  Caused by: java.util.concurrent.ExecutionException: java.lang.RuntimeException: Failed to access [/home/runner/work/userowl-api/userowl-api/domain/target/domain-0.23.3.native.jar] because the FileSystem has been closed
Error:      at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
Error:      at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
Error:      at io.quarkus.deployment.steps.ClassTransformingBuildStep.handleClassTransformation(ClassTransformingBuildStep.java:275)
Error:      at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
Error:      at java.base/java.lang.reflect.Method.invoke(Method.java:580)
Error:      at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:849)
Error:      ... 6 more
nhubbard commented 3 weeks ago

I think I have a potential solution. Should we even be attempting to cache the lock files? They are supposed to be cleaned up automatically by Gradle after all...