Repository files navigation

Cloud Foundry CLI Build Status

This is the official command line client for Cloud Foundry.

Stable Release

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.

Troubleshooting / FAQs

Linux

Mac OS X

  • "Illegal instruction: 4" - This is a known defect with some versions of OS X. Please file an issue. As a workaround, you can build from source or use homebrew.

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

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. Install Mercurial
  2. Run go get code.google.com/p/go.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.

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).

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

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

About

A CLI for Cloud Foundry written in Go

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content

Repository files navigation

Cloud Foundry CLI Build Status

This is the official command line client for Cloud Foundry.

Stable Release

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.

Troubleshooting / FAQs

Linux

Mac OS X

  • "Illegal instruction: 4" - This is a known defect with some versions of OS X. Please file an issue. As a workaround, you can build from source or use homebrew.

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

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. Install Mercurial
  2. Run go get code.google.com/p/go.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.

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).

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

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

About

A CLI for Cloud Foundry written in Go

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

Cloud Foundry CLI Build Status

This is the official command line client for Cloud Foundry.

Stable Release

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.

Troubleshooting / FAQs

Linux

Mac OS X

  • "Illegal instruction: 4" - This is a known defect with some versions of OS X. Please file an issue. As a workaround, you can build from source or use homebrew.

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

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. Install Mercurial
  2. Run go get code.google.com/p/go.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.

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).

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

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

About

A CLI for Cloud Foundry written in Go

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

Cloud Foundry CLI Build Status

This is the official command line client for Cloud Foundry.

Stable Release

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.

Troubleshooting / FAQs

Linux

Mac OS X

  • "Illegal instruction: 4" - This is a known defect with some versions of OS X. Please file an issue. As a workaround, you can build from source or use homebrew.

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

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. Install Mercurial
  2. Run go get code.google.com/p/go.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.

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).

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

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

About

A CLI for Cloud Foundry written in Go

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

Repository files navigation

Cloud Foundry CLI Build Status

This is the official command line client for Cloud Foundry.

Stable Release

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.

Troubleshooting / FAQs

Linux

Mac OS X

  • "Illegal instruction: 4" - This is a known defect with some versions of OS X. Please file an issue. As a workaround, you can build from source or use homebrew.

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

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. Install Mercurial
  2. Run go get code.google.com/p/go.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.

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).

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

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

About

A CLI for Cloud Foundry written in Go

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

Cloud Foundry CLI Build Status

This is the official command line client for Cloud Foundry.

Stable Release

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.

Troubleshooting / FAQs

Linux

Mac OS X

  • "Illegal instruction: 4" - This is a known defect with some versions of OS X. Please file an issue. As a workaround, you can build from source or use homebrew.

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

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. Install Mercurial
  2. Run go get code.google.com/p/go.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.

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).

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

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

About

A CLI for Cloud Foundry written in Go

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

Cloud Foundry CLI Build Status

This is the official command line client for Cloud Foundry.

Stable Release

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.

Troubleshooting / FAQs

Linux

Mac OS X

  • "Illegal instruction: 4" - This is a known defect with some versions of OS X. Please file an issue. As a workaround, you can build from source or use homebrew.

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

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. Install Mercurial
  2. Run go get code.google.com/p/go.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.

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).

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

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

About

A CLI for Cloud Foundry written in Go

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

Repository files navigation

Cloud Foundry CLI Build Status

This is the official command line client for Cloud Foundry.

Stable Release

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.

Troubleshooting / FAQs

Linux

Mac OS X

  • "Illegal instruction: 4" - This is a known defect with some versions of OS X. Please file an issue. As a workaround, you can build from source or use homebrew.

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

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. Install Mercurial
  2. Run go get code.google.com/p/go.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.

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).

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

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

About

A CLI for Cloud Foundry written in Go

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages