🌱 Update Scorecard API usage

[azeemshaikh38]

Recent changes to scorecard-webapp API updates how Scorecard Action should integrate with the API. This PR make the necessary updates:

• Use the updated POST URL - /projects/{host}/{org}/{repo}
• Use the updated POST JSON
• Pass the GITHUB_TOKEN to the API for scalability

Along with these changes, updates how Golang Scorecard Action will be built and tested:

• Adds a new Dockerfile.golang and cloudbuild.yaml to update how Golang Action is built.
• Updates documentation about e2e tests.

Part of #133. golang-staging branch will be deleted and need not be maintained after necessary changes to e2e tests are deployed.

[justaugustus]

Left some style comments and questions.

@ossf/scorecard-maintainers -- As an overarching goal, but also using this PR as context, we need to work on pull request hygiene/telling a story for future passerbys (which may include us).

Here's a quick list of questions/comments that I have:

Part of #133. Will update golang-staging branch to use the public image scorecard-action

• How is the golang-staging branch used?
• Is this well-documented?
• How does this relate to Feature: Scorecard badges #133 (enabling Scorecard badges through the scorecard GitHub Action)?
• The PR title and commit message says "Update Scorecard API usage", but it does not explain what is being changed or how it's being changed. https://github.com/kubernetes/sig-release/blob/master/CONTRIBUTING.md#contributing-code contains some pretty good guidance here.
• The additional infra changes, like the Dockerfile and cloudbuild.yaml, should be a separate commit, again explaining why they need to be added
• Is there a reason we prefer gcr.io instead of GH container registry?
• I'm not sure I agree with adding yet another Dockerfile (this was part of the reason for the direction in image: Build the scorecard command from this repo's wrapper instead of copying #316 and ✨ [WIP] Migrate Golang-based entrypoint for GitHub Actions scorecard#1962)

[codecov]

Codecov Report

Merging #336 (b8a85e5) into main (8e9099b) will decrease coverage by 0.39%.
The diff coverage is 73.33%.

@@            Coverage Diff             @@
##             main     #336      +/-   ##
==========================================
- Coverage   64.28%   63.88%   -0.40%     
==========================================
  Files           4        4              
  Lines         210      216       +6     
==========================================
+ Hits          135      138       +3     
- Misses         67       69       +2     
- Partials        8        9       +1     

Impacted Files	Coverage Δ
signing/signing.go	32.14% <73.33%> (+1.37%)	⬆️

[azeemshaikh38]

• How is the golang-staging branch used?
• Is this well-documented?

There is some documentation here about how golang-staging branch is being used in e2e tests - https://github.com/ossf/scorecard-action/tree/main/e2e. TLDR; is that golang-staging branch is used to deploy Scorecard action Golang code as a GitHub action without affecting the current bash action. We use it to test any changes to the Golang code.

• How does this relate to Feature: Scorecard badges #133 (enabling Scorecard badges through the scorecard GitHub Action)?

I made some updates to the scorecard-webapp repo recently which changed the API (needed for the badges work). The current PR basically makes the necessary updates here to keep the integration working.

• The PR title and commit message says "Update Scorecard API usage", but it does not explain what is being changed or how it's being changed. https://github.com/kubernetes/sig-release/blob/master/CONTRIBUTING.md#contributing-code contains some pretty good guidance here.

I will make another attempt at the PR description once we have reached an agreement on the overall changes.

• The additional infra changes, like the Dockerfile and cloudbuild.yaml, should be a separate commit, again explaining why they need to be added

Below answers should probably cover why these were added.

• Is there a reason we prefer gcr.io instead of GH container registry?

No strong reason except for personal familiarity with Google Cloud infra and that Scorecard image itself resides in GCP. Ok to use anything else.

• I'm not sure I agree with adding yet another Dockerfile (this was part of the reason for the direction in image: Build the scorecard command from this repo's wrapper instead of copying #316 and ossf/scorecard#1962)

The extra Dockerfile is only temporary (until we release the Golang code and delete any bash related code). Even today, we maintain 2 separate Dockerfiles (the second one lives in golang-staging).

[justaugustus]

Thanks @azeemshaikh38!
I may have more follow-up questions, but let's get the CI checks unblocked first and foremost.