Add cifuzz CI config for OSS-Fuzz

[ToastCheng]

After adding the Cirq to OSS-Fuzz project list, we'll need to configure GitHub action to run the CI fuzzer. This PR basically follows https://google.github.io/oss-fuzz/getting-started/continuous-integration/ to enable the workflow.

Partially implements #7515

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 99.57%. Comparing base (34cddd4) to head (224b87e). :warning: Report is 21 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff            @@
##             main    #7625    +/-   ##
========================================
  Coverage   99.57%   99.57%            
========================================
  Files        1102     1102            
  Lines       98425    98739   +314     
========================================
+ Hits        98005    98318   +313     
- Misses        420      421     +1     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ToastCheng]

Hi @pavoljuhas! From my local test, the project name needs to be in lowercase, since it's used as a Docker image name, which has a lowercase restriction. I also updated my OSS-Fuzz commit accordingly, sorry about the confusion!

(running on OSS-Fuzz repo root)
python infra/helper.py shell Cirq
INFO:__main__:Running: docker build -t gcr.io/oss-fuzz/Cirq --file /usr/local/google/home/toastcheng/dev/qc/oss-fuzz/projects/Cirq/Dockerfile /usr/local/google/home/toastcheng/dev/qc/oss-fuzz/projects/Cirq.
[+] Building 0.0s (0/0)                                                                                                                                                                          docker:default
ERROR: failed to build: invalid tag "gcr.io/oss-fuzz/Cirq": repository name must be lowercase
ERROR:__main__:Docker build failed.

Note: this command is from OSS-Fuzz debugging doc

[pavoljuhas]

Hi @pavoljuhas! From my local test, the project name needs to be in lowercase, since it's used as a Docker image name, which has a lowercase restriction. I also updated my OSS-Fuzz commit accordingly, sorry about the confusion! ...

Thank you for pointing this out! I have reverted back to the lowercase name.

On a side note, I have reassigned the review to @mhucka who has more domain knowledge with CI workflows.

[ToastCheng]

@mhucka Thank you for the suggestions and detailed explanation! I have updated the PR accordingly.

One thing I found tricky is that OSS-Fuzz doesn't have release/tag, so after the OSS-Fuzz side PR merged (so that oss-fuzz can recognize Cirq project), the commit sha needs to be updated.

Related issues on this topic:

• CIFuzz can't be pinned to a specific version #6836
• Enhancement request: Need to have releases #7172

[mhucka]

@mhucka Thank you for the suggestions and detailed explanation! I have updated the PR accordingly.

One thing I found tricky is that OSS-Fuzz doesn't have release/tag, so after the OSS-Fuzz side PR merged (so that oss-fuzz can recognize Cirq project), the commit sha needs to be updated.

Related issues on this topic:

• CIFuzz can't be pinned to a specific version #6836
• Enhancement request: Need to have releases #7172

Oh, I didn't know – thanks for that info. Hmmm this is a tricky case. I'm tempted to say it's better to use @main after all, until cifuzz makes it possible to pin to a hash, but that's not ideal either. Will the PR for this simply be a trivial 2-line change? If it's anything more than a 1-time change to update the hashes, then I would say we should go back to referencing their main.

[mhucka]

@ToastCheng Also, is the current failure in the CIFuzz job due to the hash issue? Would using @main instead of version hashes avoid that?

If yes, I propose this approach:

1. reference main instead of the hash for this PR, so that it runs without error
2. in a subsequent PR, change it to the appropriate hashes once those are known

[ToastCheng]

If it's anything more than a 1-time change to update the hashes, then I would say we should go back to referencing their main.

I would say at least one PR for bumping the version to one that includes Cirq project (commit). If there is more changes/fixes needed on the OSS-Fuzz side, then need to update again, but I'm not so sure how often will that be.

is the current failure in the CIFuzz job due to the hash issue?

It's due to the fact that Cirq isn't recognized by OSS-Fuzz project yet. It's the commit I drafted that will add Cirq's configuration to OSS-Fuzz so that OSS-Fuzz docker image (gcr.io/oss-fuzz-base/cifuzz-base) can find the corresponding info (github page, build steps etc.) to build the fuzzers.

I haven't sent out the PR to OSS-Fuzz yet, since I feel like it's better to have consensus with Cirq developers first 🙂. If no concern, I can create a OSS-Fuzz PR to unblock the CIFuzz.

Thanks!

[mhucka]

@ToastCheng Thanks for your reply. On balance, it sounds like it will be less problematic to use @main for now after all. Also, you can go ahead and submit the PR to OSS-Fuzz.

Thanks again!

[github-advanced-security[bot]]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.