Feature request - Gradle Properties options

[gildor]

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

[eskatos]

Hi @gildor,
Sorry for the late response.

I can see how this can be annoying. But then you would have to deal with more YAML, I'm not sure I'm fond of it. It's a tradeoff between long arguments and 'complex' YAML.

I'm not against such an addition and agree that system properties should be implemented too if we go down that route.

The behaviour when one sets the same property in arguments and properties should be clarified though.

[gildor]

Thanks for reply

The behaviour when one sets the same property in arguments and properties should be clarified though.

Agree, probably properties should be added after build arguments, it makes implementation simple (no need to parse and alter arguments somehow) and allows debug what kind properties are passed to gradle in build logs (because properties would be converted to arguments)

t's a tradeoff between long arguments and 'complex' YAML.

It's true, not a huge fan of more yaml, but we have what we have, and more readable workflow file is with a clear separation between tasks arguments and build properties makes sense here

[eskatos]

Agree, probably properties should be added after build arguments, it makes implementation simple (no need to parse and alter arguments somehow) and allows debug what kind properties are passed to gradle in build logs (because properties would be converted to arguments)

Converting the properties to arguments sounds good.
About precedence, I guess the choice is between prepending or appending to arguments.
IOW, yaml properties have precedence, or arguments have.
I guess the former, appending, is reasonable.

[gildor]

Yes, appending as simple and straight forward solution so properties have precedence

[vlsi]

One of the issues is GitHub actions runner does not provide access to YAML configuration. It supports literal values only, and even YAML lists are not supported yet.

On the other hand, the following might be not that bad (I'm not sure if multi-line arguments already work, but it can definitely be supported):

 - 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 }}

or

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

[bigdaz]

@vlsi I really like your idea.
@gildor I've opened #88 to add support for multi-line arguments, and will close this issue in preference to that solution.

Please add a comment if you feel a structured properties approach has some clear advantages.
Thanks!