Skip to content

Commit

Permalink
maint: update contributing guide (#10944)
Browse files Browse the repository at this point in the history 
Minor updates to CONTRIBUTING.md, things were a little outdated.
  • Loading branch information
@smartcontracts
smartcontracts committed Jun 19, 2024
1 parent 14b4425 commit 06fa881
Showing 1 changed file with 89 additions and 119 deletions.
208 changes: 89 additions & 119 deletions CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
@@ -1,66 +1,66 @@
# Optimism monorepo contributing guide
# Optimism Monorepo Contributing Guide

🎈 Thanks for your help improving the project! We are so happy to have you!
## What to Contribute

**No contribution is too small and all contributions are valued.**
Welcome to the Optimism Monorepo Contributing Guide!
If you're reading this then you might be interested in contributing to the Optimism Monorepo.
Before diving into the specifics of this repository, you might be interested in taking a quick look at just a few of the ways that you can contribute.
You can:

There are plenty of ways to contribute, in particular we appreciate support in the following areas:
- Report issues in this repository. Great bug reports are detailed and give clear instructions for how a developer can reproduce the problem. Write good bug reports and developers will love you.
- **IMPORTANT**: If you believe your report impacts the security of this repository, refer to the canonical [Security Policy](https://github.com/ethereum-optimism/.github/blob/master/SECURITY.md) document.
- Fix issues that are tagged as [`D-good-first-issue`](https://github.com/ethereum-optimism/optimism/labels/D-good-first-issue) or [`S-confirmed`](https://github.com/ethereum-optimism/optimism/labels/S-confirmed).
- Help improve the [Optimism Developer Docs](https://github.com/ethereum-optimism/docs) by reporting issues, fixing typos, or adding missing sections.
- Get involved in the protocol design process by joining discussions within the [OP Stack Specs](https://github.com/ethereum-optimism/specs/discussions) repository.

- Reporting issues. For security issues see [Security policy](https://github.com/ethereum-optimism/.github/blob/master/SECURITY.md).
- Fixing and responding to existing issues. You can start off with those tagged ["good first issue"](https://github.com/ethereum-optimism/optimism/labels/D-good-first-issue) which are meant as introductory issues for external contributors.
- Improving the [community site](https://community.optimism.io/), [documentation](https://github.com/ethereum-optimism/community-hub) and [tutorials](https://github.com/ethereum-optimism/optimism-tutorial).
- Become an "Optimizer" and answer questions in the [Optimism Discord](https://discord.optimism.io).
- Get involved in the protocol design process by proposing changes or new features or write parts of the spec yourself in the [specs repository](https://github.com/ethereum-optimism/specs).
## Code of Conduct

Note that we have a [Code of Conduct](https://github.com/ethereum-optimism/.github/blob/master/CODE_OF_CONDUCT.md), please follow it in all your interactions with the project.
Interactions within this repository are subject to a [Code of Conduct](https://github.com/ethereum-optimism/.github/blob/master/CODE_OF_CONDUCT.md) adapted from the [Contributor Covenant](https://www.contributor-covenant.org/version/1/4/code-of-conduct/).

## Workflow for Pull Requests
## Development Quick Start

🚨 Before making any non-trivial change, please first open an issue describing the change to solicit feedback and guidance. This will increase the likelihood of the PR getting merged.
### Software Dependencies

In general, the smaller the diff the easier it will be for us to review quickly.
| Dependency | Version | Version Check Command |
| ------------------------------------------------------------- | -------- | ------------------------ |
| [git](https://git-scm.com/) | `^2` | `git --version` |
| [go](https://go.dev/) | `^1.21` | `go version` |
| [node](https://nodejs.org/en/) | `^20` | `node --version` |
| [nvm](https://github.com/nvm-sh/nvm) | `^0.39` | `nvm --version` |
| [pnpm](https://pnpm.io/installation) | `^8` | `pnpm --version` |
| [foundry](https://github.com/foundry-rs/foundry#installation) | `^0.2.0` | `forge --version` |
| [make](https://linux.die.net/man/1/make) | `^3` | `make --version` |
| [jq](https://github.com/jqlang/jq) | `^1.6` | `jq --version` |
| [direnv](https://direnv.net) | `^2` | `direnv --version` |
| [docker](https://docs.docker.com/get-docker/) | `^24` | `docker --version` |
| [docker compose](https://docs.docker.com/compose/install/) | `^2.23` | `docker compose version` |

In order to contribute, fork the appropriate branch, for non-breaking changes to production that is `develop` and for the next release that is normally `release/X.X.X` branch, see [details about our branching model](https://github.com/ethereum-optimism/optimism/blob/develop/README.md#branching-model-and-releases).
### Notes on Specific Dependencies

Additionally, if you are writing a new feature, please ensure you add appropriate test cases.
#### `node`

Follow the [Development Quick Start](#development-quick-start) to set up your local development environment.
Make sure to use the version of `node` specified within [`.nvmrc`](..nvmrc).
You can use [`nvm`](https://github.com/nvm-sh/nvm) to manage multiple versions of Node.js on your machine and automatically switch to the correct version when you enter this repository.

We recommend using the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) format on commit messages.
#### `foundry`

Unless your PR is ready for immediate review and merging, please mark it as 'draft' (or simply do not open a PR yet).
`foundry` is updated frequently and occasionally contains breaking changes.
This repository pins a specific version of `foundry` inside of [`versions.json`](./versions.json).
Use the command `pnpm update:foundry` at the root of the monorepo to make sure that your version of `foundry` is the same as the one currently being used in CI.

Once ready for review, make sure to include a thorough PR description to help reviewers. You can read more about the guidelines for opening PRs in the [PR Guidelines](docs/handbook/pr-guidelines.md) file.
#### `direnv`

**Bonus:** Add comments to the diff under the "Files Changed" tab on the PR page to clarify any sections where you think we might have questions about the approach taken.

### Response time:
We aim to provide a meaningful response to all PRs and issues from external contributors within 2 business days.

### Rebasing

We use the `git rebase` command to keep our commit history tidy.
Rebasing is an easy way to make sure that each PR includes a series of clean commits with descriptive commit messages
See [this tutorial](https://docs.gitlab.com/ee/topics/git/git_rebase.html) for a detailed explanation of `git rebase` and how you should use it to maintain a clean commit history.

## Development Quick Start
[`direnv`](https://direnv.net) is a tool used to load environment variables from [`.envrc`](./.envrc) into your shell so you don't have to manually export variables every time you want to use them.
`direnv` only has access to files that you explicitly allow it to see.
After [installing `direnv`](https://direnv.net/docs/installation.html), you will need to **make sure that [`direnv` is hooked into your shell](https://direnv.net/docs/hook.html)**.
Make sure you've followed [the guide on the `direnv` website](https://direnv.net/docs/hook.html), then **close your terminal and reopen it** so that the changes take effect (or `source` your config file if you know how to do that).

### Dependencies
#### `docker compose`

You'll need the following:
[Docker Desktop](https://docs.docker.com/get-docker/) should come with `docker compose` installed by default.
You'll have to install the `compose` plugin if you're not using Docker Desktop or you're on linux.

* [Git](https://git-scm.com/downloads)
* [NodeJS](https://nodejs.org/en/download/)
* [Node Version Manager](https://github.com/nvm-sh/nvm)
* [pnpm](https://pnpm.io/installation)
* [Docker](https://docs.docker.com/get-docker/)
* [Docker Compose](https://docs.docker.com/compose/install/)
* [Go](https://go.dev/dl/)
* [Foundry](https://getfoundry.sh)
* [jq](https://jqlang.github.io/jq/)
* [go-ethereum](https://github.com/ethereum/go-ethereum)

### Setup
### Setting Up

Clone the repository and open it:

Expand All @@ -69,83 +69,21 @@ git clone git@github.com:ethereum-optimism/optimism.git
cd optimism
```

### Install the Correct Version of NodeJS

Install the correct node version with [nvm](https://github.com/nvm-sh/nvm)

```bash
nvm use
```

### Install node modules with pnpm

```bash
pnpm i
```

### Building the TypeScript packages

[foundry](https://github.com/foundry-rs/foundry) is used for some smart contract
development in the monorepo. It is required to build the TypeScript packages
and compile the smart contracts. Install foundry [here](https://getfoundry.sh/).

To build all of the [TypeScript packages](./packages), run:

```bash
pnpm clean
pnpm install
pnpm build
```

Packages compiled when on one branch may not be compatible with packages on a different branch.
**You should recompile all packages whenever you move from one branch to another.**
Use the above commands to recompile the packages.

### Building the rest of the system

If you want to run an Optimism node OR **if you want to run the integration tests**, you'll need to build the rest of the system.
Note that these environment variables significantly speed up build time.

```bash
cd ops-bedrock
export COMPOSE_DOCKER_CLI_BUILD=1
export DOCKER_BUILDKIT=1
docker compose build
```

Source code changes can have an impact on more than one container.
**If you're unsure about which containers to rebuild, just rebuild them all**:

```bash
cd ops-bedrock
docker compose down
docker compose build
docker compose up
```
### Building the Monorepo

**If a node process exits with exit code: 137** you may need to increase the default memory limit of docker containers
Make sure that you've installed all of the required [Software Dependencies](#software-dependencies) before you continue.
You will need [foundry](https://github.com/foundry-rs/foundry) to build the smart contracts found within this repository.
Refer to the note on [foundry as a dependency](#foundry) for instructions.

Finally, **if you're running into weird problems and nothing seems to be working**, run:
Install dependencies and build all packages within the monorepo by running:

```bash
cd optimism
pnpm clean
pnpm install
pnpm build
cd ops
docker compose down -v
docker compose build
docker compose up
make build
```

#### Viewing docker container logs

By default, the `docker compose up` command will show logs from all services, and that
can be hard to filter through. In order to view the logs from a specific service, you can run:

```bash
docker compose logs --follow <service name>
```
Packages built on one branch may not be compatible with packages on a different branch.
**You should rebuild the monorepo whenever you move from one branch to another.**
Use the above command to rebuild the monorepo.

### Running tests

Expand All @@ -168,12 +106,14 @@ pnpm test

#### Running unit tests (Go)

Change directory to the package you want to run tests for. Then:
Change directory to the package you want to run tests for, then:

```shell
go test ./...
```

#### Running e2e tests (Go)

See [this document](./op-e2e/README.md)

#### Running contract static analysis
Expand Down Expand Up @@ -209,7 +149,7 @@ This makes them a great tool for contributors!
[difficulty]: https://github.com/ethereum-optimism/optimism/labels?q=d-
[status]: https://github.com/ethereum-optimism/optimism/labels?q=s-

#### Filtering for Work
### Filtering for Work

To find tickets available for external contribution, take a look at the https://github.com/ethereum-optimism/optimism/labels/M-community label.

Expand All @@ -220,11 +160,41 @@ Also, all labels can be seen by visiting the [labels page][labels]

[labels]: https://github.com/ethereum-optimism/optimism/labels

#### Modifying Labels
### Modifying Labels

When altering label names or deleting labels there are a few things you must be aware of.

- This may affect the mergify bot's use of labels. See the [mergify config](.github/mergify.yml).
- If the https://github.com/ethereum-optimism/labels/S-stale label is altered, the [close-stale](.github/workflows/close-stale.yml) workflow should be updated.
- If the https://github.com/ethereum-optimism/labels/M-dependabot label is altered, the [dependabot config](.github/dependabot.yml) file should be adjusted.
- Saved label filters for project boards will not automatically update. These should be updated if label names change.

## Workflow for Pull Requests

🚨 Before making any non-trivial change, please first open an issue describing the change to solicit feedback and guidance. This will increase the likelihood of the PR getting merged.

In general, the smaller the diff the easier it will be for us to review quickly.

In order to contribute, fork the appropriate branch, for non-breaking changes to production that is `develop` and for the next release that is normally `release/X.X.X` branch, see [details about our branching model](https://github.com/ethereum-optimism/optimism/blob/develop/README.md#branching-model-and-releases).

Additionally, if you are writing a new feature, please ensure you add appropriate test cases.

Follow the [Development Quick Start](#development-quick-start) to set up your local development environment.

We recommend using the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) format on commit messages.

Unless your PR is ready for immediate review and merging, please mark it as 'draft' (or simply do not open a PR yet).

Once ready for review, make sure to include a thorough PR description to help reviewers. You can read more about the guidelines for opening PRs in the [PR Guidelines](docs/handbook/pr-guidelines.md) file.

**Bonus:** Add comments to the diff under the "Files Changed" tab on the PR page to clarify any sections where you think we might have questions about the approach taken.

### Response time

We aim to provide a meaningful response to all PRs and issues from external contributors within 2 business days.

### Rebasing

We use the `git rebase` command to keep our commit history tidy.
Rebasing is an easy way to make sure that each PR includes a series of clean commits with descriptive commit messages
See [this tutorial](https://docs.gitlab.com/ee/topics/git/git_rebase.html) for a detailed explanation of `git rebase` and how you should use it to maintain a clean commit history.

0 comments on commit 06fa881

Please sign in to comment.