Hello 👋
When using

      - uses: eskatos/gradle-command-action@v1
        with:
          build-root-directory: sample
          gradle-version: rc
          dependencies-cache-enabled: true
          arguments: (...)

I'm getting "##[error]versionSpec parameter is required" error message

I tested with different arguments 6.1.1, current, rc, nightly, release-nightly but only rc fails with such message. According to the documentation even if it is not available it should fallback to current. Or do I get something wrong?

Thanks for creating and maintaining the plugin 👍

Have you tried caching generated-gradle-jars into tool-cache as well?

In other words:

1. Download Gradle
2. Execute it so it generates .gradle/caches/6.6/generate-gradle-jars/...
3. Ensure generated-gradle-jars is cached into tool-cache (e.g. copy it to gradle location)
4. As the tool is unpacked from the cache, copy generated-gradle-jars accordingly

See gradle/gradle#13982

Update: tool-cache does not cache files across job executions in GitHub runners (see actions/toolkit#58 (comment)), so currently tool-cache is not useful for caching gradle-generated-jars

Hi, I'm using your tool and I failed to build my gradle project:

 Run eskatos/gradle-command-action@v11s
    JAVA_HOME_11.0.7_x64: C:\hostedtoolcache\windows\jdk\11.0.7\x64
Run eskatos/gradle-command-action@v1
  with:
    arguments: check --info --no-daemon --stacktrace
  env:
    JAVA_HOME: C:\hostedtoolcache\windows\jdk\11.0.7\x64
    JAVA_HOME_11.0.7_x64: C:\hostedtoolcache\windows\jdk\11.0.7\x64
(node:4488) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
##[error]The "path" argument must be of type string. Received type undefined

See https://github.com/JetBrains/Arend/runs/768528069?check_suite_focus=true
Revision: https://github.com/JetBrains/Arend/tree/cadb216982eef572f8d9ba6a6c754806a0986678

How could I fix it?

May be I'm doing something wrong but adding build-root-directory pointing to a sub directory in my repository where the Gradle wrapper lives does not get effective and the build fails.

The workflow file is https://github.com/kuniss/ScalaFlow/blob/master/.github/workflows/build.yml
An example of a failed build running this workflow can be found here: https://github.com/kuniss/ScalaFlow/actions/runs/438808438

Thanks in advance!

These generated jar files can take a significant time to create, and could benefit from caching.

These files are created whenever:

• A gradle project has a gradleApi() dependency
• A gradle project uses the Gradle Kotlin DSL
• A gradle project uses Gradle TestKit

These files still refer to eskatos/gradle-command-action and Gradle Command in places.

Why is my build failing?

> Configure project :
Compiling Discord4K version "1.0.0-SNAPSHOT"
Compiling subproject 'd4k-api'...
Compiling subproject 'd4k-sdk'...
Could not resolve compiler classpath. Check if Kotlin Gradle plugin repository is configured in root project 'Discord4K'.

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':compileKotlin'.
> Could not resolve all files for configuration ':kotlinCompilerClasspath'.
   > Cannot resolve external dependency org.jetbrains.kotlin:kotlin-compiler-embeddable:1.3.71 because no repositories are defined.
     Required by:
         project :

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 51s

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: actions/setup-java@v1
      with:
        java-version: 8
    - uses: eskatos/gradle-command-action@v1
      with:
        arguments: build

build.gradle.kts

We set some env options dynamically on our builds due to github not preserving them between steps, and in our case they're computed. It would be great if there was an option like run_init that accepted something arbitrary to run before the gradle command

I would like to separate some gradle tasks into their own steps to:

• use other actions like gradle-wrapper-validation
• allowing to read outputs from gradle into the environment
• restricting sensitive env-tokens to specific steps

Separation is already possible if "arguments" only contains "--version". At least the following seems to work fine:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # Build
      - name: Set up Java [...]
      - name: cache gradle
        uses: eskatos/[email protected]
        with:
          wrapper-cache-enabled: true
          dependencies-cache-enabled: true
          configuration-cache-enabled: true
          arguments: --version
      - name: store some config info in Environment
        run: echo "CONFIG_INFO=`./gradlew -q someConfigInfo`" >> $GITHUB_ENV
      - name: build and push
        env:
          USER: "..."
          TOKEN: "..."
        run: ./gradlew clean jib

It would be 🎉 if this action does not force the usage of arguments and by this allowing users to only utilize the excellent caching-mechanism.

#7 introduced the caching of downloaded dependencies, disabled by default

This issue is about enabling it by default.

When an exact match for a cache key is found, then any changes to the cache entry will not be persisted after the job completes. With the existing cache key algorithm, can result in inefficient use of caching.

Consider this example:

1. A job runs gradle help, and caches the dependencies with the key dependencies-<hash>
2. A subsequent job runs gradle test and gets an exact-match hit with the key dependencies-<hash>. This job will download many additional dependencies, but due to the exact match on cache key, the updated cache entry will not be saved.
3. Any subsequent gradle test job will have to re-download all dependencies

The Gradle invocation arguments should be included in the cache key, so that the cache lookup pattern will be:

1. dependencies-<arguments>-<hash>
2. dependencies-<arguments>-
3. dependencies-

A similar change should be made for the configuration-cache key.

A boolean parameter that publishes the build scan in the Action run would be perfect.

Wanted know why is the build failing?

^This is my code for Github Actions

From this PR (nokeedev/gradle-native#153), we can see that some of the SCAN were not published properly. I'm using this code to attach the build scan URL to the commit/checks.

I'm wondering if we could have a debug flag to try and narrow down what is happening when the action is trying to extract the build scan URL.

See https://docs.gradle.org/6.7-rc-1/release-notes.html#jvm-toolchains

Hello, continuing a short discussion we had on Gradle slack group with this issue :)

Our previous setup for Gradle caching was the following:

- uses: actions/cache@v2
        with:
          path: ~/.gradle/wrapper
          key: ${{ runner.os }}-gradle-wrapper-${{ hashFiles('gradle/wrapper/gradle-wrapper.properties') }}
          restore-keys: |
            ${{ runner.os }}-gradle-wrapper-

in order to cache the wrapper only.

After switching to this Github action, Wrapper caching works just like before, but we have seen that there was an increase in amount of time spent to execute a step of the job, which was previously using Gradle directly.

Our current GCA configuration is the following:

- uses: eskatos/gradle-command-action@v1
        name: Run Spotless Kotlin check
        with:
          arguments: spotlessKotlinCheck
          wrapper-cache-enabled: true
          dependencies-cache-enabled: true
          configuration-cache-enabled: true

for the steps that execute Gradle commands.

Although, we see the following logs in the Jobs execution:

Received 188743680 of 265189797 (71.2%), 179.8 MBs/sec
Received 265189797 of 265189797 (100.0%), 153.6 MBs/sec
Cache Size: ~253 MB (265189797 B)
/bin/tar --use-compress-program zstd -d -xf /home/runner/work/_temp/1bfe5e14-fe54-49ed-9be7-e82e07e1fc21/cache.tzst -P -C /home/runner/work/our_project
Wrapper installation restored from cache key: wrapper-6.6.1-all
Received 218103808 of 252537189 (86.4%), 207.8 MBs/sec
Received 252537189 of 252537189 (100.0%), 150.1 MBs/sec
Cache Size: ~241 MB (252537189 B)
/bin/tar --use-compress-program zstd -d -xf /home/runner/work/_temp/24e14abe-50f6-4f0c-ac36-a572622446b8/cache.tzst -P -C /home/runner/work/our_project
Dependencies restored from cache key: dependencies-0b71f356b09000f604bde0cdb6a19decb186c474a46cf0dd90af311471bd403e
Received 318 of 318 (100.0%), 0.0 MBs/sec
Cache Size: ~0 MB (318 B)
/bin/tar --use-compress-program zstd -d -xf /home/runner/work/_temp/55187232-a2b1-4d0c-aa79-6f6d01b2f81b/cache.tzst -P -C /home/runner/work/our_project
Configuration restored from cache key: configuration-7b33f41d52b4b4df03f055a384afe740cbd081f30e897366495d6e891ddd4948
/home/runner/work/our_project/gradlew spotlessKotlinCheck

As you can see there is no dependencies cached.

Another thing we have tried for the dependency caching issue, was trying to specify the files we needed to be checked and used for dependency-cache invalidation, like following:

          dependencies-cache-key: |
            *.gradle.kts
            gradle-wrapper.properties
            *Deps.kt
            SharedVersions.kt

This didn't work either though and we kept getting the same logs in the Job's execution.

All of our jobs run on ubuntu-latest. Let me know if there is anything unclear or how I can provide more information to help debug the issue 😄

#7 introduced the caching of build configuration, disabled by default

This issue is about enabling it by default.
This won't happen until the configuration cache is itself enabled by default in Gradle core.
This may take a while.

Currently, About section contains https://github.com/marketplace/actions/gradle-command link but it should be https://github.com/marketplace/actions/gradle-build-action since action was renamed recently

When GH action is running for many different PRs, each one could require a separate dependencies cache entry. Due to cache space limitations, it's quite possible for a PR entry to then evict the entry populated by the master branch.

This could be mitigated by running PRs with a read-only cache, so they start with the cache entries generated for the base (master) branch and only need to download any additional dependencies. By doing this, there would be no chance that a PR cache entry could cause the master cache entry to be evicted.

There seems to be a problem in the logic here: https://github.com/eskatos/gradle-command-action/blob/master/src/execution.ts#L21-L30

It seems that the next line is sometimes empty which causes the publish URL scrapping to miss the real line with the URL. I can recommend extracting the first instance of a line starting with http. Alternatively, it could be the other check that fails where the line doesn't exactly start with HTTP. Unfortunately, there isn't enough logging to figure out where the failure is happening.

When using gradle-command-action there is a warning about the deprecated set-env and add-path commands:

• The set-env command is deprecated and will be disabled on November 16th. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/

• The add-path command is deprecated and will be disabled on November 16th. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/

When using this action on a Gradle plugin build that runs TestKit tests against several Gradle versions, TestKit downloads the Gradle distributions to a dedicated "gradle user home".

Currently the distributions downloads happen on each job run, slowing down the feedback loop.

It would be nice to cache those distributions downloads.

Hello, @eskatos . I using your action in my build. I want use environment variable in arguments:

 - name: Publish with Gradle
        env:
          RELEASE_VERSION: ${GITHUB_REF:11}
        uses: eskatos/gradle-command-action@v1
        with:
          gradle-version: current
          arguments: test publish -Pversion=$RELEASE_VERSION

But, it not work for me. I get this result of this step:

/home/runner/gradle-provision-tmpdir/installs/gradle-6.1.1/bin/gradle test publish -Pversion=$RELEASE_VERSION

My env variable not resolve, and set as is. How can I set this variable for gradle param? Thx,

A particular step in androidx/androidx started failing since 11 hours ago which aligns with the 1.5.0 release that was done 1.5 release.

Below is the full log. I've not dig deeper yet to figure out what is happening (will probably pin to a previous release for now).

The error seems to be coming from:
https://github.com/cypress-io/github-actions-cache/blob/master/src/restore.ts#L40

I'll update the issue w/ more details when i have, just wanted to report it first.

2021-08-23T06:08:46.4870058Z ##[group]Run eskatos/gradle-command-action@v1
2021-08-23T06:08:46.4870589Z with:
2021-08-23T06:08:46.4874141Z   arguments: -q :ktlintCheckFile --file=/home/runner/work/androidx/androidx/camera/camera-view/dependencies.gradle  -Dorg.gradle.internal.http.connectionTimeout=300000   -Dorg.gradle.internal.http.socketTimeout=300000                    -Dorg.gradle.internal.repository.max.retries=10                    -Dorg.gradle.internal.repository.initial.backoff=500               -Dorg.gradle.jvmargs=-XX:MaxMetaspaceSize=512m                   --stacktrace
2021-08-23T06:08:46.4877755Z   build-root-directory: activity
2021-08-23T06:08:46.4878419Z   configuration-cache-enabled: true
2021-08-23T06:08:46.4879361Z   dependencies-cache-enabled: true
2021-08-23T06:08:46.4880185Z   gradle-executable: activity/gradlew
2021-08-23T06:08:46.4880827Z   wrapper-directory: activity/gradle/wrapper
2021-08-23T06:08:46.4881481Z   wrapper-cache-enabled: true
2021-08-23T06:08:46.4882846Z   distributions-cache-enabled: true
2021-08-23T06:08:46.4883622Z   dependencies-cache-exact: false
2021-08-23T06:08:46.4884499Z   configuration-cache-exact: false
2021-08-23T06:08:46.4885107Z   cache-read-only: false
2021-08-23T06:08:46.4885504Z env:
2021-08-23T06:08:46.4885987Z   JAVA_HOME_11.0.12_x64: /opt/hostedtoolcache/jdk/11.0.12/x64
2021-08-23T06:08:46.4886586Z   JAVA_HOME: /opt/hostedtoolcache/jdk/11.0.12/x64
2021-08-23T06:08:46.4887208Z   JAVA_HOME_11_0_12_X64: /opt/hostedtoolcache/jdk/11.0.12/x64
2021-08-23T06:08:46.4887828Z   ANDROID_SDK_ROOT: /home/runner/Library/Android/sdk
2021-08-23T06:08:46.4888348Z   DIST_DIR: /home/runner/dist
2021-08-23T06:08:46.4888938Z ##[endgroup]
2021-08-23T06:08:48.3929710Z Received 0 of 149835506 (0.0%), 0.0 MBs/sec
2021-08-23T06:08:49.3939627Z Received 83886080 of 149835506 (56.0%), 39.9 MBs/sec
2021-08-23T06:08:50.3946404Z Received 149835506 of 149835506 (100.0%), 47.5 MBs/sec
2021-08-23T06:08:50.3952350Z Cache Size: ~143 MB (149835506 B)
2021-08-23T06:08:50.4049918Z [command]/usr/bin/tar --use-compress-program zstd -d -xf /home/runner/work/_temp/4aace25f-b8cb-4aae-915e-f9dc79b44bb7/cache.tzst -P -C /home/runner/work/androidx/androidx
2021-08-23T06:08:50.7047440Z Cache restored successfully
2021-08-23T06:08:50.7407040Z Wrapper installation restored from cache key: wrapper-v1-7.2-all
2021-08-23T06:08:50.8989428Z ##[error]Key Validation Error: dependencies|-q :ktlintCheckFile --file=/home/runner/work/androidx/androidx/camera/camera-view/dependencies.gradle  -Dorg.gradle.internal.http.connectionTimeout=300000   -Dorg.gradle.internal.http.socketTimeout=300000                    -Dorg.gradle.internal.repository.max.retries=10                    -Dorg.gradle.internal.repository.initial.backoff=500               -Dorg.gradle.jvmargs=-XX:MaxMetaspaceSize=512m                   --stacktrace|01b77a1810c45353800e50951c8cbf7c8230703015cb5d73cdcc6a86d4b059e8 cannot be larger than 512 characters.
2021-08-23T06:08:50.9268278Z Post job cleanup.

Please see the following run:
https://github.com/cfogelklou/android_auto_test_ci_cd/actions/runs/635280555

- name: Build for Android Automotive
        uses: eskatos/[email protected]
        with:
          build-root-directory: uamp
          arguments: assemble

But it results in the error:

Error: ENOENT: no such file or directory, open '/home/runner/work/android_auto_test_ci_cd/android_auto_test_ci_cd/gradle/wrapper/gradle-wrapper.properties'

It should not be running in /home/runner/work/android_auto_test_ci_cd/android_auto_test_ci_cd/gradle/

It should be running in /home/runner/work/android_auto_test_ci_cd/android_auto_test_ci_cd/uamp/gradle as uamp is the specified subdirectory.

Hello @eskatos

I tried to include the build scan URL in the github message but didn't succeed.

Build scans
If your build publishes a build scan the gradle-command-action action will emit the link to the published build scan as an output named build-scan-url.
You can then use that link in subsequent actions of your workflow.

Here is my yaml config

name: CI unit tests
on: [pull_request]
jobs:
  unittests:
    runs-on: ubuntu-latest    
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-java@v1
        with:
          java-version: 8
      - uses: eskatos/gradle-command-action@v1
        with:
          arguments: testDebugUnitTest
      - name: Comment PR
        uses: thollander/actions-comment-pull-request@master
        if: failure()
        with:
          message: Build failed ${{ steps.gradle.outputs.build-scan-url }}
          GITHUB_TOKEN: ${{ secrets.GITHUBTOKEN }}     

Expected result: Build failed https://gradle.com/s/rjfaddrnmi5dq
Actual result: Build failed

PR jmfayard/android-kiss#5

Actions: https://github.com/jmfayard/android-kiss/actions

I want to use this action for building my Kotlin application on Ubuntu, Mac OS, and Windows. My builds works fine on Windows. However, this action fails to locate gradlew on Ubuntu 20.04 and Mac OS X 10.15. The executables gradlew and gradlew.bat are in the root folder of my repository.

Error on Mac OS X 10.15:

Run gradle/gradle-build-action@v1
  with:
    distributions-cache-enabled: true
    dependencies-cache-enabled: true
    configuration-cache-enabled: true
    arguments: build
    wrapper-cache-enabled: true
    dependencies-cache-exact: false
    configuration-cache-exact: false
    cache-read-only: false
  env:
    JAVA_HOME_11.0.12_x64: /Users/runner/hostedtoolcache/jdk/11.0.12/x64
    JAVA_HOME: /Users/runner/hostedtoolcache/jdk/11.0.12/x64
    JAVA_HOME_11_0_12_X64: /Users/runner/hostedtoolcache/jdk/11.0.12/x64
Wrapper installation cache not found. Will download and cache with key: wrapper-v1-6.7.1-bin.
Dependencies cache not found, expect dependencies download.
Configuration cache not found, expect task graph calculation.
Error: Unable to locate executable file: /Users/runner/work/***/***/gradlew. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

My workflow:

name: Build

on:
  - push
  - pull_request

jobs:

  build:
    strategy:
      matrix:
        os: [ubuntu-20.04, windows-2019, macos-10.15]
    name: ${{ matrix.os }} build
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-java@v1
        with:
          java-version: 11
      - uses: gradle/gradle-build-action@v1
        with:
          distributions-cache-enabled: true
          dependencies-cache-enabled: true
          configuration-cache-enabled: true
          arguments: build

Workaround for Linux and Mac OS:

run: chmod +x ./gradlew

However, I think this action could do this automatically and the error unable to locate executable file is a bit misleading.

The action currently fails when the Gradle execution fails. It means that the build-scan-url output can only be consumed by subsequent steps when the Gradle execution succeeds.

This issue is about adding support for not failing the action when the Gradle execution fails so that subsequent steps can decide what to do and use the build scan url.

Something along those lines:

steps:
- name: gradle 
  uses: eskatos/gradle-command-action@v1
  with:
    arguments: build --scan
    failOnError: false
- name: "publish build scan"
  uses: some/action@v42
  with:
    content: "Build Scan ${{ steps.gradle.outputs.build-scan-url }}"
- name: "check gradle exit code"
  run: test ${{ steps.gradle.outputs.status }} == 0
  shell: bash

It is a common pattern for tools (node/python/ruby/etc) to provide a "setup-X" action which downloads and installs a particular version of a tool. The setup-java action is provided by GitHub and does this for JDKs.

Following this pattern, a "setup-gradle" command would be used to provision Gradle to the PATH, given a particular version (or version alias like "nightly").

The "gradle-build-action" would be simplified so that it invoked Gradle either by:

• Invoking the wrapper if found
• Using Gradle from PATH if not (with a way to explicitly bypass the wrapper to force this option).

Every GitHub agent comes with a recent Gradle version pre-installed and on the PATH, so the 'setup-gradle' command would not be strictly required.

To reduce redundancy in caching, the downloaded wrapper distributions and generated-gradle-jars are cached separately from the Gradle User Home, allowing these cached values to be shared between many jobs that use the same Gradle versions. However, the key for these is the entire set of files downloaded, which means that a job that downloads the wrapper for Gradle 7.1 and Gradle 7.2 will not be able to reuse the cached artifacts for a job that only downloaded Gradle 7.2.

Ideally, these files would be cached independently so that the cached items would not be duplicated.

It seems gradle is using these more: https://docs.gradle.org/6.8-milestone-3/release-notes.html

I'm trying to use my gradlew, which's delivered as part of the project in the root's folder, but seems like everytime I'm getting a newly downloaded gradlew, and not using the one I already have.

Here's my code:

steps:
- uses: actions/checkout@v1
- name: Set up JDK 1.11
  uses: actions/setup-java@v1
  with:
    java-version: 1.11
- uses: eskatos/gradle-command-action@v1
  with:
    wrapper-directory: .
    arguments: clean build -P<property> -P<property>

Am I misusing the action?

name: Check if it builds.

on:
  pull_request:
    branches: [ master ]

jobs:
  gradle:
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-java@v1
        with:
          java-version: 11
      - uses: eskatos/gradle-command-action@v1
        with:
          arguments: test build

Gives this error:

Run eskatos/gradle-command-action@v1
(node:2526) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
Wrapper installation cache not found, expect a Gradle distribution download.
##[error]Unable to locate executable file: /home/runner/work/mcutils/mcutils/gradlew. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

See this for the full action.

Not sure how to specifcy the path to my gradlew

Right now this plugin supports caching of configuration, wrapper and dependencies, but not actual caching of pre-built classes and other build artifacts (~/.gradle/caches/build-cache-1 directory aka build caching - https://docs.gradle.org/current/userguide/build_cache.html).

Caching actual build artifacts can speed things up substantially when running multiple gradle tasks in parallel as part of separate jobs - this way each of those tasks can re-use the existing build cache.

Right now, I use a "workaround" which looks something like this:

...
      - name: Restore Gradle Build Cache
        uses: actions/cache@v2
        with:
          path: ~/.gradle/caches/build-cache-1/
          key: v1-deps-gradle-build-cache-${{ hashFiles('**/*.gradle', 'src/**/*.java') }}

      - name: Gradle Dist Tar
        uses: eskatos/[email protected]
        with:
          gradle-version: wrapper
          arguments: --no-daemon --build-cache downloadDependencies distTar -i
          wrapper-cache-enabled: true
          configuration-cache-enabled: true
          dependencies-cache-enabled: true
          dependencies-cache-key: gradle/dependency-locks/**
          dependencies-cache-exact: true
...

I think it would be nice to also support this functionality natively in this action since it already supports caching other types of data.

In fact, I hope to get a chance this week and take a stab at implementing this myself.

I do know there are some gotchas and edge cases which I need to handle correctly since just the other day I needed to re-implement all the caching from scratch for Argo project and I was bitten by some of them.

I would like to have also a special version called wrapper. If I understand it properly then if no gradle-version argument is sent then the wrapper is used. I would like to be able to do the following to be able to test against multiple versions of Gradle and the wrapper as well.

    strategy:
      fail-fast: false
      matrix:
        gradle:
        - 6.0.1
        - 5.6.4
        - 5.5.1
        - 5.4.1
        - 5.3.1
        - 5.2.1
        - 5.1.1
        - wrapper

Env:

• Project & Revision: JetBrains/Arend@b188d94
• Action Job Link: https://github.com/JetBrains/Arend/runs/813526344?check_suite_focus=true

I got this error when using gradle-command-action:

(node:1029) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
Cache Size: ~194 MB (203918722 B)
/usr/bin/tar --use-compress-program zstd -d -xf /Users/runner/work/_temp/0b7c03b1-56b8-4584-85ef-1e47171003b9/cache.tzst -P -C /Users/runner/work/Arend/Arend
../../../../../.gradle/wrapper/dists/gradle-6.5-bin/: Failed to create dir '../../../../../.gradle'
../../../../../.gradle/wrapper/dists/gradle-6.5-bin/6nifqtx7604sqp1q6g8wikw7p/: Failed to create dir '../../../../../.gradle'
../../../../../.gradle/wrapper/dists/gradle-6.5-bin/6nifqtx7604sqp1q6g8wikw7p/gradle-6.5-bin.zip.ok: Failed to create dir '../../../../../.gradle'
../../../../../.gradle/wrapper/dists/gradle-6.5-bin/6nifqtx7604sqp1q6g8wikw7p/gradle-6.5-bin.zip.lck: Failed to create dir '../../../../../.gradle'
../../../../../.gradle/wrapper/dists/gradle-6.5-bin/6nifqtx7604sqp1q6g8wikw7p/gradle-6.5-bin.zip: Failed to create dir '../../../../../.gradle'
../../../../../.gradle/wrapper/dists/gradle-6.5-bin/6nifqtx7604sqp1q6g8wikw7p/gradle-6.5/: Failed to create dir '../../../../../.gradle'
../../../../../.gradle/wrapper/dists/gradle-6.5-bin/6nifqtx7604sqp1q6g8wikw7p/gradle-6.5/LICENSE: Failed to create dir '../../../../../.gradle'
../../../../../.gradle/wrapper/dists/gradle-6.5-bin/6nifqtx7604sqp1q6g8wikw7p/gradle-6.5/bin/: Failed to create dir '../../../../../.gradle'
../../../../../.gradle/wrapper/dists/gradle-6.5-bin/6nifqtx7604sqp1q6g8wikw7p/gradle-6.5/init.d/: Failed to create dir '../../../../../.gradle'
../../../../../.gradle/wrapper/dists/gradle-6.5-bin/6nifqtx7604sqp1q6g8wikw7p/gradle-6.5/README: Failed to create dir '../../../../../.gradle'
../../../../../.gradle/wrapper/dists/gradle-6.5-bin/6nifqtx7604sqp1q6g8wikw7p/gradle-6.5/NOTICE: Failed to create dir '../../../../../.gradle'
../../../../../.gradle/wrapper/dists/gradle-6.5-bin/6nifqtx7604sqp1q6g8wikw7p/gradle-6.5/lib/: Failed to create dir '../../../../../.gradle'

Hope we can have a fix

Hi, I run a build with gradle-version: 7.0. I got an error: the version wasn't recognized. Is there a way to call it in this way or should we wait for an upgrade (using in the meantime the wrapper)? Regards

Github Actions agents are ephemeral, Gradle builds need to download the Gradle distribution, generate API jars, download dependencies etc... All this could be avoided on repeated builds by caching the relevant Gradle caches.

One can use https://github.com/marketplace/actions/cache Today but it requires some boilerplate:

- uses: actions/cache@v1
  with:
    path: ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-wrapper-${{ hashFiles('gradle/wrapper/gradle-wrapper.properties') }}
- uses: actions/cache@v1
  with:
    path: ~/.gradle/caches
    key: ${{ runner.os }}-gradle-caches-${{ hashFiles('gradle/wrapper/gradle-wrapper.properties') }}
    restore-keys: |
      ${{ runner.os }}-gradle-caches-

This issue is about reusing actions/cache mechanism from this very action to reduce that boilerplate.

Blocked on actions/cache#55

My workflow is in repository A and I used "checkout@v2" to checkout another repository B. I want to use "eskatos/gradle-command-action@v1" on a directory in repository B. How can I do this?

Hey all, thanks for the great GH Action.

It would be great if we could redirect the Gradle log output to file in some form.
Specifically having the log on file could be useful for parsing and for asserting that a task was effectively executed.

When not using this action it's as easy as run: ./gradlew tasks | tee gradle.log.
Once we switch to this action, it seems like there is no easy way to make it possible.

My configuration has stopped working suddenly ( since december 2020 ). With this error message :

Unable to locate executable file: /home/runner/work/wecolearn/wecolearn/front/android/gradlew. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

This is my config :

      - uses: actions/setup-java@v1
        with:
          java-version: 11
      - name: Install capacitor plugins
        run : cd front && ./node_modules/@ionic/cli/bin/ionic capacitor update
      - uses: eskatos/[email protected]
        with:
          arguments: :app:bundleRelease
          gradle-executable: front/android/gradlew
          build-root-directory: front/android
          wrapper-directory: front/android/gradle/wrapper

Hello,
When running the actions on windows-latest I've got this error :
'd:\a\{PROJECT_NAME}\{PROJECT_NAME}\gradlew.bat' is not recognized as an internal or external command.

Here is my action file :

name: Build

on:
  push:
    branches:
      - build

jobs:
  build:
    name: Build
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-java@v1
        with:
          java-version: 11
      - run: cd android  # cd to the android folder
      - uses: eskatos/gradle-command-action@v1
        with:
          arguments: build

According to the software environment documentation Gradle in Windows Server 2019 is in the PATH. Why doesn't the action only run gradlew task ?

Thanks !

To pass Gradle property as argument we have 2 choices:

1. Use env syntax and Gradle convention for environment variables:

 uses: eskatos/gradle-command-action@v1
      with:
         env:
           ORG_GRADLE_PROJECT_someSecret: 1234
         arguments: build

The issue of this approach is that it doesn't support properties with dots (very common practice, because of properties file)

2. Pass property as command-line argument:

 uses: eskatos/gradle-command-action@v1
    with:
        arguments: build -PsomeSecret=1234

Works fine until you have 1-2 property, but becomes issue if you have many of them, multiline support would help but it also have issues in YML, requires special syntax and not very convenient to use, it also easy to forgot slash in command

So I suggest adding support for gradle properties in yml syntax:

 uses: eskatos/gradle-command-action@v1
      with:
         properties:
            someSecret: 1234
         arguments: build

Tho, there is an issue with it, because key with dot requires escaping in YML:
some.secret should be escaped like:
"[some.secret]"

Still fine, but not perfect. There is another option. Support dot as yml separator:

properties:
  some:
     secret: 1234

For 1 simple property it may be overkill and escape will work just fine

But check this real-life example:

 - name: Build
      uses: eskatos/gradle-command-action@v1
      with:
        arguments: build --info -PsomeService.prod.apiKey=${{ secrets.SOME_SERVICE_API_KEY }} -PsomeService.prod.secret=${{ secrets.SOME_SERVICE_API_SECRET }} -PsomeService.prod.projectId=${{ secrets.SOME_SERVICE_PROJECT_ID }}

As you see, now it's not easy to follow what is going on. it will be better with nested properties syntax:

 - name: Build
      uses: eskatos/gradle-command-action@v1
      with:
        arguments: build
        properties:
           someService:
               prod:
                  apiKey: ${{ secrets.SOME_SERVICE_API_KEY }}
                  secret: ${{ secrets.SOME_SERVICE_API_SECRET }}
                  projectId: ${{ secrets.SOME_SERVICE_PROJECT_ID }}

So much better even if debug and dev environments are configured

Maybe it should be considered to do the same for system properties, which are also very common

If you think it reasonable, I may try to implement it and contribute

For all steps using gradle-command-action I'm getting deprecation warning: [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.

Is this expected or should it be fixed?

Tnx

Unless I am mistaken, if you override GRADLE_HOME env dir to be non-standard the caching functions won't work? Might be beneficial to add a note in the docs. I was just wondering why nothing was caching for my project :) Thanks!

With a gradle-distribution input that can point either to a local or a remote distribution.

I don't have the need for it yet, if you do, please add a 👍 .

When Gradle gets a hit from the configuration-cache, it is assumed that all dependencies were already downloaded and can be found in the dependency resolution cache.

Currently, it is possible to combine configuration-cache-enabled = true and dependencies-cache-enabled=false, which will always result in build failures (unless the build has no external plugins/dependencies).

Hello! Thanks for gradle-command-action!

I have code to publish image to dockerhub:

      - name: Publish to DockerHub
        uses: eskatos/gradle-command-action@v1
        with:
          arguments: -s jib
        env:
          GRADLE_OPTS: >
            -Djib.to.auth.username=${{ secrets.USERNAME }}
            -Djib.to.auth.password=${{ secrets.PASSWORD }}

How Publish image to Github Container Registry ?
Thanks!

This is more of a question than a feature request :), asking for some advice.

In AndroidX, we build multiple projects in paralel. As such, their dependencies are different, hence we tried to separate them by giving each of them a different key (to avoid them overriding each-other's cache)
This created another downside where it simply does not upload the cache due to the hit. (see warm up gradle step here: https://github.com/androidx/androidx/runs/3550347353?check_suite_focus=true)

Is it possible to pass multiple list of keys where we can control the fallback mechanism when the first hit does not match.
e.g. we have N projects, for each of them, we want to specify two keys:

projectName-withGradleFilesHash
projectName

https://github.com/androidx/androidx/pull/242/files

We actually don't even want it to fallback to the default dependencies if these two caches fail, as it will result in building on top of another project's dependencies (hence use more space in the 5GB limit).

As far as I can read this code, it currently uses 2 keys:

1. a key with given parameters
2. fallback to dependencies
   

   gradle-build-action/src/cache-dependencies.ts

   Line 39 in b3afdc7

   inputCacheExact ? [] : [cacheKeyWithArgs, cacheKeyPrefix]

It would be great if there was a way to pass the list of keys (and we can enable exact match for these keys to avoid the default dependency)

We are also open to suggestions if there is a better way to do this.

Thanks!

These cache keys are created by hashing the file names of the bundled artifacts. In order to produce consistent keys on different operating systems, these file names should be normalized before hashing.