cloud-concierge
  • Introduction
  • Quick Start
  • Running cloud-concierge
    • Environment Variables
    • Supported Tech Stack
    • Running Imports with CI/CD
  • How it Works
    • Pull Request Output
  • 🔓Security
  • Contributing
  • Supported Cloud Resources
    • AWS
    • Azure
    • GCP
  • Community + Resources
Powered by GitBook
On this page
  • Table of Contents
  • Introduction
  • How to contribute
  • Coding conventions
  • Pull requests
  • Release Process
  • Code of Conduct
Edit on GitHub

Contributing

Contributions, big and small, are both welcomed and encouraged!

PreviousSecurityNextSupported Cloud Resources

Last updated 1 year ago

Table of Contents

Introduction

This document is a guide for people who want to contribute to Cloud Concierge. All contributions, no matter how big or small, are greatly appreciated.

How to contribute

There are many ways to contribute to Cloud Concierge, including:

  • Providing feedback and requesting features

  • Reporting bugs and issues (either in code or in documentation)

  • Developing new features

  • Fixing bugs

Coding conventions

Pull requests

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

  1. Search existing issues or create a new issue for the feature you are creating or the bug you are fixing. Our team will reach out and help provide feedback so that the path from Pull Request to Merge is as smooth and quick as possible. Each PR should be linked to an issue.

  2. Fork the repository and create a new branch from dev.

  3. Make changes and ensure that the code passes all tests. This can be done by navigating to pkg directory of the project and running go test ./....

    • All new features should include unit tests for the new functionality.

    • To test your changes with an end to end execution of the container, you can run docker-compose up --build cloud-concierge from the root of the repository.

  4. Submit a pull request to the dev branch.

We will review your Pull Request as soon as possible (step 0. above will help expedite this process).

Release Process

NOTE: We cannot guarantee that the default branch, dev, is stable. You should always use published releases for your production use.

  • After unit test, linter and code review requirements are met, pull requests are merged to the default dev branch.

  • We tag and deploy a beta release image off of the updated dev branch, and run additional end-to-end tests on this branch to ensure new features do not break existing functionality.

Code of Conduct

Before you start contributing, please read our .

In general, we follow the , and run linting as a part of our CI/CD pipeline.

If applicable, update the to reflect your changes, if applicable.

Once validated, we merge the dev branch to the prod branch, and tag and deploy a release image off of the prod branch to . These images should be used in production.

We expect all contributors to follow our when participating in our community. Please review prior to contributing.

Introduction
How to contribute
Coding conventions
Pull request
Release Process
Code of Conduct
License
Code of Conduct
Go Style Guide
golangci
documentation
DockerHub
Code of Conduct