crytic / slither-action

GNU Affero General Public License v3.0
128 stars 20 forks source link

Disabling Foundry installation #44

Open frangio opened 1 year ago

frangio commented 1 year ago

There is currently a problem in foundry around glibc versioning that causes installation to fail in this action, resulting in a failed run. See https://github.com/foundry-rs/foundry/issues/3827

Is there a way to skip its installation entirely? In our case we have a dual Hardhat-Foundry repository so we just need Hardhat. Neither forcing the framework to Hardhat or disabling foundry compilation seems to actually skip installation in the test that I ran.

montyly commented 1 year ago

I think that if you set ignore-compile: true, and you run the install + hardhat manually before calling slither-action it might work.

I haven't tested yet, but following something like the dapp example might work: https://github.com/crytic/slither-action#example-workflow-dapp

elopez commented 1 year ago

as a workaround, you can add a - run: rm foundry.toml step on your workflow before invoking the action; this will cause foundry to not be detected and therefore installation will be skipped.

frangio commented 1 year ago

@elopez Thanks! That does it as a workaround.

thedavidmeister commented 1 year ago

I am looking for this so that i can use the foundry action to install a specific version of foundry

as it is currently slither will override any existing foundry installation on CI

elopez commented 1 year ago

hey @thedavidmeister! The Slither action runs inside a container so any existing foundry installations on the github runner are unfortunately inaccesible. If you'd like to use a foundry installation on the runner itself you can pre-build the project and then run the action with ignore-compile: true, similarly to the dapp example we have on the project readme.

(the following example is untested, but it should give you an idea of what I'm saying)

name: Slither Analysis

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout repository
      uses: actions/checkout@v3
      with:
          submodules: recursive

    - name: Install Foundry
      uses: foundry-rs/foundry-toolchain@v1

    - name: Build the contracts
      run: forge build --build-info

    - name: Run Slither
      uses: crytic/slither-action@v0.3.0
      with:
        ignore-compile: true
thedavidmeister commented 1 year ago

@elopez thanks i'll try it

PaulRBerg commented 11 months ago

I just bumped into an error that might be related to this GitHub issue. We are working on making our Foundry repos rely exclusively on Node.js dependencies (instead of git submodules), and we can't get Slither to work in CI. Always getting this error:

Done in 1.5s
[-] Did not find a requirements.txt, proceeding without installing Python dependencies.
[-] Installing dependencies from foundry.toml
Updating dependencies in /github/workspace/lib
error: pathspec '/github/workspace/lib' did not match any file(s) known to git
Error: 
git submodule exited with code 1

Slither is forcefully attempting to install some submodules in the lib directory. Why is that?

We don't want to remove the foundry.toml file because we still want to use Forge to compile the contracts. It's just that the dependencies should be sourced from node_modules (that's where our remappings point to).

Any guidance, @elopez, @montyly, @0xalpharush?

Here's the failed CI run:

https://github.com/PaulRBerg/prb-proxy/actions/runs/7087816498/job/19288940816?pr=179

elopez commented 11 months ago

hey @PaulRBerg, the Slither action just runs forge install there to install any possible dependencies your project may have.

https://github.com/crytic/slither-action/blob/main/entrypoint.sh#L233-L234

I can reproduce the same error locally on a clone of your repo:

emilio@mbpro /tmp % git clone https://github.com/PaulRBerg/prb-proxy.git -b build/include-test-utils-in-package
Cloning into 'prb-proxy'...
remote: Enumerating objects: 4114, done.
remote: Counting objects: 100% (1191/1191), done.
remote: Compressing objects: 100% (440/440), done.
remote: Total 4114 (delta 823), reused 1029 (delta 747), pack-reused 2923
Receiving objects: 100% (4114/4114), 8.34 MiB | 14.52 MiB/s, done.
Resolving deltas: 100% (2419/2419), done.
emilio@mbpro /tmp % cd prb-proxy 
emilio@mbpro prb-proxy % forge install
Updating dependencies in /private/tmp/prb-proxy/lib
error: pathspec '/private/tmp/prb-proxy/lib' did not match any file(s) known to git
Error: 
git submodule exited with code 1

It seems like Foundry doesn't like it if your project does not have a "lib" folder, but just re-adding it seems to work around the issue:

emilio@mbpro prb-proxy % forge install                                                                              
Updating dependencies in /private/tmp/prb-proxy/lib
error: pathspec '/private/tmp/prb-proxy/lib' did not match any file(s) known to git
Error: 
git submodule exited with code 1
emilio@mbpro prb-proxy % mkdir lib && touch lib/.keep && git add lib && git commit -m "fix"                         
[build/include-test-utils-in-package d3d8fba] fix
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 lib/.keep
emilio@mbpro prb-proxy % forge install                                                     
Updating dependencies in /private/tmp/prb-proxy/lib
emilio@mbpro prb-proxy %

It might be worth reporting this issue to the Foundry devs

PaulRBerg commented 11 months ago

Great sleuthing @elopez, thanks for the prompt response.

I've opened an issue in Foundry: https://github.com/foundry-rs/foundry/issues/6519

mds1 commented 9 months ago

Just noting I had a similar issue stemming from a monorepo. Our contracts package uses forge but has a package.json because there are some TS scripts in there, but the lockfile lives in a separate directory. So slither-action tried npm install, which failed because we have a preinstall script to enforce pnpm.

Here is the fix commit that removes the package.json