[FEAT] Please document that selector are using JSONata

[mook-as]

Is your feature request related to a problem? Please describe. I'm using a kv2 store, with a key that had a dash: foo-bar. This produced errors that we difficult to resolve: Unable to retrieve result for data.data.foo-bar. No match data was found. Double check your Key or Selector.

Upon reading the source code, I found references to JSONata; reading their docs, I found that I could escape things with backquotes, and this resolved the issue.

Describe the solution you'd like Please add in the relevant section in the README that the selector syntax is using JSONata.

Describe alternatives you've considered I guess ripping the library out and doing something home-grown is fine too? But that seems like a lot of work, and the actual problem is just documenting it (which would have to be done either way).

Additional context

uses: hashicorp/[email protected]

[doowb]

In case this is helpful to anyone else that needs to retrieve the entire JSON object from the secret, you can use $.$ as the selector:

secrets: secret/path/to/my-secret $.$ | MY_SECRET;

Just using $ or * might have worked with jsonata, but the selector is quoted here when it doesn't contain a .. It would be nice to be able to just do . or * to get the entire object, but I think that would be a separate feature request and I'm not sure where it would fit.

[anthonydahanne]

@doowb thanks so much for sharing $.$ - I could not find another way to grab the entire JSON under data.data !!!

[dcmoore-gd]

Same thank you @doowb!

[RichiCoder1]

This has bit enough people that I'll see if I can document this as well as add an easier wildcard shortcut.

[dcmoore-gd]

Wonderful, thank you @RichiCoder1!

[benkeil]

after one year, any progress here? how could such a basic feature not be included from the first day?

[atomlab]

any updates?

[maxcoulombe]

Hi, I was going to look at this issue but could no reproduce the problem with a quick test. Can anybody confirm if I am doing something wrong or perhaps the issue has been fixed since this was opened?

Create a Vault KV secret with dashes:

curl -X POST -H "X-Vault-Token: $VAULT_TOKEN" -d "{"data": {"secret-with-dashes": "my-secret"}}" $VAULT_ADDR/v1/secret/data/test-with-dash

Read the secret with dashes in a vault-action:

jobs:
  build:
    name: local-test
    runs-on: ubuntu-latest
    steps:
      - name: Import Secrets
        id: import-secrets
        uses: hashicorp/[email protected]
        with:
          url: ${{ secrets.VAULT_ADDR }}
          method: token
          token: ${{ secrets.VAULT_TOKEN }}
          secrets: |
            secret/data/secret-with-dashes my-secret | DASH;

Vault version: Vault v1.12.3

[fairclothjm]

Hello! Is there any recent update on this issue? Are you still experiencing this issue?

[mook-as]

I'm afraid I've stopped using vault-action some time in the last 2½ years; I see though that jsonata is still in use and the documentation is still rather light (but I can't confirm if it works now).

[maxcoulombe]

I added a small precision to the doc to indicate the selectors use JSONata so it's more obvious if any characters need to be escaped.

The issue discussed here with dashes couldn't be reproduced and we have an acceptance test in place to catch any regression. With these measures in place I think it's safe to close this issue.

Thanks for bringing this up and if anyone is able to reproduce the original issue please let us know!