We'd love to accept your patches and contributions to this project. There are just a few small guidelines you need to follow.
Contributions to this project must be accompanied by a Contributor License Agreement. You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project. Head over to https://cla.developers.google.com/ to see your current agreements on file or to sign a new one.
You generally only need to submit a CLA once, so if you've already submitted one (even if it was for a different project), you probably don't need to do it again.
We love and encourage your contributions to the RAD Lab repo. Follow the steps below to contribute on features
and bug fixes
for RAD Lab:
-
Fork the public RAD Lab repo
-
Create a
feature branch
from themain
branch of your forked repo.NOTE: Before you create the
feature branch
make sure that themain
branch of your forked repo is in sync with themain
branch of public RAD Lab repo. -
Once the development is completed, raise a PR to merge the
feature branch
(of your forked repo) intostaging
branch of the RAD Lab public repo.NOTE: Make sure that there are no conflicts and the testing is completed on the raised PR itself.
-
Code Owners will review the PR and squash & merge it into
staging
branch of the RAD Lab public repo. -
GitHub Actions tests and UI testing will be done on the internal RAD Lab staging environment, which points to the
staging
branch of the RAD Lab public repo. -
After all the testing is completed, Code Owners will rebase and merge the
staging
branch intomain
branch of the RAD Lab public repo.
The project has the following file structure:
- /docs: Documentation about the repository.
- /modules: Customisable modules to create Google Cloud Platform infrastructure & supporting scripts.
- /radlab-launcher: RAD-Lab Launcher and associated scripts to support the modules.
- /radlab-ui: Source code to deploy RAD Lab UI.
Every individual module is contained in it subdirectory and should follow these guidelines:
-
Create at least a
versions.tf
,main.tf
,variables.tf
andoutputs.tf
. It's ok to create additional files, to split resources between files and give them more meaningful names.NOTE: Make sure all the variables are in alphabetical order in
variables.tf
-
If any additional scripts (apart from terraform configs) are required to support the module either to build or use the module, move them to individual module's subdirectory, example:
/modules/[MODULE-NAME]/scripts/build
&/modules/[MODULE-NAME]/scripts/usage
respectively. -
Add the GCP architecture diagram under
modules/[MODULE_NAME]/images
with filename asarchitecture.png
for respective module. -
A README.md containing more information about the modules, required IAM permissions and any specific instructions to create the infrastructure, etc. Make sure to add at least the below mentioned Headings & Sub Headings:
-
HEADING:
# RAD LAB [MODULE-NAME] Module
: Title of the Module Specific README.
-
SUB-HEADINGS:
## Module Overview
: Description about the module.## GCP Products/Services
: List the GCP products and the sevices used in the respective module development.## Reference Architecture Diagram
: Add the GCP architecture diagram under this section. Images for module specific architechture diagrams should be stored undermodules/[MODULE_NAME]/images
with filename asarchitecture.png
for respective module.
NOTE: Add the below two tags in the RAD-Lab module specific README.md for populating structured Variables and Outputs automatically via tfdoc.py.
<!-- BEGIN TFDOC --> <!-- END TFDOC -->
-
For every module, a base configuration is determined, which can be deployed via the radlab.py launcher. The base configuration is reflected in the default values for all the variables, except for organization_id
, billing_account_id
and (optional) folder_id
.
It should be possible for people with less experience in Infrastructure As Code to use every module. The repository contains a launcher for that purpose, which can be found in the /radlab-launcher directory (radlab.py). The launcher needs to be updated whenever new modules are introduced to the repository.
Where possible, use the open source Cloud Foundation Toolkit modules to create Google Cloud infrastructure.
All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. NOTE: Create a seperate pull request for every module you create or update. Do not include changes of multiple modules in the same pull request.
Consult GitHub Help for more information on using pull requests.
This project follows Google's Open Source Community Guidelines.