cloudfoundrycli

module
v6.0.1+incompatible Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Feb 24, 2014 License: Apache-2.0

README

Cloud Foundry CLI Build Status

This is the official command line client for Cloud Foundry. cf v6.0.0 is the current supported release.

Stable Release (v6.0.0)

Installers

Binaries

Edge Releases (master)

Edge binaries are published to our Amazon S3 bucket with each new commit that passes CI. These binaries are not intended for wider use, but for developers to test new features and fixes as they are completed:

You can follow our development progress on Pivotal Tracker.

Filing Bugs

For simple bugs (eg: text formatting, help messages, etc), please provide
  • the command you ran
  • what occurred
  • what you expected to occur
  • the command you ran
  • the trace output
  • a high-level description of the bug
For panics and other crashes, please provide
  • the command you ran
  • the stack trace generated (if any)
  • any other relevant information

Cloning the repository

  1. Install Go
  2. Clone (Forking beforehand for development).
  3. Run git submodule update --init --recursive

Building

  1. Run ./bin/build
  2. The binary will be built into the ./out directory.

Optionally, you can use bin/run to compile and run the executable in one step.

Developing

  1. Write a Ginkgo test.
  2. Run bin/test and watch the test fail.
  3. Make the test pass.
  4. Submit a pull request.

Contributing

Architecture overview

The app (in src/cf/app/app.go) declares the list of available commands, which are composed of a Name, Description, Usage and any optional Flags. The action for each command is to instantiate a command object, which is invoked by the runner (in src/cf/commands/runner.go).

A command has Requirements, and a Run function. Requirements are used as filters before running the command. If any of them fails, the command will not run (see src/cf/requirements for examples of requirements).

When the command is run, it communicates with api using repositories (they are in src/cf/api).

Dependencies are injected into each command, so tests can inject a fake. This means that dependencies are typically declared as an interface type, and not a concrete type. (see src/cf/commands/factory.go)

Some dependencies are managed by a repository locator in src/cf/api/repository_locator.go.

Repositories communicate with the api endpoints through a Gateway (see src/cf/net). Repositories return a Model and an ApiResponse object by convention. Consumers are expected to check the ApiResponse for success or failure, much like an error.

Models are data structures related to Cloud Foundry (see src/cf/models). For example, some models are apps, buildpacks, domains, etc.

ApiResponse objects convey a variety of important error conditions (see src/cf/net/api_response.go).

Managing dependencies

Command dependencies are managed by the commands factory. The app uses the command factory (in src/cf/commands/factory.go) to instantiate them, this allows not sharing the knowledge of their dependencies with the app itself.

As for repositories, we use the repository locator to handle their dependencies. You can find it in src/cf/api/repository_locator.go.

Example command

Create Space is a good example of a command. Its tests include checking arguments, requiring the user to be logged in, and the actual behavior of the command itself. You can find it in src/cf/commands/space/create_space.go.

Current conventions

Creating Commands

Resources that include several commands have been broken out into their own sub-package using the Resource name. An example of this convention is the Space resource and package (see src/cf/commands/space)

In addition, command file and methods naming follows a CRUD like convention. For example, the Space resource includes commands such a CreateSpace, ListSpaces, DeleteSpace, etc.

Creating Repositories

Although not ideal, we use the name "Repository" for API related operations as opposed to "Service". Repository was chosen to avoid confusion with Service model objects (i.e. creating Services and Service Instances within Cloud Foundry).

By convention, Repository methods return a model object and an ApiResponse. Models are used in both Commands and Repositories to model Cloud Foundry data. ApiResponse objects are used to communicate application errors, runtime errors, whether the resource was found, etc. This convention provides a consistent method signature across repositories.

Directories

Path Synopsis
src
cf
code.google.com/p/go.net/dict
Package dict implements the Dictionary Server Protocol as defined in RFC 2229.
Package dict implements the Dictionary Server Protocol as defined in RFC 2229.
code.google.com/p/go.net/html
Package html implements an HTML5-compliant tokenizer and parser.
Package html implements an HTML5-compliant tokenizer and parser.
code.google.com/p/go.net/html/atom
Package atom provides integer codes (also known as atoms) for a fixed set of frequently occurring HTML strings: tag names and attribute keys such as "p" and "id".
Package atom provides integer codes (also known as atoms) for a fixed set of frequently occurring HTML strings: tag names and attribute keys such as "p" and "id".
code.google.com/p/go.net/html/charset
Package charset provides common text encodings for HTML documents.
Package charset provides common text encodings for HTML documents.
code.google.com/p/go.net/idna
Package idna implements IDNA2008 (Internationalized Domain Names for Applications), defined in RFC 5890, RFC 5891, RFC 5892, RFC 5893 and RFC 5894.
Package idna implements IDNA2008 (Internationalized Domain Names for Applications), defined in RFC 5890, RFC 5891, RFC 5892, RFC 5893 and RFC 5894.
code.google.com/p/go.net/ipv4
Package ipv4 implements IP-level socket options for the Internet Protocol version 4.
Package ipv4 implements IP-level socket options for the Internet Protocol version 4.
code.google.com/p/go.net/ipv6
Package ipv6 implements IP-level socket options for the Internet Protocol version 6.
Package ipv6 implements IP-level socket options for the Internet Protocol version 6.
code.google.com/p/go.net/netutil
Package netutil provides network utility functions, complementing the more common ones in the net package.
Package netutil provides network utility functions, complementing the more common ones in the net package.
code.google.com/p/go.net/proxy
Package proxy provides support for a variety of protocols to proxy network data.
Package proxy provides support for a variety of protocols to proxy network data.
code.google.com/p/go.net/publicsuffix
Package publicsuffix provides a public suffix list based on data from http://publicsuffix.org/.
Package publicsuffix provides a public suffix list based on data from http://publicsuffix.org/.
code.google.com/p/go.net/spdy
Package spdy implements the SPDY protocol (currently SPDY/3), described in http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3.
Package spdy implements the SPDY protocol (currently SPDY/3), described in http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3.
code.google.com/p/go.net/websocket
Package websocket implements a client and server for the WebSocket protocol as specified in RFC 6455.
Package websocket implements a client and server for the WebSocket protocol as specified in RFC 6455.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL