Skip to content
ENSNode

Creating Pull Requests

Pull Request Templates

Section titled “Pull Request Templates”

We use pull request templates to help guide contributors through the process of creating a pull request.

  • Lite PR
    • The default PR template for non-significant or low-risk changes.
  • Substantial PR
    • Template for significant changes or PRs that are complex or higher-risk to review.

Standard PR Process

Section titled “Standard PR Process”
  1. Apply the appropriate Pull Request Template based on the nature of the changes.
  2. Create your PR as a “Draft” first until it is ready for review.
  3. Complete all of your work, self-reviews, and PR description updates on the PR.
  4. Complete all checkboxes on the PR description.
  5. Convert the PR from “Draft” to “Ready for Review”.
  6. Wait for automated PR reviews from Greptile and GitHub Copilot. Resolve any of their suggestions as appropriate.
  • After applying updates, if you want Greptile to make additional follow-up reviews, add a comment to the PR with the phrase “@greptile”.
  • GitHub Copilot will automatically re-review each push to the PR.
  1. Send a message to notify the ENSNode team that the PR is ready for manual-review.

Changesets

Section titled “Changesets”

We use changesets to manage version bumps and release notes for our monorepo’s artifacts (NPM packages, Docker images, and Lambda zips).

”Logical Changes”

Section titled “”Logical Changes””

A “logical change” is a cohesive set of related modifications that share a common narrative, even if it spans multiple apps/packages.

Changeset Criteria

Section titled “Changeset Criteria”

Changesets should not be created robotically for every “logical change” in a PR. We create changesets specifically for the purposes of managing version bumps and autogenerated release notes.

Only the following types of “logical changes” should be documented in a changeset:

  • Changes that should bump versions.
  • Changes that are relevant to communicate to the ENS ecosystem in release notes.

If a PR does not introduce any “logical changes” meeting the above criteria then the PR should not include a changeset.

Mapping “Logical Changes” to Changesets

Section titled “Mapping “Logical Changes” to Changesets”

Ensure that each “logical change” described in a changeset is appropriately mapped to the relevant package/app.

Example: assume changes A, B, and C in a PR pass the criteria for changesets, with the following applicability: change A applies only to package/app X, change B applies to both package/app X and package/app Y, and change C applies only to package/app Y. This means multiple distinct changesets should be created as follows:

  • Changeset 1: Documenting change A for package/app X
  • Changeset 2: Documenting change B for package/app X and package/app Y
  • Changeset 3: Documenting change C for package/app Y

In other words, avoid attaching a changeset to a package/app that is not affected by the changes.

Adding a Changeset to Your PR

Section titled “Adding a Changeset to Your PR”

When you open a PR you should include relevant changeset files that document your changes.

  1. Run pnpm changeset in the monorepo root.
  2. Select the packages/apps that the “logical change” affects using the interactive prompt.
  3. Choose the version bump type:
  • NOTE: At this time, we are NOT using semantic versioning. Breaking changes are classified as “minor” rather than “major”.
  • “major” - currently reserved only for specially approved cases
  • “minor” - breaking changes (note: ENSNode doesn’t follow standard semver where breaking = major)
  • “patch” - non-breaking changes
  1. Write a clear description of the “logical change” - this will appear in the next autogenerated release notes.

The changesets/bot will automatically comment on your PR to either remind you to add a changeset or confirm the version changes that will happen when your PR is merged.

Important notes:

  • Changesets should optimize for the narrative of the next autogenerated release notes. Optimize for how the resulting release notes will read to a developer in the ENS Ecosystem. Communicate all ideas with a positive frame by emphasizing benefits to users, describing fixes in terms of what now works, and using active, solution‑oriented language rather than focusing on past problems.
  • All apps and packages in the ENSNode monorepo use “fixed” versioning - they all share the same version number regardless of which app or package triggered the version bump.
    • An exception to the above “fixed” versioning is the “fallback-ensapi” app. This is a Lambda containing logic specific to NameHash deployments of ENSNode and is therefore versioned independently.

Changesets and Release Notes

Section titled “Changesets and Release Notes”

Upon the publishing of a new release, your change will be included in the produced artifacts and your contributions (as described in changesets) will be referenced in the autogenerated GitHub Release notes.

PR Description Checks

Section titled “PR Description Checks”

The GitHub Action for “Require PR Description Checks” will report a failing CI check on non-draft PRs where there are unchecked checkboxes in the description. You should therefore make your PR a draft PR until it is ready for review.