The home for Hyperlane core contracts, sdk packages, and other infrastructure
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 
hyperlane-monorepo/docs/contributing.md

2.8 KiB

Contributing to Optics

Signing Commits

💡 Please set up commit signing: See docs here

Sign them!

Set pulls to fast forward only

💡 Please read this article about squash merging

  • git config pull.ff only
    • Consider setting this globally because it's way better this way

Naming Branches

We want to know who is working on a branch, and what it does. Please use this format:

  • name/short-description
  • Examples:
    • prestwich/refactor-home
    • erinhales/merkle-tests
    • pranay/relayer-config

Commit messages

We want to know what a commit will do and be able to skim the commit list for specific things. Please add a short 1-word tag to the front, and a short sentence that fills in the blank "If applied, this commit will __________"

  • Examples:
    • docs: improve rustdoc on the Relay run function
    • feature: add gas escalator configuration to optics-base
    • test: add test vector JSON files for the merkle trees

For large commits, please add a commit body with a longer description, and bullet points describing key changes.

PRs

Please name the PR with a short sentence that fills in the blank "If applied, this PR will _________". To be merged into main a PR must pass CI in order to be merged.

Please use the Github Draft PR feature for WIP PRs. When ready for review, assign at least one reviewer from the core team. PRs should be reviewed by at least 1 other person.

PRs should ALWAYS be merged by squashing the branch.

Merging PRs

PRs can be merged once the author says it's ready and one core team-member has signed off on the changes.

Before approving and merging please do the following:

  1. Ensure that you feel comfortable with the changes being made
  2. If an existing Request Changes review exists, ask the reviewer to re-review
  3. Pull the branch locally
  4. Run the pre-commit script
  5. Ensure that the build and tests pass
  6. Give an approval
  7. Ensure that any issues the PR addresses are properly linked
  8. If any changes are needed to local environments (e.g. re-installing the build script, or installing new tooling) please record it in the documentation folder.
  9. Resolve conficts by rebasing onto target branch

Workflows

Debugging

Solidity Install

  1. Click on workflow to see where the install is failing
  2. Delete node_modules and package-lock.json in affected folder
  3. Reinstall locally
  4. Push to branch