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

Create auto-releaser #7212

Open
oliverchang opened this issue Jan 31, 2022 · 5 comments
Open

Create auto-releaser #7212

oliverchang opened this issue Jan 31, 2022 · 5 comments

Comments

@oliverchang
Copy link
Collaborator

That runs on a weekly basis for CIFuzz and ClusterFuzzLite

@evverx
Copy link
Contributor

evverx commented Jan 31, 2022

To really pin CIFuzz I think it would be necessary to somehow also pin the base-builder image in https://github.com/google/oss-fuzz/blob/master/projects/systemd/Dockerfile. Without it it seems the action and the base builder image can diverge and break the CI suddenly.

@evverx
Copy link
Contributor

evverx commented Jan 31, 2022

More generally I think both CIFuzz and CFlite should pull docker images they are compatible with automatically. Given that dockerfiles like https://github.com/systemd/systemd/blob/main/.clusterfuzzlite/Dockerfile are never used (by users) to build images directly with docker build I'm not even sure why FROM should be specified by regular users explicitly.

@evverx
Copy link
Contributor

evverx commented Jan 31, 2022

Since CIFuzz is used upstream it's kind of easy to update it once a month with Dependabot but CFLite is supposed to be used to test forks so once releases are cut the CFLite actions and images are kind of pinned forever there so the latest images like https://github.com/google/clusterfuzzlite/blob/d223d71403114874c061c651394daec172e32e32/actions/build_fuzzers/action.yml#L52 used by auto-released actions are likely to break at some point as well. The idea behind pinning in that case is to freeze stuff that works and forget about it :-)

@evverx
Copy link
Contributor

evverx commented Jan 31, 2022

Just to be sure I wonder if unpinned actions and docker images are more likely to work in those scenarios? If so, I generally have no problem with switching to those floating tags. I'm not sure scorecard is happy about that though :-)

  "score": 6.0,
  "checks": [
    {
      "details": [
        "Warn: third-party action not pinned by hash: .github/workflows/cflite_pr.yml:28",
        "Warn: third-party action not pinned by hash: .github/workflows/cflite_pr.yml:34",
        "Warn: third-party action not pinned by hash: .github/workflows/cifuzz.yml:37",
        "Warn: third-party action not pinned by hash: .github/workflows/cifuzz.yml:44",
        "Info: GitHub-owned actions are pinned",
        "Warn: docker image not pinned by hash: .clusterfuzzlite/Dockerfile:1",
        "Info: no insecure (not pinned by hash) dependency downloads found in Dockerfiles",
        "Info: no insecure (not pinned by hash) dependency downloads found in shell scripts",
        "Info: no insecure (not pinned by hash) dependency downloads found in GitHub workflows"

@oliverchang
Copy link
Collaborator Author

If/when we do this, we need to make sure use cases like google/clusterfuzzlite#96 (comment) are supported and aren't unnecessarily spammed by default.

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

No branches or pull requests

2 participants