Giter Club home page Giter Club logo

Comments (4)

samuelkarp avatar samuelkarp commented on June 24, 2024

The Dockerfile in oss-fuzz pulls in the instrumentation repo and then runs a script which invokes another script held in this repository. Can we remove the indirection in the oss-fuzz repo and just clone instrumentation directly in our oss_fuzz_build.sh script? That seems to remove at least one coordination point.

from containerd.

samuelkarp avatar samuelkarp commented on June 24, 2024

The use of instrumentation is not versioned at all. This can be helpful for the evolution of fuzzers, but introduces risk of breakage into our CI (i.e., cloning HEAD is not reproducible). Should we pin in our script and then bump when needed?

from containerd.

estesp avatar estesp commented on June 24, 2024

Also note that this checkout of the containerd repo does not use any information about the branch or PR in flight, although I think the "run fuzzers" does try and handle something PR related? (the default mode for the "run fuzzers" action is "code change" testing). However, I can't find the actual checking out the PR branch, but it could be hidden in the python code that gets kicked off after this checkout of main clearly seen in the project Dockerfile.

What this definitely means is that the release/1.7 fuzzer CI action and the main fuzzer CI action are doing the exact same thing for "build fuzzers" only again the 2.0 codebase; it should have broken in main when the packages were moved, but it is just silently exiting when it doesn't find the images package (moved from images/ to core/images/). Until we figure out if it is actually testing something in release/1.7 we might as well disable the action.

from containerd.

vishalRGurrala avatar vishalRGurrala commented on June 24, 2024

Hi there,

I understand your integration with oss-fuzz. I feel it is better to maintain the entire build process in the build.sh because we're anyway cloning our entire repo in the Dockerfile and also incase of any issue, it would direct all the pull requests to oss-fuzz. It is easy to maintain.

Yes, I agree it is better to maintain a specific state of instrumentation, not doing so might effect the fuzz test results.

Yes, CI action for build fuzzers is always taking the latest commit on the default branch. I verified it from the build job logs. But according to this line, the run fuzzers uses a default mode which should fetch the changes from pull request in theory. I can verify this by explicitly adding a crash scenario on my PR.

from containerd.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.