✨ scorecard badges

[naveensrinivasan]

• Please check if the PR fulfills these requirements

• Tests for the changes have been added (for bug fixes / features)
  Manually tested. Need to do automate it.

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
  Feature

• What is the current behavior? (You can also link to an open issue here)
  Feature Scorecard badges #271

• What is the new behavior (if this is a feature change)?

  • Initial implementation for generating scorecard badges.
  • The calculation of the score is right now simple logic.
  • The request for the badge would be something like https://somefqdn/host/owner/repo example https://localhost:8000/github.com/18F/identity-idp
  • The badge service uses the cron results to calculate the score.
  • The service is an HTTP endpoint that is stateless.

• Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
  None

• Other information:
  Fixes Feature Scorecard badges #271

• Example of a generated badge that generated after running curl -o badge.svg https://localhost:8000/github.com/18F/identity-idp
  

[github-actions]

Integration tests success for 92146ee6a0311020606dadf570307db6816d5680

[github-actions]

Integration tests success for 9a5ce07e3727d85bc56cc2aef37357ec75c3736d

[naveensrinivasan]

ping @inferno-chromium

[oliverchang]

Thanks for working on this change!

However I'm not sure this approach will scale, and it adds significant maintenance cost since this renders the badge on demand and we need to maintain this service for serving the badges.

A much more scalable approach here would be to publish these rendered badges in a public GCS bucket instead so that we don't have to worry about the actual serving.

GCS buckets also allow access over HTTP. This is also what we do for OSS-Fuzz. See e.g. https://oss-fuzz-build-logs.storage.googleapis.com/badges/envoy.svg

[naveensrinivasan]

we

How do you think this won’t scale could you please explain further?

[dlorenc]

I'd say it's probably less about scalability, a stateless web server would likely be fine :)

Using GCS would simplify things though, and likely be more reliable/easier to maintain since we just don't have to worry about keeping things running.

[naveensrinivasan]

I'd say it's probably less about scalability, a stateless web server would likely be fine :)

Using GCS would simplify things though, and likely be more reliable/easier to maintain since we just don't have to worry about keeping things running.

I agree on that. It makes sense.

[github-actions]

Integration tests success for 3fb3a272d8f7110f7b087e16afd71bc1951b8546

[inferno-chromium]

I'd say it's probably less about scalability, a stateless web server would likely be fine :)
Using GCS would simplify things though, and likely be more reliable/easier to maintain since we just don't have to worry about keeping things running.

I agree on that. It makes sense.

it should be very simple to do this in cron code here - https://github.com/ossf/scorecard/blob/main/cron/main.go#L68
add that overall % calc logic in main scorecard code, so in json it gives that number too, and then parse that output in json in cron/main.go and create the badges in a bucket, like ossf-scorecard-badges/repo/url/badge.svg or something. this web service needs some thought and we are still thinking on dash and stuff. so, doing this unblocks and start working right away.

[naveensrinivasan]

I'd say it's probably less about scalability, a stateless web server would likely be fine :)
Using GCS would simplify things though, and likely be more reliable/easier to maintain since we just don't have to worry about keeping things running.

I agree on that. It makes sense.

it should be very simple to do this in cron code here - https://github.com/ossf/scorecard/blob/main/cron/main.go#L68
add that overall % calc logic in main scorecard code, so in json it gives that number too, and then parse that output in json in cron/main.go and create the badges in a bucket, like ossf-scorecard-badges/repo/url/badge.svg or something. this web service needs some thought and we are still thinking on dash and stuff. so, doing this unblocks and start working right away.

I agree we could move the score calculation to the main scorecard binary.

I think it should not be cronjob responsibility to generate the badge. There needs to be separation of concerns. The cronjob responsibility needs to be as is.

The reason I am calling for that is because others in the community could use the same cronjob to run scorecard on bunch of repos , but they might not want badge generation.

[inferno-chromium]

I'd say it's probably less about scalability, a stateless web server would likely be fine :)
Using GCS would simplify things though, and likely be more reliable/easier to maintain since we just don't have to worry about keeping things running.

I agree on that. It makes sense.

it should be very simple to do this in cron code here - https://github.com/ossf/scorecard/blob/main/cron/main.go#L68
add that overall % calc logic in main scorecard code, so in json it gives that number too, and then parse that output in json in cron/main.go and create the badges in a bucket, like ossf-scorecard-badges/repo/url/badge.svg or something. this web service needs some thought and we are still thinking on dash and stuff. so, doing this unblocks and start working right away.

I agree we could move the score calculation to the main scorecard binary.

I think it should not be cronjob responsibility to generate the badge. There needs to be separation of concerns. The cronjob responsibility needs to be as is.

The reason I am calling for that is because others in the community could use the same cronjob to run scorecard on bunch of repos , but they might not want badge generation.

Nobody else is running cron. We can make this configurable which is just like we have GCS_BUCKET, we can do GCS_BADGES_BUCKET, which if set, then we write the badges as well. you can create a seperate cron for badges too, but then there will be race conditions on when to generate etc. Best to keep it simple.

[naveensrinivasan]

I'd say it's probably less about scalability, a stateless web server would likely be fine :)
Using GCS would simplify things though, and likely be more reliable/easier to maintain since we just don't have to worry about keeping things running.

I agree on that. It makes sense.

it should be very simple to do this in cron code here - https://github.com/ossf/scorecard/blob/main/cron/main.go#L68
add that overall % calc logic in main scorecard code, so in json it gives that number too, and then parse that output in json in cron/main.go and create the badges in a bucket, like ossf-scorecard-badges/repo/url/badge.svg or something. this web service needs some thought and we are still thinking on dash and stuff. so, doing this unblocks and start working right away.

I agree we could move the score calculation to the main scorecard binary.
I think it should not be cronjob responsibility to generate the badge. There needs to be separation of concerns. The cronjob responsibility needs to be as is.
The reason I am calling for that is because others in the community could use the same cronjob to run scorecard on bunch of repos , but they might not want badge generation.

Nobody else is running cron. We can make this configurable which is just like we have GCS_BUCKET, we can do GCS_BADGES_BUCKET, which if set, then we write the badges as well. you can create a seperate cron for badges too, but then there will be race conditions on when to generate etc. Best to keep it simple.

Sounds good. I will change the implementation. Thanks

[oliverchang]

I'd say it's probably less about scalability, a stateless web server would likely be fine :)
Using GCS would simplify things though, and likely be more reliable/easier to maintain since we just don't have to worry about keeping things running.

I agree on that. It makes sense.

it should be very simple to do this in cron code here - https://github.com/ossf/scorecard/blob/main/cron/main.go#L68
add that overall % calc logic in main scorecard code, so in json it gives that number too, and then parse that output in json in cron/main.go and create the badges in a bucket, like ossf-scorecard-badges/repo/url/badge.svg or something. this web service needs some thought and we are still thinking on dash and stuff. so, doing this unblocks and start working right away.

I agree we could move the score calculation to the main scorecard binary.
I think it should not be cronjob responsibility to generate the badge. There needs to be separation of concerns. The cronjob responsibility needs to be as is.
The reason I am calling for that is because others in the community could use the same cronjob to run scorecard on bunch of repos , but they might not want badge generation.

Nobody else is running cron. We can make this configurable which is just like we have GCS_BUCKET, we can do GCS_BADGES_BUCKET, which if set, then we write the badges as well. you can create a seperate cron for badges too, but then there will be race conditions on when to generate etc. Best to keep it simple.

Sounds good. I will change the implementation. Thanks

Thanks @naveensrinivasan !

[naveensrinivasan]

Closing it to open a new one with the latest refacoring