After migration from v1 to v2 silently fails

[rlconst]

That's it, nothing helpful for troubleshooting

 ##[group]Run gradle/wrapper-validation-action@v2
 with:
   min-wrapper-count: 1
   allow-snapshots: false
 env:
   JAVA_HOME: /opt/hostedtoolcache/Java_Adopt_jdk/17.0.10-7/x64
   JAVA_HOME_17_X64: /opt/hostedtoolcache/Java_Adopt_jdk/17.0.10-7/x64
   AWS_DEFAULT_REGION: us-east-1
   AWS_REGION: us-east-1
   AWS_ACCESS_KEY_ID: ***
   AWS_SECRET_ACCESS_KEY: ***
 ##[endgroup]

[wjglerum]

We are having the same issue here, no errors or warnings in the logs.

[bigdaz]

As far as I'm aware, the only significant change in v2 is that Node20 is now required to run the action.

Are you using a GitHub-provided runner, or a custom runner?

If there are no errors or warnings, can you describe what "silently fails" looks like? Screenshots or links to runs would be very helpful.

Is there anything more you can share that might help us determine the underlying cause?

[sergei-ivanov]

We have been suffering from sporadic failures of this action ever since I upgraded it to @v2. There is no output from the action, it is simply marked as failed, and that is it. We are using "larger" GitHub-hosted runners, but it also fails on the standard ubuntu-latest runner.

[sergei-ivanov]

This is how it looks like in the Actions UI. There's no output at all. The action is marked as failed and the build stops.
The only thing that I suspect may be at play is the use of caches.
BTW, we have also migrated to gradle/actions/setup-gradle@v3 at the same time, but I am not sure if one of them affects the other. Again, possibly a change in caching, but I cannot yet provide any evidence for that.

[bigdaz]

Thanks for the further info. Can you please try to enable GitHub Actions debugging and see if that provides more clues?

Also, why are you setting GRADLE_BUILD_ACTION_SETUP_COMPLETED and GRADLE_BUILD_ACTION_CACHE_RESTORED? These are internal flags not designed to be set by users. Besides, they should have no impact on wrapper-validation-action.

[bigdaz]

@TWiStErRob (or anyone else) : can you confirm that v2 is working for you? Just want to see if this issue is widespread.

[sergei-ivanov]

Also, why are you setting GRADLE_BUILD_ACTION_SETUP_COMPLETED and GRADLE_BUILD_ACTION_CACHE_RESTORED? These are internal flags not designed to be set by users. Besides, they should have no impact on wrapper-validation-action.

I believe those are set by gradle/actions/setup-gradle@v3, which runs just before gradle/wrapper-validation-action@v2. We are not setting them manually anywhere.

[sergei-ivanov]

Thanks for the further info. Can you please try to enable GitHub Actions debugging and see if that provides more clues?

I tried re-running the previously failed job a few times with debug logs and the action worked every time. But I may have been lucky because it only failed 1 time out of 10 before.

[jprosenbaum]

V2 works intermittently, we have 2 separate Gradle steps in the same workflow. The second one fails more frequently.
With debug enabled on the repo, I have not seen it fail.

[bigdaz]

Also, why are you setting GRADLE_BUILD_ACTION_SETUP_COMPLETED and GRADLE_BUILD_ACTION_CACHE_RESTORED? These are internal flags not designed to be set by users. Besides, they should have no impact on wrapper-validation-action.

I believe those are set by gradle/actions/setup-gradle@v3, which runs just before gradle/wrapper-validation-action@v2. We are not setting them manually anywhere.

Ah, got it. The image you shared is Github describing the full environment, not the actual config you entered.

I'm guessing there's something different in Node 20 that causes the process to return with a non-zero exit value. I just don't have any idea what that might be.

[TWiStErRob]

@TWiStErRob (or anyone else) : can you confirm that v2 is working for you?

I think it works for me

2 emails in thread means PR opened and auto-merged. This is from last night.

Almost all my repos use this reusable workflow (and version):
https://github.com/TWiStErRob/github-workflows/blob/v1.4.2/.github/workflows/validate.yml

and it's a required check on branch protection rules.

[wjglerum]

Just tried with debugging enabled and saw it fail multiple times with exit code 1

##[debug]Evaluating condition for step: 'run'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: run
##[debug]Loading inputs
##[debug]Loading env
Run gradle/wrapper-validation-action@v2
  with:
    min-wrapper-count: 1
    allow-snapshots: false
  env:
    GITHUB_ACTOR: github-merge-queue[bot]
    GITHUB_TOKEN: ***
    JAVA_HOME: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.10-7/x64
    JAVA_HOME_17_X64: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.10-7/x64
    GRADLE_BUILD_ACTION_SETUP_COMPLETED: true
    GRADLE_BUILD_ACTION_CACHE_RESTORED: true
##[debug]Node Action run completed with exit code 1
##[debug]Finished: run
##[debug]Evaluating condition for step: 'run'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> false
##[debug]Result: false
##[debug]Evaluating condition for step: 'run'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> false
##[debug]Result: false

nothing about any failure or error in the logs

[jprosenbaum]

Adding the repository variable ACTIONS_RUNNER_DEBUG=true prevents the validation from failing

[deejay1]

Every run locally runs (with node versions 20.x, I haven't tested patch releases though), on GitHub runners and also on self hosted runners it seems to fail and debug doesn't show anything, trying to investigate still...

[TWiStErRob]

I had a quick look at the code and this stood out:

wrapper-validation-action/src/main.ts

Line 29 in 56b90f2

core.setFailed(error.message)

@bigdaz I have a feeling message can be easily "" or undefined, which would set the exit code to 1, but probably wouldn't explain what happened. This is the recommended code in docs, but I think changing it to include Error's toString or Error.stack would help in diagnosing this and future problems.

e.g. core.setFailed(error) (it internally detects Error and does toString on it, but it doesn't show stack, so probably best is: core.setFailed(`Unknown error was thrown: ${error.toString()}\n{error.stack}`)