andygrove commented on code in PR #6061:
URL: https://github.com/apache/datafusion-comet/pull/6061#discussion_r4244176345


##########
.github/workflows/pr_build_linux.yml:
##########
@@ -202,9 +202,36 @@ jobs:
           restore-keys: |
             ${{ runner.os }}-java-maven-
 
+      # Split a Maven Central hiccup from a real lint violation. Resolving the
+      # scalafix plugin descriptor has failed mid-job before, leaving
+      # "No plugin found for prefix 'scalafix'" and a red lint that looks
+      # exactly like a violation (pull request #6035). The scalafix-syntactic
+      # job above solves the same problem by retrying the download and then
+      # linting offline; Maven has no equally safe offline mode here, because
+      # the goal resolves rule artifacts as it runs, so retry instead. Stop the
+      # moment scalafix reports actual errors, so a genuinely broken pull
+      # request is not rebuilt four times. Backoff matches
+      # .github/actions/maven-bootstrap: 10s, 20s, 40s plus 0-4s of jitter.
       - name: Run scalafix check
         run: |
-          ./mvnw -B package -DskipTests scalafix:scalafix 
-Dscalafix.mode=CHECK -Psemanticdb ${{ matrix.profile.maven_opts }}
+          set -o pipefail
+          for attempt in 1 2 3 4; do
+            if ./mvnw -B package -DskipTests scalafix:scalafix 
-Dscalafix.mode=CHECK \
+                 -Psemanticdb ${{ matrix.profile.maven_opts }} 2>&1 | tee 
scalafix-check.log; then

Review Comment:
   Fixed in 49ff6ce03b. The log now goes to a `mktemp` file outside the 
checkout, the same way the sbt retry in `spark_sql_test_reusable.yml` handles 
it, so a passing run leaves the tree clean.
   



##########
.github/workflows/pr_build_linux.yml:
##########
@@ -202,9 +202,36 @@ jobs:
           restore-keys: |
             ${{ runner.os }}-java-maven-
 
+      # Split a Maven Central hiccup from a real lint violation. Resolving the
+      # scalafix plugin descriptor has failed mid-job before, leaving
+      # "No plugin found for prefix 'scalafix'" and a red lint that looks
+      # exactly like a violation (pull request #6035). The scalafix-syntactic
+      # job above solves the same problem by retrying the download and then
+      # linting offline; Maven has no equally safe offline mode here, because
+      # the goal resolves rule artifacts as it runs, so retry instead. Stop the
+      # moment scalafix reports actual errors, so a genuinely broken pull
+      # request is not rebuilt four times. Backoff matches
+      # .github/actions/maven-bootstrap: 10s, 20s, 40s plus 0-4s of jitter.
       - name: Run scalafix check
         run: |
-          ./mvnw -B package -DskipTests scalafix:scalafix 
-Dscalafix.mode=CHECK -Psemanticdb ${{ matrix.profile.maven_opts }}
+          set -o pipefail
+          for attempt in 1 2 3 4; do
+            if ./mvnw -B package -DskipTests scalafix:scalafix 
-Dscalafix.mode=CHECK \
+                 -Psemanticdb ${{ matrix.profile.maven_opts }} 2>&1 | tee 
scalafix-check.log; then
+              exit 0
+            fi
+            if grep -q 'Scalafix invoked with errors' scalafix-check.log; then

Review Comment:
   Agreed, fixed in 49ff6ce03b. The loop now retries only when one of Maven's 
`[ERROR]` lines names a download (`No plugin found for prefix`, `could not be 
resolved`, `Could not transfer`, or the `scala.tools.nsc.Main` 
ClassNotFoundException that a missing compiler jar produces), and anything else 
fails on the first attempt. Replaying it over 111 Lint Java step logs from CI 
runs since 09-20, it retries the six download failures and none of the 30 
compile errors or 25 lint violations.
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to