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

[infra] Publish build badges on status page #2513

Merged
merged 3 commits into from
Aug 12, 2019

Conversation

ammaraskar
Copy link
Contributor

What?

This implements a feature for the oss-fuzz build pipeline similar to how Travis, GCB, coverage tools offer the ability to have a little image badge representing whether builds are passing.

building
coverage_failing
failing

These will automatically get pushed out by the build_status.py script on Jenkins and the images will be available on https://oss-fuzz-build-logs.storage.googleapis.com/badges/cpython3.png for example.

Why?

A lot of high profile FOSS projects are using oss-fuzz but without visiting the projects subdirectory it's hard to gauge just how many projects that is. A lot of projects like tensorflow and python prominently display their badges in the README. Hopefully this should let people glance at the status of their oss-fuzz builds as well as direct some attention to oss-fuzz.


!! Needs Testing !!

I've done some best effort manual testing without involving the GCP components, if people are actually interested in this feature then more thorough testing is needed.

@Dor1s
Copy link
Contributor

Dor1s commented Jun 13, 2019

And then OSS-Fuzz participating projects could have a link on their GitHub page to those icons? I think that would be awesome, feels like someone even has asked for a similar feature in the past.

@jonathanmetzman
Copy link
Contributor

And then OSS-Fuzz participating projects could have a link on their GitHub page to those icons? I think that would be awesome, feels like someone even has asked for a similar feature in the past.

Yup, see #738

infra/gcb/builds_status.py Outdated Show resolved Hide resolved
infra/gcb/builds_status.py Outdated Show resolved Hide resolved
infra/gcb/builds_status.py Outdated Show resolved Hide resolved
infra/gcb/builds_status.py Outdated Show resolved Hide resolved
infra/gcb/builds_status.py Outdated Show resolved Hide resolved
@jonathanmetzman
Copy link
Contributor

I'm not so sure we want the badge to point at whether the build is succeeding since this isn't the point of OSS-Fuzz, maybe we should discuss this more.

@Dor1s
Copy link
Contributor

Dor1s commented Jun 14, 2019

Good point, but what else can we indicate? A successful build means there is continuous fuzzing happening with ToT build, which is the point of OSS-Fuzz. Can change the text on the icon though.

@ammaraskar
Copy link
Contributor Author

ammaraskar commented Jun 14, 2019

The basic idea is as Max said, I was using the build status as a closest approximation to whether ClusterFuzz has something new to run on.

We could do it at the clusterfuzz level, if a project hasn't had any fuzzing executions in an hour or more the badge could be marked as failing. This would also let us put up a number like:

image

which might be cool.

@jonathanmetzman
Copy link
Contributor

The basic idea is as Max said, I was using the build status as a closest approximation to whether ClusterFuzz has something new to run on.

We could do it at the clusterfuzz level, if a project hasn't had any fuzzing executions in an hour or more the badge could be marked as failing. This would also let us put up a number like:

image

which might be cool.

Some other ideas: bugs (which might turn people off), coverage.

@Dor1s
Copy link
Contributor

Dor1s commented Jun 14, 2019

Some other ideas: bugs (which might turn people off), coverage.

!!! Yes, please!

Getting execution numbers would be harder (as we'd need a CF change for that). Coverage is easy (there are public JSON files, just read them and generate icons) and feels more informative than number of executions.

@ammaraskar
Copy link
Contributor Author

Badges changed to:

building
coverage_failing
failing

@ammaraskar ammaraskar marked this pull request as ready for review June 27, 2019 02:37
@ammaraskar
Copy link
Contributor Author

@oliverchang Could you PTAL? This does need testing on the actual jenkins instance.

Copy link
Collaborator

@oliverchang oliverchang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@inferno-chromium inferno-chromium merged commit 8776ec2 into google:master Aug 12, 2019
@evverx
Copy link
Contributor

evverx commented Aug 12, 2019

Thank you!

I'm wondering what these badges are supposed to point to. Normally badges lead to dashboards like https://semaphoreci.com/systemd/systemd, https://travis-ci.org/systemd/systemd, https://lgtm.com/projects/g/systemd/systemd/context:cpp and so on. I'm not sure where I should end up after clicking on OSS-Fuzz. If projects fail to build it makes sense to go to https://oss-fuzz-build-logs.storage.googleapis.com/index.html but coverage reports like https://oss-fuzz.com/coverage-report/job/libfuzzer_asan_systemd/latest are much more useful in general I think.

@inferno-chromium
Copy link
Collaborator

Good idea. Both options should be ok, just depends on how we document this, we can have different template for fuzzing and coverage links.

@evverx
Copy link
Contributor

evverx commented Aug 12, 2019

I think I'll just add a link to https://oss-fuzz.com, which seems to be as close to a dashboard where all the data including links to build logs and coverage reports are gathered as it's currently possible. Though given that access to it is limited It would be great if there was a landing page of some kind that would be at least partly public.

ebraminio added a commit to harfbuzz/harfbuzz that referenced this pull request Aug 20, 2019
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

Successfully merging this pull request may close these issues.

None yet

6 participants