Arthur HALET
26 yearsbirth (birthday) - permis
tphone: 06-79-21-39-53

E: arthurh.halet@gmail.com
fr.png uk.png

Projets personnels

buildpack-always-fail cf-chocolatey ciwatch deaph
A buildpack to show what's wrong in cloudfoundry's dea A chocolatey package to install cloudfoundry cli This is a useful tool to see all status from your ci tools in a wink (tools like travis, scrutinizer, SensioLabsInsight or CodeClimate). A php deployer
Voir le readme

Not Found

Voir le readme


A chocolatey package to install official command line client for Cloud Foundry.


  1. Install chocolatey (follow instructions chocolatey: https://chocolatey.org/
  2. Run in your prefered cli $ choco install cf
  3. You've done.


To maintain always up-to-date this choco package with https://github.com/cloudfoundry/cli I've made a php script which can be run everyday.

To try it run with php in cli command $ php rebuild.php.

It will:

  1. Check if version between this github and the https://github.com/cloudfoundry/cli are the same
  2. Recreate tools\chocolateyinstall.ps1 and cf.nuspec with this new version.
  3. Repack the nugget package with the cpack command.
  4. Push to https://chocolatey.org this new package.
Voir le readme


This is a useful tool to see all status from your ci tools in a wink (tools like travis, scrutinizer, SensioLabsInsight or CodeClimate).

It provides also tools to directly create CI environment in one time and permit you to restart inspection on a repo.

[Logo CIWatch](Logo CIWatch)

Voir le readme

What is deaph

Deaph is a deployer very flexible which you can use to deploy what you want through FTP, SFTP, Dropbox, Zip, Local or Amazon S3 After deploying your files you can use step as the same way as puppet or chief.


Deaph is .phar file you can download it.

How to use

dialog-watson-client dockerfiles echo-colors ep_cloudfoundry
Client for dialog watson module Repo of dockerfiles Echo in CLI with colors easily by using colorstring Etherpad lite plugin for cloudfoundry support
Voir le readme


Client for dialogs watson module


  • Python 2.7
  • Pip


Install with pip: pip install dialog-watson-client

Run the playground

Simply run in command line: dialog-watson-client --name=dialog-name path/to/dialog/file [--clean](optional: clean your dialogs in watson) and you will chat with your robot

At the first launch it will create a config file located to ~/.config-dialog-watson.yml and ask you your watson credentials

Usage for developers

Bootstrap example:

from dialog_watson_client.Client import Client
watsonClient = Client('user_watson', 'password_watson', 'file/path/to/dialog', 'your_dialog_name') # this library abstract the registering of dialog (and the update when you cahnge it) and run it, to do that it will store your dialog id in a file called `dialog_id_file.txt`
watsonClient.start_dialog() # this will create the dialog into watson or update it and run the initialization of the conversation

resp = watsonClient.converse('hi') # talk to the robot, here it will say 'hi' and watson will answered
print resp.response # show the response from watson
watsonClient.get_profile().get_data() # get extracted data from watson in format: [key => value]

Note: If your file is in xml (and you have lxml lib installed) it will also check your format with xsd: https://www.ibm.com/smarterplanet/us/en/ibmwatson/developercloud/doc/dialog/download/WatsonDialogDocument_1.0.xsd

Voir le readme


Repo of dockerfiles

Voir le readme


Echo in CLI with colors easily by using colorstring.


On *nix system

You can install this via the command-line with either curl or wget.

via curl

$ sh -c "$(curl -fsSL https://raw.github.com/ArthurHlt/echo-colors/master/bin/install.sh)"

via wget

$ sh -c "$(wget https://raw.github.com/ArthurHlt/echo-colors/master/bin/install.sh -O -)"

On windows

You can install it by downloading the .exe corresponding to your cpu from releases page: https://github.com/ArthurHlt/echo-colors/releases . Alternatively, if you have terminal interpreting shell you can also use command line script above, it will download file in your current working dir.

From go command line

Simply run in terminal:

$ go get github.com/ArthurHlt/echo-colors


   echoc - Echo in colors some text easily

   echoc "[red] this is red [yellow]and yellow [_red_]with red background [bold] and bold [reset] and no colors"


   -n           Optional. Do not print the trailing newline character
   --help, -h       show help
   --version, -v    print the version
Voir le readme


generate-sql-data gh-stats ghorg github-blob-sender
Generate sql data for a given size some stats about repos and orgs in github Analyse a github organization to find top contributors by commit and number of repos Send a file into github blob in command line (written in golang)
Voir le readme


Generate sql data for a given size


On *nix system

You can install this via the command-line with either curl or wget.

via curl

$ sh -c "$(curl -fsSL https://raw.github.com/ArthurHlt/generate-sql-data/master/bin/install.sh)"

via wget

$ sh -c "$(wget https://raw.github.com/ArthurHlt/generate-sql-data/master/bin/install.sh -O -)"

On windows

You can install it by downloading the .exe corresponding to your cpu from releases page: https://github.com/ArthurHlt/generate-sql-data/releases . Alternatively, if you have terminal interpreting shell you can also use command line script above, it will download file in your current working dir.

From go command line

Simply run in terminal:

$ go get github.com/ArthurHlt/generate-sql-data


Usage: generate-sql-data [file size] [file name] (e.g.: generate-sql-data 1mb fakedata.sql)
Voir le readme

Not Found

Voir le readme


Analyse a github organization to find top contributors by commit and number of repos

Voir le readme


Send a file into github blob in command line (written in golang)

gitlab-accept-mr-cli annotations arhframe iocart
Accept automatically all opened merge request in a project on Gitlab The arhframe php framework. Ioc which use the spring style.
Voir le readme


Accept automatically all opened merge request in a project on Gitlab.


On *nix system

You can install this via the command-line with either curl or wget.

via curl

$ sh -c "$(curl -fsSL https://raw.github.com/ArthurHlt/gitlab-accept-mr-cli/master/bin/install.sh)"

via wget

$ sh -c "$(wget https://raw.github.com/ArthurHlt/gitlab-accept-mr-cli/master/bin/install.sh -O -)"

On windows

You can install it by downloading the .exe corresponding to your cpu from releases page: https://github.com/ArthurHlt/gitlab-accept-mr-cli/releases . Alternatively, if you have terminal interpreting shell you can also use command line script above, it will download file in your current working dir.

From go command line

Simply run in terminal:

$ go get github.com/ArthurHlt/gitlab-accept-mr-cli


   accept-mr - Automatically accept Merge Request on project

   accept-mr [global options] command [command options] [arguments...]


     help, h  Shows a list of commands or help for one command

   --url value, -u value      Url to your gitlab [$GITLAB_URL]
   --token value, -t value    User token to access the api [$GITLAB_TOKEN]
   --project value, -p value  Project name where accepting mr (e.g.: owner/repo) [$GITLAB_PROJECT]
   --failed-on-error, -e      If true accept in error exit with status code > 0
   --insecure, -k             Ignore certificate validation
   --log-json, -j             Write log in json
   --no-color                 Logger will not display colors
   --on-build-succeed, --bs   Merge request will automatically accepted if pipeline succeeded
   --help, -h                 show help
   --version, -v              print the version
Voir le readme

Not Found

Voir le readme

Not Found

Voir le readme


IocArt is an another IOC (inversion of Control) and he is close too Spring Ioc style. The main point is that IocArt have his context file in yml. Bean is "class" wich you can inject inside their properties:

  • Another bean
  • Property file
  • A yaml file read by yamlarh
  • A stream

You can also import other yaml context in a yaml context


Through Composer, obviously:

    "require": {
        "arhframe/iocart": "1.*"


use Arhframe\IocArt\BeanLoader;

$beanLoader = BeanLoader::getInstance();


util yamlarh
Util libraries for arhframe Yml injector for arhframe in standalone
Voir le readme


Util libraries for arhframe

Voir le readme


Yml injector for arhframe in standalone. You can inject into your yaml:

  • object
  • constant from scope
  • Variable from global scope
  • Variable from yaml file

You can also import other yaml inside a yaml file for overriding


Through Composer, obviously:

    "require": {
        "arhframe/yamlarh": "1.*"


use Arhframe\Yamlarh\Yamlarh;

$yamlarh = new Yamlarh(__DIR__.'/path/to/yaml/file');
$array = $yamlarh->parse();


Variable injection

Variable injection is hierarchical, it will find in this order:

  1. In the yaml file with import
  2. In your global scope
  3. In you constant

Yaml file:

  myvar1: test
  myvar2: %arhframe.myvar1%
  myvar3: %var3%
  myvar4: %VARCONSTANT%

Php file:

use Arhframe\Yamlarh\Yamlarh;
$var3 = 'testvar';
define('VARCONSTANT', 'testconstant');
$yamlarh = new Yamlarh(__DIR__.'/test.yml');
$array = $yamlarh->parse();
echo print_r($array);


      [arhframe] => Array
              [myvar1] => test
              [myvar2] => test
              [myvar3] => testvar
              [myvar4] => testconstant


Object injection

It use snakeyml (yaml parser for java) style:

  file: !! Arhframe.Util.File(test.php) #will instanciate this: Arhframe\Util\File('test.php') in file var after parsing


Import are also hierarchical the last one imported will override the others. Use @import in your file:


  var1: var
test: arhframe

 - file2.yml #you can use a relative path to your yaml file or an absolute


  var1: varoverride
test2: var3

After parsing file1.yml, yml will look like:

  var1: varoverride
test: arhframe
test2: var3


You can include a yaml file into another:


  var1: var
    - file2.yml #you can use a relative path to your yaml file or an absolute


test2: var3

After parsing file1.yml, yml will look like:

  var1: var
  test2: var3

Contribues aux projets

bosh-cli cachet-monitor cf-java-client cf-ssh
New BOSH CLI (beta) Monitors a URL and posts data points to cachet Java client library and tools for Cloud Foundry SSH into a running container for your Cloud Foundry application, run one-off tasks, debug your app, and more.
Voir le readme

bosh CLI


Client Library

This project includes director and uaa packages meant to be used in your project for programmatic access to the Director API.

See docs/example.go for a live short usage example.

Developer Notes

Voir le readme

Not Found

Voir le readme

Cloud Foundry Java Client

The cf-java-client project is a Java language binding for interacting with a Cloud Foundry instance. The project is broken up into a number of components which expose different levels of abstraction depending on need.

  • cloudfoundry-client – Interfaces, request, and response objects mapping to the Cloud Foundry REST APIs. This project has no implementation and therefore cannot connect a Cloud Foundry instance on its own.
  • cloudfoundry-client-spring – The default implementation of the cloudfoundry-client project. This implementation is based on the Spring Framework RestTemplate.
  • cloudfoundry-operations – An API and implementation that corresponds to the Cloud Foundry CLI operations. This project builds on the cloudfoundry-cli and therefore has a single implementation.
  • cloudfoundry-maven-plugin / cloudfoundry-gradle-plugin – Build plugins for Maven and Gradle. These projects build on cloudfoundry-operations and therefore have single implementations.

Most projects will need two dependencies; the Operations API and an implementation of the Client API. For Maven, the dependencies would be defined like this:


The artifacts can be found in the Spring release and snapshot repositories:

        <name>Spring Releases</name>
        <name>Spring Snapshots</name>

For Gradle, the dependencies would be defined like this:

dependencies {
    compile "org.cloudfoundry:cloudfoundry-client-spring:$cfJavaClientVersion"
    compile "org.cloudfoundry:cloudfoundry-operations:$cfJavaClientVersion"

The artifacts can be found in the Spring release and snapshot repositories:

repositories {
    maven { url "http://repo.spring.io/release" }
repositories {
    maven { url "http://repo.spring.io/snapshot" }


Both the cloudfoundry-operations and cloudfoundry-client projects follow a "Reactive" design pattern and expose their responses with Reactive Streams Publishers. The choice to expose Reactive Streams Publishers gives the project interoperability with the various reactive framework implementations such as Project Reactor and RxJava. In the examples that follow, Project Reactor is used, but all reactive frameworks work similarly.

CloudFoundryClient and CloudFoundryOperations Builders

The lowest-level building block of the API is a CloudFoundryClient. This is only an interface and the default implementation of this is the SpringCloudFoundryClient. To instantiate one, you configure it with a builder:


In Spring-based applications, you'll want to encapsulate this in a bean definition:

CloudFoundryClient cloudFoundryClient(@Value("${cf.host}") String host,
                                      @Value("${cf.username}") String username,
                                      @Value("${cf.password}") String password) {
    return SpringCloudFoundryClient.builder()

The CloudFoundryClient provides direct access to the raw REST APIs. This level of abstraction provides the most detailed and powerful access to the Cloud Foundry instance, but also requires users to perform quite a lot of orchestration on their own. Most users will instead want to work at the CloudFoundryOperations layer. Once again this is only an interface and the default implementation of this is the DefaultCloudFoundryOperations. To instantiate one, you configure it with a builder:

new CloudFoundryOperationsBuilder()
    .target("example-organization", "example-space")

In Spring-based applications, you'll want to encapsulate this in a bean definition as well:

CloudFoundryOperations cloudFoundryOperations(CloudFoundryClient cloudFoundryClient,
                                              @Value("${cf.organization}") String organization,
                                              @Value("${cf.space}") String space) {
    return new CloudFoundryOperationsBuilder()
            .target(organization, space)

CloudFoundryOperations APIs

Once you've got a reference to the CloudFoundryOperations, it's time to start making calls to the Cloud Foundry instance. One of the simplest possible operations is list all of the organizations the user is a member of. The following example does three things:

  1. Requests a list of all organizations
  2. Extracts the name of each organization
  3. Prints the name of the each organization to System.out

To relate the example to the description above the following happens:

  1. Streams.wrap(...) – Wraps the Reactive Streams Publisher (an interoperability type) in the Reactor-native Stream type
  2. .map(...) – Maps an input type to an output type. This example uses a method a reference and the equivalent lambda would look like organization -> organization.getName().
  3. consume... – The terminal operation that consumes each item in the stream. Again, this example uses a method reference and the the equivalent lambda would look like name -> System.out.println(name).

CloudFoundryClient APIs

As mentioned earlier, the cloudfoundry-operations implementation builds upon the cloudfoundry-client API. That implementation takes advantage of the same reactive style in the lower-level API. The implementation of the Organizations.list() method (which was demonstrated above) looks like the following (roughly):

ListOrganizationsRequest request = ListOrganizationsRequest.builder()

    .flatMap(response -> Streams.from(response.getResources))
    .map(resource -> {
        return Organization.builder()

The above example is more complicated:

  1. Streams.wrap(...) – Wraps the Reactive Streams Publisher in the Reactor-native Stream type
  2. .flatMap(...) – substitutes the original stream with a stream of the Resources returned by the requested page
  3. .map(...) – Maps the Resource to an Organization type

Maven Plugin

TODO: Document once implemented

Gradle Plugin

TODO: Document once implemented


The project depends on Java 8 but is built to be Java 7 compatible. To build from source and install to your local Maven cache, run the following:

$ ./mvnw clean install

To run the the integration tests, run the following:

$ ./mvnw -Pintegration-test clean test

IMPORTANT Integration tests should be run against an empty Cloud Foundry instance. The integration tests are destructive, nearly everything on an instance given the chance.

The integration tests require a running instance of Cloud Foundry to test against. We recommend using MicroPCF to start a local instance to test with. To configure the integration tests with the appropriate connection information use the following environment variables:

Name Description
TEST_HOST The host of Cloud Foundry instance. Typically something like api.local.micropcf.io.
TEST_ORGANIZATION The default organization to use for testing
TEST_PASSWORD The test user's password
TEST_SKIPSSLVALIDATION Whether to skip SSL validation when connecting to the Cloud Foundry instance. Typically true when connecting to a MicroPCF instance.
TEST_SPACE The default space to use for testing
TEST_USERNAME The test user's username


Pull requests and Issues are welcome.


This project is released under version 2.0 of the Apache License.

Voir le readme


SSH into a running container for your Cloud Foundry application, run one-off tasks, debug your app, and more.

Initial implementation requires the application to have a manifest.yml.

Also, cf-ssh requires that you run the command from within the project source folder. It performs a cf push to create a new application based on the same source code/path, buildpack, and variables. Once CF Runtime supports copy app bits #78847148, then cf-ssh will be upgraded to use app bit copying, and not require local access to project app bits.

It is desired that cf-ssh works correctly from all platforms that support the cf CLI.

Windows is a target platform but has not yet been tested. Please give feedback in the Issues.


This tool requires the following CLIs to be installed

It is assumed that in using cf-ssh you have already successfully targeted a Cloud Foundry API, and have pushed an application (successfully or not).

This tool also currently requires outbound internet access to the http://tmate.io/ proxies. In future, to avoid the requirement of public Internet access, it would be great to package up the tmate server as a BOSH release and deploy it into the same infrastructure as the Cloud Foundry deployment.

Why require ssh CLI?

This project is written in the Go programming language, and there is a candidate library go.crypto that could have natively supported an interactive SSH session. Unfortunately, the SSL supports a subset of ciphers that don't seem to work with tmate.io proxies [stackoverflow]

Using the go.crypto library I was getting the following error. In future, perhaps either tmate.io or go.crypto will change to support each other.

unable to connect: ssh: handshake failed: ssh: no common algorithms


Download a pre-compiled release for your platform. Place it in your $PATH or %PATH% and rename to cf-ssh (or cf-ssh.exe for Windows).

Alternately, if you have Go setup you can build it from source:

go get github.com/cloudfoundry-community/cf-ssh


cd path/to/app
cf-ssh -f manifest.yml

Publish releases

To generate the pre-compiled executables for the target platforms, using gox:

gox -output "out/{{.Dir}}_{{.OS}}_{{.Arch}}" -osarch "darwin/amd64 linux/amd64 windows/amd64 windows/386" ./...

They are now in the out folder:

-rwxr-xr-x  1 drnic  staff   4.0M Oct 25 23:05 cf-ssh_darwin_amd64
-rwxr-xr-x  1 drnic  staff   4.0M Oct 25 23:05 cf-ssh_linux_amd64
-rwxr-xr-x  1 drnic  staff   3.4M Oct 25 23:05 cf-ssh_windows_386.exe
-rwxr-xr-x  1 drnic  staff   4.2M Oct 25 23:05 cf-ssh_windows_amd64.exe
github-release release -u cloudfoundry-community -r cf-ssh -t $VERSION --name "cf-ssh $VERSION" --description 'SSH into a running container for your Cloud Foundry application, run one-off tasks, debug your app, and more.'

for arch in darwin_amd64 linux_amd64 windows_amd64 windows_386; do
  github-release upload -u cloudfoundry-community -r cf-ssh -t $VERSION --name cf-ssh_$arch --file out/cf-ssh_$arch*

cf-uaa-guard-service cf-webui cf-zsh-autocompletion cfplayground
UAA proxy as a service Single page CloudFoundry web user interface using AngularJS and Bootstrap Oh My Zsh tab completion / autocompletion for cloud foundry Web portal for CF, lets users try out CF with free temp account and interactive tutorials
Voir le readme

UAA Auth Route Service Build Status

(Based on https://github.com/benlaplanche/cf-basic-auth-route-service)

Using the new route services functionality available in Cloud Foundry, you can now bind applications to routing services. Traffic sent to your application is routed through the bound routing service before continuing onto your service.

This allows you to perform actions on the HTTP traffic, such as enforcing authentication, rate limiting or logging.

For more details see:

Getting Started

There are two components and thus steps to getting this up and running. The broker and the filtering proxy.

Before getting started you will need:

  • Access to a cloud foundry deployment
  • UAA client credentials

Uncomment and fill in the environment variables required as the sample in broker-manifest.yml.sample and copy the manifest to broker-manifest.yml.

Run cf push -f broker-manifest.yml to deploy the uaa-guard-proxy app.

Uncomment and fill in the environment variables required as the sample in proxy-manifest.yml.sample and copy the manifest to proxy-manifest.yml.

Run cf push -f proxy-manifest.yml to deploy the uaa-guard-proxy app.

Once the broker is deployed, you can register it:

cf create-service-broker \
    uaa-auth-broker \
    https://uaa-guard-broker.my-paas.com \

Once you've created the service broker, you must enable-service-access in order to see it in the marketplace.

cf enable-service-access uaa-auth

You should now be able to see the service in the marketplace if you run cf marketplace

Protecting an application with UAA authentication

Now you have setup the supporting components, you can now protect your application with auth!

First create an instance of the service from the marketplace, here we are calling our instance authy

$cf create-service uaa-auth uaa-auth authy

Next, identify the application and its URL which you wish to protect. Here we have an application called hello with a URL of https://hello.my-paas.com

Then you need to bind the service instance you created called authy to the hello.my-paas.com route

⇒  cf bind-route-service my-paas.com authy --hostname hello

Binding may cause requests for route hello.my-paas.com to be altered by service instance authy. Do you want to proceed?> y
Binding route hello.my-paas.com to service instance authy in org org / space space as admin...

You can validate the route for hello is now bound to the authy service instance

⇒  cf routes
Getting routes for org org / space space as admin ...

space          host                domain            port   path   type   apps                service
space          hello               my-paas.com                            hello               authy

All of that looks good, so the last step is to validate we can no longer view the hello application without providing credentials!

⇒  curl -k https://hello.my-paas.com

and if you visit it you will be redirected to UAA.

Knowing who is logged in

This service will forward a header X-AUTH-USER with the email of the logged in user.

Voir le readme


CF WebUI is a modern single-page web-frontend for Cloud Foundry based on AngularJS and Bootstrap.

Cloud Foundry is the OpenSource Platform as a Service (PaaS) Framework on which many PaaS offerings are based (e.g. Pivotal Web Services, HP Helion, IBM BlueMix, Swisscom Application Cloud, etc.). It allows the developers to provide, manage and scale their application in the cloud very easily and quickly. For end-users Cloud Foundry provides a REST based API and a command line interface (CLI) client. No official free and open source web front-end is currently available.

Getting started

1. Clone the project: git clone https://github.com/icclab/cf-webui <br>
2. Change directory to cf-webUI: cd cf-webUI<br>
3. Change the manifest.yml to your options and the endpoint to your desired Cloud Foundry instance. E.g.: <br>

    - name: cf-webui  
      memory: 128M  
      host: console-cf-webui-${random-word}  
      path: ./build
      buildpack: staticfile_buildpack
        API_ENDPOINT: https://api.run.pivotal.io
        # Use Google DNS by default
        #Enforce https is used (using x_forwarded_proto check) .Default: enabled
        FORCE_HTTPS: 1

4. Install npm packages: npm install<br>
5. Build the application using Grunt: grunt build<br>
6. Push this application to Cloud Foundry using the cf Command Line Interface (CLI): cf push.<br>
7. Enjoy the CF WebUI!<br>


The current version is an early release (alpha). It is not yet production-ready. Some features are still to come and it may contain major bugs.

Community & Support

Please report bugs and request features using GitHub Issues. For additional information, you can contact the maintainer directly.

Community discussions about CF-WebUI happen in the CF-WebUI-discuss mailing list. Once you subscribe to the list, you can send mail to the list address: icclab-cf-webui@dornbirn.zhaw.ch. The mailing list archives are also available on the web.

Please follow the ICCLab blog for updates.


CF-WebUI is licensed under the Apache License version 2.0. See the LICENSE file.

Voir le readme


Oh My Zsh (or probably any zsh but YMMV) plugin for cf (Cloud Foundry) autocompletion.

See the know issues below for what doesn't work.


Now that the CLI supports plugins, I'm considering abandoning this project in favor of a true CLI plugin.


Drop the cf directory into your $ZSH/custom/plugins/ (usually ~/.oh-my-zsh/custom/plugins) directory. Then add cf to the plugins line of your .zshrc file. For example here's my .zshrc plugin lines

# Which plugins would you like to load? (plugins can be found in ~/.oh-my-zsh/plugins/*)
# Custom plugins may be added to ~/.oh-my-zsh/custom/plugins/
# Example format: plugins=(rails git textmate ruby lighthouse)
# Add wisely, as too many plugins slow down shell startup.
plugins=(git docker jsontools tmux vagrant bosh cf)

Runtime Options

Personally I think the short hand options to many CF commands clutter up the tab view, so I don't include them in the default output. If you want them included in the output export CF_ZSH_INCLUDE_SHORT=true. The plugin will look for this variable every time so if you want to play with it you an set it on the command line. Otherwise, stick it in your .zshrc had have at it.


Type cf <tab> and watch the magic happen

➜  ~  cf <tab>                                                                      
zsh: do you wish to see all 120 possibilities (60 lines)? y                                                
api                                     passwd
app                                     plugins
apps                                    purge-service-offering
auth                                    push
bind-running-security-group             quota
... and on and on

➜  ~  cf create-<tab>                                                                                                  
create-buildpack              create-security-group         create-space
create-domain                 create-service                create-space-quota
create-org                    create-service-auth-token     create-user
create-quota                  create-service-broker         create-user-provided-service
create-route                  create-shared-domain

Known Issues

It doesn't provide extended help for commands, which would be nice. For instance when you type cf push <tab> you don't get the usage.

It doesn't know about parameters for every command yet. It will prompt with spaces, orgs and apps for some commands.

El Problemo?

Open an issue or submit a PR please!


Is avaliable here

Voir le readme

CF Playground

The goal of this project is to provide an easily accessible environment for users who want to experience Cloud Foundry, without having to setup and to learn the operation of the platform. CF Playground provides an interactive tutorial.

CF Playground in Action

Setting up CF Playground

The following instruction is for OSX/Linux, windows support is coming soon. You will need to host your own Cloud Foundry environment (bosh-lite or any full deployment)

1) Ensure that Go version 1.2+ is installed on the system

2) Setup the GOPATH

export GOPATH=~/go
export PATH=$GOPATH/bin:$PATH

3) Download CF PLayground

go get github.com/cloudfoundry-community/cfplayground
cd $GOPATH/src/github.com/cloudfoundry-community/cfplayground

*(Ignore any warnings about "no buildable Go source files")

4) Create a config file config.json under config/ with the info of your Cloud Foundry environment, a sample config file is provided for reference config/sameple_config.json

* if no config.json is found, boshlite_config.json will be used to target a local boshlite environment.

5) Run CF Playground

go run main.go
  • If you are running CF Playground under Linux, download Linux CF CLI Binary, rename and replace the pcf file under assets/cf/ with the downloaded binary.


  • No Windows support (coming soon)
  • Arbitrary app pushing (functioning, improvement to be made)
  • Temp user account/space clean up (work in progress)
  • Restore user session (functioning, improvement to be made)
  • The supported CF commands are:
    • cf push
    • cf apps
    • cf app {app name}
    • cf delete {app name}

cg-deck cli-plugin-repo cloudfoundry-cli concourse
A web console for managing Cloud Foundry Apps Public repository for community created CF CLI plugins. A CLI for Cloud Foundry written in Go BOSH Release
Voir le readme

18F Cloud Foundry Deck

Build Status

Tech Stack

  • Go (v1.5 required) for the backend server. Go Code Coverage Status

  • AngularJS for the frontend. JS Code Coverage Status


Create a Client with UAAC

  • Make sure UAAC is installed.
  • Target your UAA server. uaac target <uaa.your-domain.com>
  • Login with your current UAA account. uaac token client get <your admin account> -s <your uaa admin password>
  • Create client account:
    uaac client add <your-client-id> \
    --authorities cloud_controller.admin,cloud_controller.read,cloud_controller.write,openid,scim.read \
    --authorized_grant_types authorization_code,client_credentials,refresh_token \
    --scope cloud_controller.admin,cloud_controller.read,cloud_controller.write,openid,scim.read \
    -s <your-client-secret>
  • Unable to create an account still? Troubleshoot here

Set the environment variables

If you are testing locally, export these variables. If you are deploying to cloud foundry, modify the manifest.yml

  • CONSOLE_CLIENT_ID: Registered client id with UAA.
  • CONSOLE_CLIENT_SECRET: The client secret.
  • CONSOLE_HOSTNAME: The URL of the service itself.
  • CONSOLE_LOGIN_URL: The base URL of the auth service. i.e. https://login.domain.com
  • CONSOLE_UAA_URL: The URL of the UAA service. i.e. https://uaa.domain.com
  • CONSOLE_API_URL: The URL of the API service. i.e. http://api.domain.com
  • CONSOLE_LOG_URL: The URL of the loggregator service. i.e. http://loggregator.domain.com
  • PPROF_ENABLED: An optional variable. If set to true or 1, will turn on /debug/pprof endpoints as seen here

Front end

Install front end dependencies

npm install

Running locally

  • Make sure all of your environment variables are set as mentioned above.
  • Install godep
  • Run godep restore to get all third party code
  • go run server.go
  • Navigate browser to http://localhost:9999

Unit Testing

Running Go unit tests

  • go test ./...

Running Angular unit tests

Test can then be run with the command:

npm run tests

To get a viewable coverage report change the coverageReport object in karma.conf.js from json to html

coverageReporter: {
    type: 'html',
    dir: 'coverage',
    subdir: '.'

Acceptance Tests

This project currently uses a combination of Agouti + Ginkgo + Gomega to provide BDD acceptance testing. All the acceptance tests are in the 'acceptance' folder.


  • Make sure you have PhantomJS installed: brew install phantomjs
  • Install aogut: go get github.com/sclevine/agouti
  • Install ginkgo go get github.com/onsi/ginkgo/ginkgo
  • Install gomega go get github.com/onsi/gomega
  • To run locally, in addition to the variables in the "Set the environmnent variables" section, you will need to set two more variables in your environment
  • CONSOLE_TEST_USERNAME: The username of the account you want the tests to use to login into your CONSOLE_LOGIN_URL
  • CONSOLE_TEST_PASSWORD: The password of the account you want the tests to use to login into your CONSOLE_LOGIN_URL
  • CONSOLE_TEST_ORG_NAME: The test organization the user should be navigating to.
  • CONSOLE_TEST_SPACE_NAME: The test space the user should be navigating to.
  • CONSOLE_TEST_APP_NAME: The test app the user should be navigating to.
  • CONSOLE_TEST_HOST: The host that the app can create a mock route for.
  • CONSOLE_TEST_DOMAIN: The domain for the mock route.

Running acceptance tests

  • cd acceptance && go test -tags acceptance


  • cf push <optional-app-name>


This project uses Travis-CI

  • The following environment variables need to be set in plain text in the global env section:
  • In case you fork this project for your own use (no need to do this if forking to make a pull request), you will need to use the Travis-CI CLI tool to re-encrypt all the environment variables.
    • travis encrypt CONSOLE_CLIENT_ID='<your client id>' --add env.global
    • travis encrypt CONSOLE_CLIENT_SECRET='<your client secret>' --add env.global
    • travis encrypt CONSOLE_TEST_PASSWORD='<the test user account password>' --add env.global
    • travis encrypt CONSOLE_TEST_USERNAME='<the test user account username>' --add env.global
    • travis encrypt CF_USERNAME='<the user account username used to deploy>' --add env.global
    • travis encrypt CF_PASSWORD='<the user account password used to deploy>' --add env.global

What’s a Deck?

From Wikipedia:

The Sprawl trilogy (also known as the Neuromancer, Cyberspace, or Matrix trilogy) is William Gibson's first set of novels, composed of Neuromancer (1984), Count Zero (1986), and Mona Lisa Overdrive (1988).

Cyberspace Deck

Also called a "deck" for short, it is used to access the virtual representation of the matrix. The deck is connected to a tiara-like device that operates by using electrodes to stimulate the user's brain while drowning out other external stimulation. As Case describes them, decks are basically simplified simstim units.

Voir le readme

Cloud Foundry CLI Plugin Repository (CLIPR)Build Status

This is a public repository for community created CF CLI plugins. To submit your plugin approval, please submit a pull request according to the guidelines below.

*If you are looking for information about the Plugin Repo Server, please go here

Submitting Plugins

  1. You need to have git installed
  2. Clone this repo git clone https://github.com/cloudfoundry-incubator/cli-plugin-repo
  3. Include your plugin information in repo-index.yml, here is an example of a new plugin entry

    - name: new_plugin
    description: new_plugin to be made available for the CF community
    version: 1.0.0
    created: 2015-1-31
    updated: 2015-1-31
    - name: Sample-Author
      homepage: http://github.com/sample-author
      contact: contact@sample-author.io
    homepage: http://github.com/sample-author/new_plugin
    - platform: osx 
      url: https://github.com/sample-author/new_plugin/releases/download/v1.0.0/echo_darwin
      checksum: 2a087d5cddcfb057fbda91e611c33f46
    - platform: win64 
      url: https://github.com/sample-author/new_plugin/releases/download/v1.0.0/echo_win64.exe
      checksum: b4550d6594a3358563b9dcb81e40fd66
    - platform: linux32
      url: https://github.com/sample-author/new_plugin/releases/download/v1.0.0/echo_linux32
      checksum: f6540d6594a9684563b9lfa81e23id93

    Please make sure the spacing and colons are correct in the entry. The following descibes each field's usage.

    Field Description
    name Name of your plugin, must not conflict with other existing plugins in the repo.
    description Describe your plugin in a line or two. This desscription will show up when your plugin is listed on the command line
    version Version number of your plugin, in [major].[minor].[build] form
    created Date of first submission of the plugin, in year-month-day form
    updated Date of last update of the plugin, in year-month-day form
    company Optional field detailing company or organization that created the plugin
    authors Fields to detail the authors of the plugin
    name: name of author
    homepage: Optional link to the homepage of the author
    contact: Optional ways to contact author, email, twitter, phone etc ...
    homepage Link to the homepage where the source code is hosted. Currently we only support open source plugins
    binaries This section has fields detailing the various binary versions of your plugin. To reach as large an audience as possible, we encourage contributors to cross-compile their plugins on as many platforms as possible. Go provides everything you need to cross-compile for different platforms
    platform: The os for this binary. Supports osx, linux32, linux64, win32, win64
    url: Link to the binary file itself
    checksum: SHA-1 of the binary file for verification
  4. After making the changes, fork the repository
  5. Add your fork as a remote

    cd $GOPATH/src/github.com/cloudfoundry-incubator/cli-plugin-repo
    git remote add your_name https://github.com/your_name/cli-plugin-repo
  6. Push the changes to your fork and submit a Pull Request

Running your own Plugin Repo Server

Included as part of this repository is the CLI Plugin Repo (CLIPR), a reference implementation of a repo server. For information on how to run CLIPR or how to write your own, please see the CLIPR documentation here.

Voir le readme

Cloud Foundry CLI Build Status

This is the official command line client for Cloud Foundry.

You can follow our development progress on Pivotal Tracker.

Getting Started

Download and run the installer for your platform from the Downloads Section.

Once installed, you can log in and push an app.

$ cd [my-app-directory]
$ cf api api.[my-cloudfoundry].com
Setting api endpoint to https://api.[my-cloudfoundry].com...

$ cf login
API endpoint: https://api.[my-cloudfoundry].com

Email> [my-email]

Password> [my-password]

$ cf push

Further Reading and Getting Help

  • You can find further documentation at the docs page for the CLI here.
  • There is also help available in the CLI itself; type cf help for more information.
  • Each command also has help output available via cf [command] --help or cf [command] -h.
  • For development guide on writing a cli plugin, see here.
  • Finally, if you are still stuck or have any questions or issues, feel free to open a GitHub issue.


Latest stable: Download the installer or compressed binary for your platform:

Mac OS X 64 bit Windows 64 bit Linux 64 bit
Installers pkg zip rpm / deb
Binaries tgz zip tgz

From the command line: Download examples with curl for Mac OS X and Linux

# ...download & extract Mac OS X binary
$ curl -L "https://cli.run.pivotal.io/stable?release=macosx64-binary&source=github" | tar -zx
# ...or Linux binary
$ curl -L "https://cli.run.pivotal.io/stable?release=linux64-binary&source=github" | tar -zx
# ...and confirm you got the version you expected
$ ./cf --version
cf version x.y.z-...

Experimental: Install CF for OSX through Homebrew via the pivotal's homebrew-tap:

$ brew tap pivotal/tap
$ brew install cloudfoundry-cli

Also, edge binaries are published for Mac OS X 64 bit, Windows 64 bit and Linux 64 bit with each new 'push' that passes though CI. These binaries are not intended for wider use; they're for developers to test new features and fixes as they are completed.

Releases: 32 bit releases and information about all our releases can be found here

Troubleshooting / FAQs

Known Issues

  • .cfignore used in cf push must be in UTF8 encoding for CLI to interpret correctly.


Filing Bugs

For simple bugs (eg: text formatting, help messages, etc), please provide
  • the command you ran
  • what occurred
  • what you expected to occur
For bugs related to HTTP requests or strange behavior, please run the command with env var CF_TRACE=true and provide
  • 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

Forking the repository for development

  1. Install Go
  2. Ensure your $GOPATH is set correctly
  3. Install godep
  4. Get the cli source code: go get github.com/cloudfoundry/cli
    • (Ignore any warnings about "no buildable Go source files")
  5. Run godep restore (note: this will modify the dependencies in your $GOPATH)
  6. Fork the repository
  7. Add your fork as a remote: cd $GOPATH/src/github.com/cloudfoundry/cli && git remote add your_name https://github.com/your_name/cli


To prepare your build environment, run go get -u github.com/jteeuwen/go-bindata/...

  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.

If you want to run the tests with ginkgo, or build with go build you should first run bin/generate-language-resources. bin/build and bin/test generate language files automatically.


  1. Install Mercurial
  2. Run go get golang.org/x/tools/cmd/vet
  3. Write a Ginkgo test.
  4. Run bin/test and watch the test fail.
  5. Make the test pass.
  6. Submit a pull request to the master branch.

*__ For development guide on writing a cli plugin, see here**


Major new feature proposals are given as a publically viewable google document with commenting allowed and discussed on the cf-dev mailing list.

Pull Requests

Pull Requests should be made against the master branch.

Architecture overview

A command is a struct that implements this interface:

type Command interface {
    MetaData() CommandMetadata
    SetDependency(deps Dependency, pluginCall bool) Command
    Requirements(requirementsFactory requirements.Factory, context flags.FlagContext) (reqs []requirements.Requirement, err error)
    Execute(context flags.FlagContext)

Source code

Metadata() is just a description of the command name, usage and flags:

type CommandMetadata struct {
    Name            string
    ShortName       string
    Usage           string
    Description     string
    Flags           map[string]flags.FlagSet
    SkipFlagParsing bool
    TotalArgs       int

Source code

Requirements() returns a list of requirements that need to be met before a command can be invoked.

Execute() is the method that your command implements to do whatever it's supposed to do. The context object provides flags and arguments.

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

SetDependency() is where a command obtains its dependencies. Dependencies are typically declared as an interface type, and not a concrete type, so tests can inject a fake. The bool argument pluginCall indicates whether the command is invoked by one of the CLI's plugin API methods.

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 cf/command_registry/dependency.go)

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

Repositories communicate with the api endpoints through a Gateway (see cf/net).

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

Managing dependencies

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

For commands that use another command as dependency, command_registry is used for retrieving the command dependency. For example, the command restart has a dependency on command start and stop, and this is how the command dependency is retrieved: restart.go

As for repositories, we use the repository locator to handle their dependencies. You can find it in 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 cf/commands/space/create_space.go.


All pull requests which include user-facing strings should include updated translation files. These files are generated/ maintained using i18n4go.

To add/ update translation strings run the command i18n4go -c fixup. For each change or update, you will be presented with the choices new or upd. Type in the appropriate choice. If upd is chosen, you will be asked to confirm which string is being updated using a numbered list.

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 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 error. Models are used in both Commands and Repositories to model Cloud Foundry data. This convention provides a consistent method signature across repositories.

Voir le readme

concourse slack.concourse.ci

Concourse is a pipeline-based CI system written in Go.


Concourse is built on a few components, all written in Go with cutesy aerospace-themed names. This repository is actually its BOSH release, which ties everything together and also serves as the central hub for GitHub issues.

Each component has its own repository:

  • ATC is most of Concourse: it provides the API, web UI, and all pipeline orchestration
  • Fly is the CLI for interacting with and configuring Concourse pipelines
  • TSA is a SSH server used for authorizing worker registration
  • Garden is a generic interface for orchestrating containers remotely on a worker
  • Baggageclaim is a server for managing caches and artifacts on the workers

To learn more about how they fit together, see Concourse Architecture.

ECOMSport ep_ldapauth ethercalc etherpad-lite-cf-orange
LDAP authentication plugin for Etherpad-lite Node.js port of Multi-user SocialCalc Really real-time collaborative document editing for the rest of us working with cloudfoundry
Voir le readme

Not Found

Voir le readme

Etherpad lite LDAP authentication and authorization


In your etherpad-lite dir:

npm install ep_ldapauth

Add to settings.json:

"users": {
    "ldapauth": {
        "url": "ldaps://ldap.example.com",
        "accountBase": "ou=Users,dc=example,dc=com",
        "accountPattern": "(&(objectClass=*)(uid={{username}}))",
        "displayNameAttribute": "cn",
        "searchDN": "uid=searchuser,dc=example,dc=com",
        "searchPWD": "supersecretpassword",
        "groupSearchBase": "ou=Groups,dc=example,dc=com",
        "groupAttribute": "member",
        "groupAttributeIsDN": true,
        "searchScope": "sub",
        "groupSearch": "(&(cn=admin)(objectClass=groupOfNames))"
        "anonymousReadonly": false



Voir le readme

Not Found

Voir le readme

A really-real time collaborative word processor for the web

alt text


Etherpad is a really-real time collaborative editor maintained by the Etherpad Community.

Etherpad is written in Javascript(99.9%) on both the server and client so it's easy for developers to maintain and add new features. Because of this Etherpad has tons of customizations that you can leverage.

Etherpad is designed to be easily embeddable and provides a HTTP API that allows your web application to manage pads, users and groups. It is recommended to use the available client implementations in order to interact with this API.

There is also a jQuery plugin that helps you to embed Pads into your website.

There's also a full-featured plugin framework, allowing you to easily add your own features. By default your Etherpad is rather sparce and because Etherpad takes a lot of it's inspiration from Wordpress plugins are really easy to install and update. Once you have Etherpad installed you should visit the plugin page and take control.

Finally, Etherpad comes with translations into most languages! Users are automatically delivered the correct language for their local settings.

Visit beta.etherpad.org to test it live.

Also, check out the FAQ, really!


Etherpad works with node v0.8, v0.10 and v0.11, only. (We don't support v0.6)


Prebuilt windows package

This package works out of the box on any windows machine, but it's not very useful for developing purposes...

  1. Download the latest windows package
  2. Extract the folder

Now, run start.bat and open http://localhost:9001 in your browser. You like it? Next steps.

Fancy install

You'll need node.js and (optionally, though recommended) git.

  1. Grab the source, either
  2. start bin\installOnWindows.bat

Now, run start.bat and open http://localhost:9001 in your browser.

Update to the latest version with git pull origin, then run bin\installOnWindows.bat, again.

Next steps.

GNU/Linux and other UNIX-like systems

You'll need gzip, git, curl, libssl develop libraries, python and gcc.
For Debian/Ubuntu: apt-get install gzip git-core curl python libssl-dev pkg-config build-essential
For Fedora/CentOS: yum install gzip git-core curl python openssl-devel && yum groupinstall "Development Tools" For FreeBSD: portinstall node, npm, git (optional)

Additionally, you'll need node.js installed, Ideally the latest stable version, be careful of installing nodejs from apt.

As any user (we recommend creating a separate user called etherpad):

  1. Move to a folder where you want to install Etherpad. Clone the git repository git clone git://github.com/ether/etherpad-lite.git
  2. Change into the new directory containing the cloned source code cd etherpad-lite

Now, run bin/run.sh and open in your browser.

Update to the latest version with git pull origin. The next start with bin/run.sh will update the dependencies.

You like it? Next steps.

Next Steps

Tweak the settings

You can initially modify the settings in settings.json. (If you need to handle multiple settings files, you can pass the path to a settings file to bin/run.sh using the -s|--settings option. This allows you to run multiple Etherpad instances from the same installation.) Once you have access to your /admin section settings can be modified through the web browser.

You should use a dedicated database such as "mysql", if you are planning on using etherpad-in a production environment, since the "dirtyDB" database driver is only for testing and/or development purposes.

Helpful resources

The wiki is your one-stop resource for Tutorials and How-to's, really check it out! Also, feel free to improve these wiki pages.

Documentation can be found in docs/.


Things you should know

Read this git guide and watch this video on getting started with Etherpad Development.

If you're new to node.js, start with Ryan Dahl's Introduction to Node.js.

You can debug Etherpad using bin/debugRun.sh.

If you want to find out how Etherpad's Easysync works (the library that makes it really realtime), start with this PDF (complex, but worth reading).

Getting started

You know all this and just want to know how you can help?

Look at the TODO list and our Issue tracker. (Please consider using jshint, if you plan to contribute code.)

Also, and most importantly, read our Developer Guidelines, really!

Get in touch

Join the mailinglist and make some noise on our busy freenode irc channel #etherpad-lite-dev!

Modules created for this project

  • ueberDB "transforms every database into a object key value store" - manages all database access
  • channels "Event channels in node.js" - ensures that ueberDB operations are atomic and in series for each key
  • async-stacktrace "Improves node.js stacktraces and makes it easier to handle errors"



Apache License v2

local development cli
Voir le readme


A command line interface that runs a build in a container with ATC.

A good place to start learning about Concourse is its BOSH release.


Fly is built using Go. Building and testing fly is most easily done from a checkout of concourse.

  1. Check out concourse and update submodules:

    git clone git@github.com:concourse/concourse.git
    cd concourse
    git submodule update --init --recursive
  2. Install direnv. Once installed you can cd in and out of the concourse directory to setup your environment.

  3. You can now build the the fly binary with go build:

    cd src/github.com/concourse/fly
    go build
  4. You can also now run tests by installing and running ginkgo:

    go get github.com/onsi/ginkgo/ginkgo
    ginkgo -r

Installing from the Concourse UI for Project Development

Fly is available for download in the lower right-hand corner of the concourse UI.

  1. Click the button corresponding to your OS

  2. Move the downloaded file onto your PATH

    mv ~/Downloads/fly /usr/bin
  3. Make the fly file executable

    chmod +x /usr/bin/fly
  4. Confirm availability with which fly

Membre d'organisations