Incomplete example for GitHub action integration

[auumai-mattia]

The documentation mentions it is possible to use the env provider to read secrets in a Github action workflow.

When trying to run a job step in a devenv like this:

 - name: Build API Docker Image via devenv
   shell: devenv shell bash -- -e {0}
   run: secretspec run --provider env -- build-api-image

where I've loaded environment variables in a previous step, I keep encountering an error:

Error:   × No provider backend configured.
  │ 
  │ To fix this, either:
  │   1. Run 'secretspec config init' to set up your default provider
  │   2. Use --provider flag (e.g., 'secretspec check --provider keyring')

I have also tried using a different provider, but it still complaints about a missing secretspec configuration. None of the documentation contains details on how to add this configuration during a GitHub action. I tried manually writing a simple .toml file during the Github action, but this didn't seem to work either.

Would be great if the documentation highlights what the right approach to do here is. Obviously, running the secretspec config init command can't be done because it is interactive.

[domenkozar]

Can you link to a github run to see what's happening? Something else must be going on.

[auumai-mattia]

After some experimentation I was able to make it work in the end like this:

 - name: Build API Docker Image via devenv
    shell: devenv shell bash -- -e {0}
    env:
       SECRETSPEC_PROVIDER: ${{ secrets.SECRETSPEC_PROVIDER_DEVELOPMENT }}
       SECRETSPEC_PROFILE: development
    run: secretspec run -- build-api-image

However, this is turning somewhat suboptimal because I would ideally like to keep separate profiles for separate components in my stack. I should not need to keep a development profile and share all of my development creds for building just the API. Additionally, keeping separate profiles for separate stacks would speed up the eval time when setting up the shell because I can scope the secretspec profile to only use API specific credentials, making the loading of these credentials faster (as there will be fewer).

The issue with scoping the credentials in the above way, however, is that I would also need separate shells for each component, and that is rather complicated to setup. @domenkozar you got any advice?

Note that I also had to use a 1password action to use the op provider to make the above work:

        - name: Install 1Password CLI
          uses: 1password/install-cli-action@v2

[domenkozar]

I think we should add devenv secretspec subcomannd to devenv to make this easier.