slingnode.ethereum
  • Overview
    • Supported clients
    • Supported OSes
    • Requirements
  • Using the role
  • Role Variables
  • Architecture
    • Exposing ports
    • Security
    • Docker & host firewall
  • JWT secret
  • Enabling Validator client API
  • Checkpoint sync
  • Switching clients
  • Metrics
  • Logging
  • Testing
  • Contributing
  • Known issues
Powered by GitBook
On this page
  • Workflow
  • Git workflow
  • Branch naming
  • Commit messages
  • Versioning
  • Will you accept my pull request if it doesn't follow the above?
  • Testing

Was this helpful?

Contributing

This page contains contributing guidelines.

First of all, thank you for considering contributing to this project!

There are several ways to contribute:

  • Spread the word about the project

  • Suggest features

  • Tell us how you use the project / contribute to examples project

  • Contribute support for new clients

  • Contribute test cases

  • Submit bugs and issues

Workflow

Git workflow

The project follows a simple git trunk based workflow:

  • 'master' branch which is the current latest stable version

  • we develop in feature branches which then get tested and merged into master

Branch naming

Branch naming is as follows:

git branch feature/issue-42/add-new-client-support
git branch feature/no-ref/refactor-consensus-tasks

'issue' refers to a Github issue.

Commit messages

They should begin with on of the three below prefixes, be short and descriptive. We like keeping it simple.

git commit -m 'feat: add support Teku consensus and validator'
git commit -m 'fix: update type in geth docker compose template'
git commit -m 'refactor: refactor execution deployment tasks'

Versioning

Will you accept my pull request if it doesn't follow the above?

Yes. Ultimately we want this be a community driven project, if you have written code you want to contribute we'll happily review it and merge it.

Testing

PreviousTestingNextKnown issues

Last updated 2 years ago

Was this helpful?

We use Semantic Versioning 2.0.0 -> .

We take testing seriously. Ideally your pull request would be tested against project's test suite. See for details. However, we will test all pull requests before merging them.

https://semver.org/
Testing