[FR]: Providing working-directory as an input param

[yudintsevegor]

Is your feature request related to a problem? Please describe.
We would like to use this github action for the directory with subdirectories, which contain go.* files.
Unfortunately, the action doesn't work if the root directory doesn't contain go.* files. It forces as having steps in github actions - run: mv ./* ./../../

Describe the solution you'd like
I guess, the solution might be an optional working-directory input param with a default value ${{ github.workspace }}.

Describe alternatives you've considered
Honestly, i haven't thought of any better solution for the users, but the implementation might be improved - I am not so experienced with shell scripts.

Additional context
The error which we got:

6:56PM ERR Scanning yielded error error="running govulncheck binary produced govulncheck: no go.mod file\n\ngovulncheck only works with Go modules. Try navigating to your module directory.\nOtherwise, run go mod init to make your project a module.\n\nSee https://go.dev/doc/modules/managing-dependencies for more information.\n"

Implementation notes:

• the input param working-directory with default value ${{ github.workspace }} was provided
• the script determine-wd.sh was added to set correctly working directory for the github action and for the docker container as they are a little bit different (see below)
• --workdir and -v can't use relative path - it should be provided as absolute ones (e.g. /kek/lol instead of ./kek/lol)
• run.working-directory can use only relative paths, that's why we can't use the same value for docker ... -v and docker ... --workdir and run.working-directory (https://docs.github.com/en/actions/sharing-automations/creating-actions/metadata-syntax-for-github-actions#runsstepsworking-directory)

e2e testing:
yudintsevegor/playground#1
f.e.: yudintsevegor/playground@f6a3b51

Concerns:

• the current implementation allows the user to provide both absolute and relative paths: working-directory: ./kek/lol and working-directory: /kek/lol are both valid. I wonder if it's fine 🤔

Notes:

• if it's approved by the owner of the repo, I am happy to try to provide some tests for this impl. I tested it in our private repo for now.

[yudintsevegor]

Hey @Templum!

I can't modify Labels and Assignees to assign the correct things there 🤔

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.20%. Comparing base (e7476a5) to head (f7b0e70).

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #98   +/-   ##
=======================================
  Coverage   70.20%   70.20%           
=======================================
  Files           5        5           
  Lines         433      433           
=======================================
  Hits          304      304           
  Misses        124      124           
  Partials        5        5           

Flag	Coverage Δ
unit-tests	70.20% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Templum]

Can you perform an E2E Run against your change and link the result here ? Sadly the testing I have does not cover E2E (only once merged). And given this change does not touch "code" the existing tests aren't helpful

[Templum]

Would you be so kind to walk me through your code here ?

I see that DOCKER_WD & GITHUBH_WD in the most cases have the same content

[yudintsevegor]

Yes, sure!

The content is not exactly the same. Let me provide more details, which could simply the understanding:

• if the provided github.worspace is empty --> the execution is not possible. The reason for that is to be sure that the first argument is github.worspace as we use it as a default case.
• if the github_workspace == input_working_directory OR the input_working_directory == "" (as a second arg) we could use github_workspace as a default use case.

if 2 args are provided, we could forget about github_workspace and use input_working_directory for our processing:

• if input_working_directory starts with / then for the docker we would use it as it is (docker accepts only absolute paths), but for the github workdir we would need to add a dot as a prefix: ./ (GitHub working-directory should be relative path)
• input_working_directory starts with ./ then for the docker we would remove a dot from the beginning with a help of sed command (docker accepts only absolute paths) and use input_working_directory as it is for the github actions (GitHub working-directory should be relative path)

[yudintsevegor]

This morning I tried to implement it in Go with tests (you could see commits below), but I gave up this idea because it's not possible to set the env variable from the go program to use it outside of it. I guess it could be a workaround, but probably with sh script is cleaner

[Templum]

No worries, probably having a shell script is fine for this case. I also don't think any extra test needs to be done. The E2E Flow that we have in place, should be sufficient enough.

[yudintsevegor]

@Templum wow, thank you so much for the quick response! I will back to the PR a little bit later 😅
I didn't expect you to answer so fast

[yudintsevegor]

@Templum

Can you perform an E2E Run against your change and link the result here ? Sadly the testing I have does not cover E2E (only once merged). And given this change does not touch "code" the existing tests aren't helpful

Do you mean create a repo to use this workflow or something else?

[Templum]

@Templum

Can you perform an E2E Run against your change and link the result here ? Sadly the testing I have does not cover E2E (only once merged). And given this change does not touch "code" the existing tests aren't helpful

Do you mean create a repo to use this workflow or something else?

Exactly, you could use your repo that was used to produce the screenshot. And specify this branch and let it run

[yudintsevegor]

@Templum yudintsevegor/playground#1 check this :)

the commit with a branch: yudintsevegor/playground@f6a3b51

[Templum]

Thanks for your contribution, it looks good to me. The linked test runs where also successful and did not show any issues. From what I can tell, this change should not be breaking any previous behaviour

[Templum]

@yudintsevegor thanks for your contribution, I will merge it later. And then eventually release it. However, last release had some issue... Which I will need to read up on.

[yudintsevegor]

@Templum thank you so much for the quick cooperation!

I haven't updated the docs and didn't update the version. Shall I do it or you want to do it on your own? 👀

[Templum]

@Templum thank you so much for the quick cooperation!

I haven't updated the docs and didn't update the version. Shall I do it or you want to do it on your own? 👀

You can follow the release progress over @ #100, will need to address the issue of the previous release attempt. The documentation I already adjusted based on what you did in the action.yaml.

[Templum]

This was released as part of v1.0.2