Skip to content

Latest commit

 

History

History
65 lines (50 loc) · 3.33 KB

CONTRIBUTING.md

File metadata and controls

65 lines (50 loc) · 3.33 KB
Raw

Contributing to cf-release

The Cloud Foundry team uses GitHub and accepts contributions via pull request.

The cf-release repository is a BOSH release for Cloud Foundry.

If you wish to make a change to any of the components, submit a pull request to those repositories directly. Once accepted those changes should make their way into cf-release. All components are submodules in cf-release and can be found in the src/ directory.

To learn about how you can contribute to Cloud Foundry please visit our contributing page

Proposing new Features

Please see the Proposing New Features page on the Cloud Foundry community wiki that explains the process for getting the team's buy-in on your contribution before you start work.

General Workflow

  1. Collaborate with the team before you start work

  2. Fork the repository and make a local clone

  3. Create a feature branch from the development branch

    cd cf-release
git checkout develop
./scripts/update
git checkout -b better_cf-release

  4. Build and deploy the checked out version of cf-release. We recommend using bosh-lite for this.

    cd cf-release
./scripts/generate-bosh-lite-dev-manifest

bosh create release
bosh upload release
bosh deploy

  5. Make changes on your branch.

  6. Update and run manifest generation tests and other basic tests ./scripts/test.

  7. Re-deploy your version of cf-release.

  8. Run Cloud Foundry Acceptance Tests (CATS). We recommend running the tests as a bosh errand (bosh run errand acceptance_tests). You won't see any output from the tests until the errand completes. If you choose to run them manually, please follow the instructions in the CATS README.

  9. Set up git hooks by running ./scripts/setup-git-hooks and commit your work. This will ensure that the same set of tests as ./scripts/test run as a pre-commit hook before any commit.

  10. Push to your fork (git push origin better_cf-release) and submit a pull request selecting develop as the target branch.

We favor pull requests with very small, single commits with a single purpose.

Your pull request is much more likely to be accepted if:

  • Your pull request includes tests. The runtime development team uses test driven development to help ensure high quality code and excellent test coverage.

  • Your pull request is small and focused with a clear message that conveys the intent of your change.