Skip to content

Latest commit

 

History

History
144 lines (101 loc) · 6.71 KB

CONTRIBUTING.md

File metadata and controls

144 lines (101 loc) · 6.71 KB

Contributing to Digger

Welcome to the contributing guide for Digger! We appreciate your interest in contributing to our open source project.

FEEDBACK: The best way to contribute to Digger today is by using it within your organisation and providing feedback. If you are considering using Digger please drop us a line, and we would be happy to set you up.

Table of Contents

Introduction

Digger is an open source terraform cloud alternative. We believe that open source software is important, and we welcome contributions from anyone who is interested in making our platform better. This document is intended to be a guide for people who want to contribute to Digger. We appreciate all contributions, no matter how big or small.

AI Assistance Notice

Important

We have an AI assistance policy inspired by ghostty. We copied the same policy with a few modifications below If you are using any kind of AI assistance to contribute to Digger, it must be disclosed in the pull request.

If you are using any kind of AI assistance while contributing to Digger, this must be disclosed in the pull request, along with the extent to which AI assistance was used (e.g. docs only vs. code generation). If PR responses are being generated by an AI, disclose that as well. As a small exception, trivial tab-completion doesn't need to be disclosed, so long as it is limited to single keywords or short phrases.

An example disclosure:

This PR was written primarily by Claude Code.

Or a more detailed disclosure:

I consulted ChatGPT to understand the codebase but the solution was fully authored manually by myself.

Failure to disclose this is first and foremost rude to the human operators on the other end of the pull request, but it also makes it difficult to determine how much scrutiny to apply to the contribution.

In a perfect world, AI assistance would produce equal or higher quality work than any human. That isn't the world we live in today, and in most cases it's generating slop. I say this despite being a fan of and using them successfully myself (with heavy supervision)!

When using AI assistance, we expect contributors to understand the code that is produced and be able to answer critical questions about it. It isn't a maintainers job to review a PR so broken that it requires significant rework to be acceptable.

Please be respectful to maintainers and disclose AI assistance.

How to contribute

If you are considering using digger within your organisation please reach out to us we would be happy to help onboard you to use it. There are many ways to contribute to Digger, including:

  • Providing feedback
  • Reporting bugs and issues
  • Improving documentation
  • Adding new features
  • Fixing bugs
  • Writing tests
  • And more!

Before you start contributing, please read our Code of Conduct to understand what is expected of contributors.

Coding conventions

We strive to maintain a consistent coding style throughout the project. Please follow our coding conventions when making changes to the codebase.

Folder structure

libs/ # contains libraries that are common between digger cli and digger cloud backend (should NOT import anything from cli/pkg/ which is cli specific)
cli/cmd/ # contains the main cli files
cli/pkg/ # contains packages that are used by the cli code, can import from libs/
backend/ # contains the backend code, can import from libs/
ee/ # contains the ee code, can import from libs/ and the other ce packages (but ce must not import from ee)
docs/ # contains documentation pages

Submitting a pull request

When you have made changes to the codebase that you would like to contribute back, please follow these steps:

  1. Fork the repository and create a new branch from develop.

  2. Make your changes and ensure that the code passes all tests.

  3. Write tests for your changes, if applicable.

  4. Test out your changes in a demo GitHub repository using Github Actions.

    • You can test out the changes from your fork by referencing the Action within a Github workflow file: uses: <github-username>/digger@your-branch.
    • Fork this demo repository to setup and assert your tests.
    • If you're adding new app level inputs that implies new environment variables, make sure to reference them both within the build digger and run digger steps in action.yml.

  5. Update the documentation to reflect your changes, if applicable.

  6. Submit a pull request to the develop branch. We will review your pull request as soon as possible. Please be patient and open to feedback. We appreciate your contributions!

Release Process

NOTE: The default branch @develop is not guaranteed to be stable and you should always use published release versions in your testing and production environments.

  • All pull requests are merged to the default develop branch after initial unit tests and integration tests are passing and required code review requirements are met.
  • We checkout a pre-release branch to prepare for an upcoming release with the pattern prerelease-0.1.xx.
  • We perform additional manual and automated tests in this branch to make sure there are no regressions.
  • Once we are ready we tag the head of our release branch and perform a release on it.
  • Tagged releases are published as actions and they are the most suitable to be used in production.

How to test locally

The easiest way to test locally is to follow our Testing locally instructions.

Code of Conduct

We expect all contributors to follow our Code of Conduct when participating in our community. Please read it carefully before contributing.

License

Digger is released under the MIT. By contributing to this project, you agree to license your contributions under the same license.

Attributions

If you include code from other projects, you must retain the original copyright and license notices in those files.
Please also add a clear comment noting the source of the code (project name, license, and link).