Skip to content
This repository was archived by the owner on Nov 9, 2020. It is now read-only.

developer.md

Latest commit

 

History

History
78 lines (58 loc) · 3.2 KB

developer.md

File metadata and controls

78 lines (58 loc) · 3.2 KB

Developer's Guide

Prerequisites

The assumption Chaperone makes for developers is not something one would propose is light, but not out of the norm for many. We assume reasonable competence in the following:

Contributing

The Chaperone team welcomes contributions from the community.

Submit issues and PRs through github.

If you wish to contribute code and you have not signed our contributor license agreement (CLA), our bot will update the issue when you open a Pull Request. For any questions about the CLA process, please refer to our FAQ.

Getting the code

Instructions to setup, install and deploy the Chaperone UI tools and underlying Ansible plays, Python modules and other required code bases are here

Structure and Standards

TODO

Development Workflow

General public enhancements or fixes on individual code repositories

Use case:

You've found bug found in a single role or playbook, you would like to submit a fix, and you don't have push privileges to the original repository.

the steps

  1. Use an existing Chaperone base or run a typical repo init as described in the setup docs to pull original Chaperone sources down
  2. fork the original role or playbook repository in Github under your own account
  3. add your remote in the source tree ( cd ansible/roles/role-to-fix; git remote add myfork https://github.com/myaccount/myrepo )
  4. make edits in the role/playbook, commit them
  5. push your work to your fork: git push myfork
  6. in github make a Pull Request from your fork to the origin repo

new contributors will need to fill out the CLA.

Long Running Project

In some cases, we need to do work for customers or for specific projects that will require long running divergence of the repo manifest. These manifest changes are may not intended to be pushed back to origin/master for public consumption, but must be available to other people working on the same project.

Some examples of this use case:

  • Isolated environments, where access to public repositories is blocked by firewall
  • Team working on a feature not ready or intended for public release

the steps

  1. Github fork the chaperone manifest repo (https://github.com/vmware/chaperone)
  2. clone your fork: git clone git@github.com:yourname/chaperone.git
  3. edit the manifest as needed to point to internal, forked, or non-standard role/playbook repositories
  4. git commit and git push to your fork
  5. in a new project directory, checkout the new manifest: repo init https://github.com/yourname/chaperone
  6. make your changes as needed
  7. use repo as normal to work with your set of repos
  8. team members can use your same repo init to make changes on the same set of repos

If you later want to push changes back to the upstream master, create PRs back to the origin from your forked repos