SpicyPizza/create-envfile

Wrong documentation for v1.1

Hecsall opened this issue · 5 comments

Hello, I was trying to use version 1.1 of this action, and after a lot of failed attempts to make it work, I noticed that there is a required parameter that the example on the readme does not cover.

Inside the create-envfile.py at line 18 there is:

path = str(os.environ.get("INPUT_GITHUB_WORKSPACE"))

So it expects the user to manually input the GitHub workspace variable. If missing, that line will throw an error because it tries to output the env file into None/directory/.env.

To make it work it should be used like this:

- name: Make envfile
      uses: SpicyPizza/create-envfile@v1.1
      with:
        envkey_SOME_VARIABLE: "test"
        directory: somedirectory
        github_workspace: ${{ github.workspace }}

Also, in the master branch, the title in the readme should say SpicyPizza/create-envfile@master (to use the master version) and not SpicyPizza/create-envfile@v1.1, which leads to confusion since the usage is a little different.

Hope it helps

@Hecsall Thank you so much! 💯

@riboney I saw the commit on your project, maybe I should have written the issue better.
The github_workspace parameter is only needed if you use the v1.1, instead if you use the master version you can omit that parameter, see examples below:

Using v1.1

- name: Make envfile
      uses: SpicyPizza/create-envfile@v1.1
      with:
        envkey_SOME_VARIABLE: "test"
        directory: somedirectory
        github_workspace: ${{ github.workspace }} # <-- this is needed in v.1.1

Using master

- name: Make envfile
      uses: SpicyPizza/create-envfile@master
      with:
        envkey_SOME_VARIABLE: "test"
        directory: somedirectory
        # here in master the github_workspace is not needed anymore

Now it should be clearer

Awesome, thanks for the fix

@riboney In case you were interested, I believe best practice suggests not referencing @master in the README. Rather, it should reference the latest version/tag or upcoming version/tag. Then, for example, the version of README for tag v1.0 would show ...@v1.0 and the version of README for tag v1.1 would show ...@v1.1

You can see an example of this approach for tags v0 and v1 of setup-sam.

I think this should be resolved properly on 1.3 that is about to come out, so I'm going to close this for now. I'm going to make the docs point to 1.3 specifically, so people should be fine to just use it as the latest.

Feel free to check that the tests cover this case. Also, if there is outstanding changes that should be made, feel free to re-open this issue :)