github.com/asifdxtreme/cli@v6.1.3-0.20150123051144-9ead8700b4ae+incompatible/BUILDING.md (about)

     1  Building Cloud Foundry CLI
     2  ==========================
     3  
     4  For developing on unix systems:
     5  
     6  1. Run `./bin/build`
     7  1. The binary will be built into the `./out` directory.
     8  
     9  Optionally, you can use `bin/run` to compile and run the executable in one step.
    10  
    11  For developing on windows with powershell.exe:
    12  1. $Env:GODEP_PATH=C:\path\to\go-path\src\github.com\cloudfoundry\cli\Godeps\_workspace;
    13  1. $Env:GOPATH = $Env:GODEP_PATH + ";" + "C:\path\to\go-path\"
    14  
    15  Building Installers and Cross Compiling On Unix Systems
    16  =======================================================
    17  1. [Configure your go installation for cross compilation](https://stackoverflow.com/questions/12168873/cross-compile-go-on-osx)
    18  1. Run `bin/build-all.sh`
    19  1. Run `ci/scripts/build-installers`
    20  1. Installers will all be in the `release` dir
    21  
    22  How We Test, Build, and Release The CLI
    23  =======================================
    24  
    25  High Level Overview
    26  -------------------
    27  Every push to the master branch goes through a CI pipeline that consists of
    28  
    29  * unit tests
    30  * integration tests
    31  
    32  We run all of our tests on multiple platforms (e.g.: Linux, OS X, Windows) and
    33  on multiple architectures (eg: 32bit, 64bit). Edge builds and tagged releases
    34  are only released when all tests pass.
    35  
    36  Unit Tests
    37  ----------
    38  The first stage of every build is to run `bin/test` on all unix platforms (e.g.: 64 and 32bit Linux and OS X) and to
    39  run an equivalent `go test` command on Windows. The executables produced by `go build` from this stage are uploaded
    40  so that they can be run through integration tests and ultimately packaged into installers. This ensures that the
    41  final products are fully tested and known to have passed our entire CI process.
    42  
    43  The `ci/scripts` directory contains scripts that run tests and save the executable for each platform-architecture combination.
    44  
    45  CATS
    46  ----
    47  The [cf-acceptance-tests](https://github.com/cloudfoundry/cf-acceptance-tests) (eg: C.A.T.S.) are a suite of integration tests that
    48  drive the `cf` cli along with a real CF deployment to verify the entire system works. We have some moderate tooling
    49  to run these on different platforms, refer to the `herd-cats-$PLATFORM-$ARCH` scripts in `ci/scripts` for more
    50  information.
    51  
    52  
    53  GATS
    54  ----
    55  The CLI team identified a need for integration tests *similar* to the CATS that we maintain; we call these tests
    56  [GATS](https://github.com/tjarratt/GATS) (e.g.: GCF Acceptance Test Suite). These are run after the CATS tests,
    57  and are fairly simple to run:
    58  
    59  ```
    60  cd path/to/GATS
    61  
    62  export API=http://api.some.ip.v4.address.xip.io
    63  export ADMIN_USER=admin-user
    64  export ADMIN_PASSWORD=admin-password
    65  export CF_USER=user-name
    66  export CF_USER_PASSWORD=user-password
    67  export ORG=org-name
    68  export SPACE=space-name
    69  export APP_HOST=persistent-app-host
    70  
    71  bin/configure
    72  bin/test
    73  ```
    74  
    75  
    76  Build and Release to S3
    77  -----------------------
    78  At the very end of our pipeline, assuming all tests have passed, we run a fairly simple script that uploads our
    79  binaries and installers to the appropriate bucket on S3.
    80  
    81  ```
    82  export AWS_SECRET_ACCESS_KEY=SECRET_KEY_IS_SECRET
    83  export AWS_ACCESS_KEY_ID=WINK
    84  
    85  ci/scripts/build-and-release
    86  ```
    87  
    88  This script fetches the binaries that were produced earlier, generates installers for our supported platforms
    89  and then uploads the final artifacts to S3.
    90  
    91  Tagged Releases On Github
    92  -------------------------
    93  Every time we push to the master branch, a release is created in a directory in the go-cli bucket on our S3 account.
    94  We make these URLs public so that people can try the edge builds.  Refer to our README for the URLs for some of these artifacts.
    95  
    96  Commits that have a release tag on them (e.g.: v6.1.0) go into special directories that have the release name in them.
    97  
    98  e.g.: http://go-cli.s3-website-us-east-1.amazonaws.com/releases/v6.1.0/