Skip to content

Latest commit

 

History

History
72 lines (60 loc) · 4.9 KB

CONTRIBUTING.md

File metadata and controls

72 lines (60 loc) · 4.9 KB
Raw

How to contribute to kubernetes-engine-samples

Steps to follow

  1. Submit an issue describing your proposed changes.
  2. Wait for the proposed changes to be accepted by a repo maintainer.
  3. Sign a Contributor License Agreement if you haven't done so.
  4. Fork the repo, develop, and test your code changes.
  5. Ensure that your code follows samples requirements.
  6. Create a pull request (PR).

Note that:

  • The PR reviewer may not be looking at the correctness of the code. They are generally focusing on the PR structure and that it follows samples requirements.
  • You are responsible for making prompt fixes to any issues arising with your samples. If a sample goes out-of-date or breaks, it may be deprecated, depending on business needs.

Samples requirements

All new code samples require the following:

  • Directory for all files of the sample (e.g. /databases/mysql-on-gke/**).
    • Use one of the pre-existing top-level topic directories, if possible.
  • README file with a link pointing to the tutorial or content using the sample. [Template]
    • There should only be one source of truth for sample instructions (i.e. don't duplicate instructions in the README that are or will be made available elsewhere).
  • Code that has been tested end-to-end and follows the Google style guides.
  • GitHub Action workflow that tests the sample code. At minimum, this should dry-run any container images or Terraform scripts and pass without any errors. [Template]
    • Each container image should build successfully (e.g. docker build...).
    • Each Terraform script should validate successfully (e.g. terraform validate...).
    • If there are any other quick tests that can be performed, they should also be added here.
  • Dependencies using up-to-date versions.
    • Note that we have automation in place to update these versions on a weekly-basis.
  • License headers on all source code and manifest files. [Example]
  • Region tags surrounding any file or snippets of code that will be embeded in a tutorial. [Example]
    • These surround code to be embeded and look like: [START gke_topic_sample_title_file_name] and [END gke_topic_sample_title_file_name].
  • CODEOWNERS file with an entry listing the samples maintainers. [CODEOWNERS]

Canonical container images

  • If the sample relies on canonical image artifacts, these can be hosted officially, which requires:
    • Cloud Build configs for all container images that pushes to the google-samples artifact registry. [Template]
    • A Terraform resource for the above Cloud Build configs. [Example]
      • Note that in order for the Cloud Build configs to be applied to the google-samples project, you need to run terraform init && terraform apply while in that project (a repository admin will do this for you). [Docs]
      • The images will be of the form us-docker.pkg.dev/google-samples/containers/gke<image_name>:latest

Contributor License Agreement (CLA)

Before you're able to contribute to this repository, you need to sign a Contributor License Agreement (CLA). You can follow the links below to fill out the appropriate CLA (individual, or corporate):

  • Individual CLA: You are an individual writing original source code and own the intellectual property.
  • Corporate CLA: You work for a company that allows you to contribute your work.

Follow either of the two links above to access the appropriate CLA and instructions for how to sign and return it. Once we receive it, we'll be able to accept your pull requests. You can visit https://cla.developers.google.com/ to confirm your current agreements or to sign a new one.

Community guidelines

This project follows Google's Open Source Community Guidelines.