Skip to content

Latest commit

 

History

History
240 lines (169 loc) · 9.34 KB

CONTRIBUTING.md

File metadata and controls

240 lines (169 loc) · 9.34 KB
Raw

Contributing to OpenSSF Scorecard

Thank you for contributing your time and expertise to the OpenSSF Scorecard project. This document describes the contribution guidelines for the project.

Important

Before you start contributing, you must read and abide by our Code of Conduct.

Additionally the Linux Foundation (LF) requires all contributions include per-commit sign-offs. Ensure you use the -s or --signoff flag for every commit.

For more details, see the LF DCO wiki or this Pi-hole signoff guide.

Contributing code

Getting started

  1. Create a GitHub account
  2. Create a personal access token
  3. Set up your development environment

Environment Setup

You must install these tools:

  1. git: For source control

  2. go: You need go version v1.21.8 or higher.

  3. protoc: v3 or higher

  4. make: You can build and run Scorecard without it, but some tasks are easier if you have it.

You may need these tools for some tasks:

  1. docker: v18.9 or higher.

New to Go?

If you're unfamiliar with the language, there are plenty of articles, resources, and books. We recommend starting with several resources from the official Go website:

Contributing steps

  1. Identify an existing issue you would like to work on, or submit an issue describing your proposed change to the repo in question.
  2. The repo owners will respond to your issue promptly.
  3. Fork the desired repo, develop and test your code changes.
  4. Submit a pull request.

How to build Scorecard locally

Note that, by building Scorecard from the source code we are allowed to test the changes made locally.

  1. Clone your fork of the project locally. (Detailed instructions)
  2. Enter the project folder by running the command cd ./scorecard
  3. Install the build tools for the project by running the command make install
  4. Run the command make build to build the source code

How to run scorecard locally

In the project folder, run the following command:

# Get scores for a repository
go run main.go --repo=github.com/ossf-tests/scorecard-check-branch-protection-e2e

Many developers prefer working with the JSON output format, although you may need to pretty print it. Piping the output to jq is one way of doing this.

# Get scores for a repository
go run main.go --repo=github.com/ossf-tests/scorecard-check-branch-protection-e2e --format json | jq

To view all Scorecard commands and flags run:

# View scorecard help
go run main.go --help

You should familiarize yourself with:

  • --repo and --local to specify a repository
  • --checks and --probes to specify which analyses run
  • --format to change the result output format
  • --show-details is pretty self explanatory

Choosing checks to run

You can use the --checks option to select which checks to run. This is useful if, for example, you only want to run the check you're currently developing.

# Get score for Pinned-Dependencies check
go run main.go --repo=github.com/ossf-tests/scorecard-check-branch-protection-e2e --checks=Pinned-Dependencies

# Get score for Pinned-Dependencies and Binary-Artifacts check
go run main.go --repo=github.com/ossf-tests/scorecard-check-branch-protection-e2e --checks=Pinned-Dependencies,Binary-Artifacts

PR Process

Every PR should be annotated with an icon indicating whether it's a:

  • Breaking change: ⚠️ (:warning:)
  • Non-breaking feature: ✨ (:sparkles:)
  • Patch fix: 🐛 (:bug:)
  • Documentation changes (user or developer): 📖 (:book:)
  • Infra/Tests/Other: 🌱 (:seedling:)
  • No release note: 👻 (:ghost:)

Use 👻 (no release note) only for the PRs that change or revert unreleased changes, which don't deserve a release note. Please don't abuse it.

Prefer using the :xyz: aliases over the equivalent emoji directly when possible.

Individual commits should not be tagged separately, but will generally be assumed to match the PR. For instance, if you have a bugfix in with a breaking change, it's generally encouraged to submit the bugfix separately, but if you must put them in one PR, you should mark the whole PR as breaking.

Note

Once a maintainer reviews your code, please address feedback without rebasing when possible. This includes synchronizing your PR with main. The GitHub review experience is much nicer with traditional merge commits.

What to do before submitting a pull request

Following the targets that can be used to test your changes locally.

Command Description Is called in the CI?
make all Runs go test,golangci lint checks, fmt, go mod tidy yes
make e2e-pat Runs e2e tests yes

When developing locally, the following targets are useful to run frequently. While they are included in make all, running them individually is faster.

Command Description Called in the CI?
make unit-test Runs unit tests only yes
make check-linter Checks linter issues only yes

Changing Score Results

As a general rule of thumb, pull requests that change Scorecard score results will need a good reason to do so to get merged. It is a good idea to discuss such changes in a GitHub issue before implementing them.

Linting

Most linter issues can be fixed with golangci-lint with the following command:

make fix-linter

Permission for GitHub personal access tokens

For public repos, classic personal access tokens need the following scopes:

  • public_repo - Read/write access to public repositories. Needed for branch protection

Where the CI Tests are configured

  1. See the action files to check its tests, and the scripts used on it.

How do I add additional GitHub repositories to be scanned by scorecard weekly?

Scorecard maintains the list of GitHub repositories in a file https://github.com/ossf/scorecard/blob/main/cron/internal/data/projects.csv

GitLab repositories are listed in: https://github.com/ossf/scorecard/blob/main/cron/internal/data/gitlab-projects.csv

Append your desired repositories to the end of these files, then run make add-projects. Commit the changes, and submit a PR and scorecard would start scanning in subsequent runs.

Adding New Checks

See checks/write.md. When you add new checks, you need to also update the docs.

Adding New Probes

See probes/README.md for information about the probes.

Updating Docs

A summary for each check needs to be included in the README.md. In most cases, to update the documentation simply edit the corresponding .md file, with the notable exception of the auto-generated file checks.md.

Details about each check need to be provided in docs/checks/internal/checks.yaml. If you want to update its documentation, update that checks.yaml file.

Whenever you modify the checks.yaml file, run the following to generate docs/checks.md:

make generate-docs

DO NOT edit docs/checks.md directly, as that is an auto-generated file. Edit docs/checks/internal/checks.yaml instead.