Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scan argument will just scan folder inside the container? #23

Open
ydmk opened this issue Sep 9, 2023 · 6 comments
Open

Scan argument will just scan folder inside the container? #23

ydmk opened this issue Sep 9, 2023 · 6 comments

Comments

@ydmk
Copy link

ydmk commented Sep 9, 2023

Looking at the scan parameter

- '--scan'
- '${{ inputs.path }}'

If a . is provided here (as is the default), won't it just scan the home directory inside the container? github's working directory is mounted at /github/workspace (as indicated by the out parameter in

- '--out'
- '/github/workspace/${{ inputs.out }}'
)

So doesn't /github/workspace need to be prefixed to inputs.path (if it's a relative path), to scan in github's actual workspace?

additionally what do you do if someone provides absolute paths (in this case and in the case of out)?

i can do a pr if needed

@javixeneize
Copy link

I think those paths are where the code is checked out, can’t remember by heart. That’s a parameter that can be modified anyway. When you execute it, it will show the absolute path it is using

@ydmk
Copy link
Author

ydmk commented Sep 10, 2023

  • those paths are given to the docker container as is:
    runs:
    using: 'docker'
    image: 'Dockerfile'
    args:
    - '--project'
    - '${{ inputs.project }}'
    - '--scan'
    - '${{ inputs.path }}'
    - '--format'
    - '${{ inputs.format }}'
    - '--out'
    - '/github/workspace/${{ inputs.out }}'
    - '--noupdate'
    - ${{ inputs.args }}
  • the container's entrypoint.sh then passes it straight to the cli sitting inside
  • that's why the --out parameter requires that prefix (/github/workspace), because it needs to write back to the host filesystem, not the container's
  • since the cli needs to scan the code in the host's file system (the code), it needs to look at /github/workspace also
  • --scan is indeed configurable, but the discrepancy between --scan and --out is weird and inconsistent.
    • with one parameter (--out), you write in terms of your host's file system (the action prefixes it with the github workspace location inside the container itself), with the other (--scan), you write in terms of the container's file system (since the prefix isn't added by the action)
    • this is not something a normal user of this action would expect (they wouldn't even know that github action containers bind the host's workspace at /github/workspace inside the container unless they read the documentation).

@javixeneize
Copy link

Ah, i see. I think both . and /github/workspace point to the same place, isnt it?

https://github.com/dependency-check/DependencyCheck_Test/actions/runs/6136166905/job/16650728404#step:5:8

There, it is mounting this as a volume

-v "/home/runner/work/DependencyCheck_Test/DependencyCheck_Test":"/github/workspace"

Sorry, its been long time since i built this

@ydmk
Copy link
Author

ydmk commented Sep 29, 2023

Let me clarify it further.

. in your host is the same as /github/workspace in your container. This is documented in the github actions documentation, and, as you saw in your test, happens due to mounting the . of your host to your /github/workspace of the container.

Your executable runs inside the container. The arguments provided to the executable run from the context of inside the container.

Now when someone says that their scan param is ., they mean to say that the . of their own directory (which is the host's).
However, what the executable interprets is . of the container, which is some directory inside the container where the exe is running (probably /home/root). For the executable to translate . to the correct directory (the . of the host), it needs to point to /github/workspace/.

@ydmk
Copy link
Author

ydmk commented Sep 29, 2023

you basically need to prefix line 28 with the prefix you have in line 32 (/github/workspace)

@javixeneize
Copy link

javixeneize commented Sep 29, 2023

Right ;)

fancy doing a pr with the change?

thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants