Giter Club home page Giter Club logo

workflow-cli's Introduction

Deis Workflow is no longer maintained.
Please read the announcement for more detail.
09/07/2017 Deis Workflow v2.18 final release before entering maintenance mode
03/01/2018 End of Workflow maintenance: critical patches no longer merged
Hephy is a fork of Workflow that is actively developed and accepts code contributions.

Deis Client

Build Status Go Report Card codebeat badge codecov

Download Links:

deis is a command line utility used to interact with the Deis open source PaaS.

Please add any issues you find with this software to the Deis Workflow CLI Project.

Installation

Pre-built Binary

See the appropriate sub-section below for your system to download and install the latest build of this software.

64 Bit Linux

Master:

curl -o deis https://storage.googleapis.com/workflow-cli-master/deis-latest-linux-amd64 && chmod +x deis

Latest stable release:

curl -o deis https://storage.googleapis.com/workflow-cli-release/deis-stable-linux-amd64 && chmod +x deis

32 Bit Linux

Master:

curl -o deis https://storage.googleapis.com/workflow-cli-master/deis-latest-linux-386 && chmod +x deis

Latest stable release:

curl -o deis https://storage.googleapis.com/workflow-cli-release/deis-stable-linux-386 && chmod +x deis

64 Bit Mac OS X

Master:

curl -o deis https://storage.googleapis.com/workflow-cli-master/deis-latest-darwin-amd64 && chmod +x deis

Latest stable release:

curl -o deis https://storage.googleapis.com/workflow-cli-release/deis-stable-darwin-amd64 && chmod +x deis

32 Bit Max OS X

Master:

curl -o deis https://storage.googleapis.com/workflow-cli-master/deis-latest-darwin-386 && chmod +x deis

Latest stable release:

curl -o deis https://storage.googleapis.com/workflow-cli-release/deis-stable-darwin-386 && chmod +x deis

64 Bit Windows

Master:

powershell -NoProfile -ExecutionPolicy Bypass -Command "(new-object net.webclient).DownloadFile('https://storage.googleapis.com/workflow-cli-master/deis-latest-windows-amd64.exe', 'deis.exe')"

Latest stable release:

powershell -NoProfile -ExecutionPolicy Bypass -Command "(new-object net.webclient).DownloadFile('https://storage.googleapis.com/workflow-cli-release/deis-stable-windows-amd64.exe', 'deis.exe')"

32 Bit Windows

Master:

powershell -NoProfile -ExecutionPolicy Bypass -Command "(new-object net.webclient).DownloadFile('https://storage.googleapis.com/workflow-cli-master/deis-latest-windows-386.exe', 'deis.exe')"

Latest stable release:

powershell -NoProfile -ExecutionPolicy Bypass -Command "(new-object net.webclient).DownloadFile('https://storage.googleapis.com/workflow-cli-release/deis-stable-windows-386.exe', 'deis.exe')"

After you execute the appropriate command for your system, you'll have a deis binary in the current directory.

Run the following to see the version:

$ ./deis --version

You can then move it anywhere in your path:

$ mv deis /usr/local/bin

From Scratch on OS X and Linux

To compile the client from scratch, ensure you have Docker installed and run

$ make

From Scratch on Windows

To compile the client from scratch, open PowerShell and execute the following commands in the source directory.

$ .\make bootstrap
$ .\make build

.\make bootstrap will fetch all required dependencies, while .\make build will compile and install the client in the current directory.

$ .\deis --version

Usage

Running deis help will give you a up to date list of deis commands. To learn more about a command run deis help <command>.

License

see LICENSE

workflow-cli's People

Contributors

adamkdean avatar aledbf avatar arschles avatar babarinde avatar bengrunfeld avatar carmstrong avatar croemmich avatar glogiotatidis avatar helgi avatar iancoffey avatar jgmize avatar johanneswuerbach avatar joshua-anderson avatar kalbasit avatar kmala avatar krancour avatar mboersma avatar nathansamson avatar ngpestelos avatar progrium avatar romansergey avatar slack avatar smothiki avatar technosophos avatar tombh avatar ultimateboy avatar vdice avatar wenzowski avatar xe avatar zinuzoid avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

workflow-cli's Issues

Panic on `deis ps`

I don't believe there were any running processes when I executed this command:

ENG000656:k8s-claimer aaronschlesinger$ deis ps -a k8s-claimer
panic: interface conversion: interface is nil, not []interface {}

goroutine 1 [running]:
github.com/deis/workflow/client/controller/client.Client.LimitedRequest(0xc820013cb0, 0x0, 0xc82012e760, 0x4, 0x0, 0x0, 0x0, 0xc82012e767, 0x14, 0x0, ...)
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/controller/client/http.go:82 +0x386
github.com/deis/workflow/client/controller/models/ps.List(0xc8200f02c0, 0x7fff5fbff9bb, 0xb, 0x64, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0)
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/controller/models/ps/ps.go:15 +0x1a7
github.com/deis/workflow/client/cmd.PsList(0x7fff5fbff9bb, 0xb, 0x64, 0x0, 0x0)
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/cmd/ps.go:26 +0xd0
github.com/deis/workflow/client/parser.psList(0xc82000a290, 0x3, 0x3, 0x0, 0x0)
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/parser/ps.go:67 +0x2d0
github.com/deis/workflow/client/parser.Ps(0xc82000a290, 0x3, 0x3, 0x0, 0x0)
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/parser/ps.go:34 +0x29f
main.Command(0xc82000a290, 0x3, 0x3, 0x188850)
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/deis.go:85 +0x694
main.main()
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/deis.go:18 +0x60

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1

apps:transfer scenario exit code discrepancy

e2e has caught an intermittent error where the app is transferred from a testUser to an admin and when a subsequent deis info command is invoked (by testUser) we expect said command to exit with 1, yet 0 is produced:

05:59:51 remote: Done, test-27862817:v2 deployed to Deis        
05:59:51 remote: --->         
05:59:51 remote: Use 'deis open' to view this application in your browser        
05:59:51 remote: --->         
05:59:51 remote: To learn more, use 'deis help' or visit http://deis.io        
05:59:51 remote: [DEBUG]         
05:59:51 remote: running [git gc] in directory /home/git/test-27862817.git        
05:59:51 To ssh://[email protected]:2222/test-27862817.git
05:59:51  * [new branch]      master -> master
05:59:51 $ deis apps:transfer admin
05:59:51 $ deis info -a test-27862817
05:59:51 Transferring test-27862817 to admin... === test-27862817 Application
05:59:51 updated:  2016-03-24T11:59:48UTC
05:59:51 uuid:     a0702efb-ceac-4570-923d-7b71ac7239bd
05:59:51 created:  2016-03-24T11:59:36UTC
05:59:51 url:      test-27862817.10.231.253.119.xip.io
05:59:51 owner:    test-81
05:59:51 id:       test-27862817
05:59:51 
05:59:51 === test-27862817 Processes
05:59:51 --- web:
05:59:51 test-27862817-v2-web-5bjsd up (v2)
05:59:51 
05:59:51 === test-27862817 Domains
05:59:51 test-27862817
05:59:51 
05:59:51 $ deis apps:destroy --app=test-27862817 --confirm=test-27862817
05:59:51 Destroying test-27862817...
05:59:51 Error: 
05:59:51 403 Forbidden
05:59:51 detail: You do not have permission to perform this action.
05:59:51 
05:59:51 done
05:59:51 
05:59:51 • Failure [16.979 seconds]
05:59:51 Apps
05:59:51 /go/src/github.com/deis/workflow-e2e/tests/apps_test.go:204
05:59:51   with a deployed app
05:59:51   /go/src/github.com/deis/workflow-e2e/tests/apps_test.go:174
05:59:51     can transfer the app to another owner [It]
05:59:51     /go/src/github.com/deis/workflow-e2e/tests/apps_test.go:173
05:59:51 
05:59:51     No future change is possible.  Bailing out early after 0.133s.
05:59:51     Expected
05:59:51         <int>: 0
05:59:51     to match exit code:
05:59:51         <int>: 1
05:59:51 
05:59:51     /go/src/github.com/deis/workflow-e2e/tests/apps_test.go:165
05:59:51 ------------------------------

Related logs can be found here

Specifying an invalid limit creates a noop release

$ deis limits:set web=512Mi
web=512Mi doesn't fit format type=#unit or type=#
Examples: web=2G worker=500M web=300
Applying limits... done

=== indoor-whitecap Limits

--- Memory
web     128M

--- CPU
web     40m

Should probably exit non-zero instead.

Change user-agent string for release

Currently controller logs show it still reports v2.0.0-dev:

INFO Not scaling RC webbed-traverse-v2-cmd in Namespace webbed-traverse to 0 replicas. Already at desired replicas
10.200.1.8 "POST /v2/apps/webbed-traverse/config/ HTTP/1.1" 201 242 "Deis Client v2.0.0-dev"
10.200.1.8 "GET /v2/apps/webbed-traverse/config/ HTTP/1.1" 200 230 "Deis Client v2.0.0-dev"
10.200.1.8 "GET /v2/apps/webbed-traverse/ HTTP/1.1" 200 173 "Deis Client v2.0.0-dev"

Deis does not support alphanumeric process type in Procfile

Docs says that process types declared in Procfile are alphanumeric and can be named arbitrarily: http://docs.deis.io/en/latest/using_deis/process-types/#declaring-process-types

But this is not the case, as when using an actual alphanumeric string as process type, I get the following message:

'worker2=1' does not match the pattern 'type=num', ex: web=2

github repo to test this out: https://github.com/n0n0x/deis-cli-bug

git clone https://github.com/n0n0x/deis-cli-bug.git
cd deis-cli-bug
deis create cli-bug
git push deis master
deis ps:scale worker1=1
deis ps:scale worker2=1
deis ps:scale worker=1

The only one that gets scaled is worker.

Example output:

n0n0x@n0n0x:~/repos/cli-bug (master)$ deis ps:scale worker1=1
'worker1=1' does not match the pattern 'type=num', ex: web=2
Scaling processes... but first, coffee!
done in 0s
=== cli-bug Processes

n0n0x@n0n0x:~/repos/cli-bug (master)$ deis ps:scale worker2=1
'worker2=1' does not match the pattern 'type=num', ex: web=2
Scaling processes... but first, coffee!
done in 0s
=== cli-bug Processes

n0n0x@n0n0x:~/repos/cli-bug (master)$ deis ps:scale worker=1
Scaling processes... but first, coffee!
done in 37s
=== cli-bug Processes
--- worker:
cli-bug-v2-worker-eu6wa up (v2)

Pipeline Workaround: Command Output

Right now, in order to get output from an command, you have to pipe it into a file and then read that file (example).

This is the approach recommended by the pipeline plugin for now, but it's pretty hacky. We should keep our eyes out for a better solution to this.

Extract common Jenkinsfile logic into Pipeline Global Library

This repo's Jenkinsfile as well as the controller-sdk-go repo's Jenkinsfile share common logic, especially as of deis/controller-sdk-go#46 which builds workflow-cli in place, duplicating many steps used in this repo's pipeline.

It would be preferable if we extracted shared logic into common functionality via the Pipeline Global Library to both reduce duplication and enable only making changes to such functionality in one location. Some functionality will even prove to be generally useful outside of workflow-cli/controller-sdk-go's scope, such as sending email notifications on e2e failures.

Can't install Deis-cli

It seems that the bintray link is broken.

curl -sSL http://deis.io/deis-cli/install-v2.sh | bash
There doesn't seem to be a version of deis avaiable at https://bintray.com/deis/deisci/deis/_latestVersion

`deis limits:unset web=64M` doesn't unset the limit

k:mustache example-go [master]$ deis limits:unset web=64M
Applying limits... done

=== indoor-whitecap Limits

--- Memory
web     64M

--- CPU
web     250m
k:mustache example-go [master]$ deis limits
=== indoor-whitecap Limits

--- Memory
web     64M

--- CPU
web     250m
kubectl --namespace=indoor-whitecap describe po indoor-whitecap-v15-web-amixa
Name:       indoor-whitecap-v15-web-amixa
Containers:
  indoor-whitecap-web:
    QoS Tier:
      cpu:  Guaranteed
      memory:   Guaranteed
    Limits:
      cpu:  250m
      memory:   64Mi
    Requests:
      memory:       64Mi
      cpu:      250m

Looks like deis limits:unset web does, bit of a surprise behavior.

Proposal: support for multiple Deis clusters

As far as I can tell, the CLI stores all auth and registration information in $HOME/.deis/client.json, which means that the user has to use the same Deis cluster for all projects on their machine. Some users might like to use different Deis clusters on a per-project basis.

One possibility to accomplish this is to have the CLI look for a config file in the current directory, and fall back to the global one.

I'm not sure if we accomplish multiple Deis clusters in a different way, but if we have, I haven't found it.

Panic on `deis apps:info` for an existing app

The k8s-claimer exists and has at least one release.

ENG000656:k8s-claimer aaronschlesinger$ deis apps:info -a k8s-claimer
=== k8s-claimer Application
updated:  2016-04-08T17:48:22UTC
uuid:     4220ee5b-703f-47a6-8523-d32d026d2e41
created:  2016-04-08T17:47:55UTC
url:      
owner:    arschles
id:       k8s-claimer

panic: interface conversion: interface is nil, not []interface {}

goroutine 1 [running]:
github.com/deis/workflow/client/controller/client.Client.LimitedRequest(0xc8201582d0, 0x0, 0xc82015e1a0, 0x4, 0x0, 0x0, 0x0, 0xc82015e1a7, 0x14, 0x0, ...)
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/controller/client/http.go:82 +0x386
github.com/deis/workflow/client/controller/models/ps.List(0xc82018a000, 0xc8201562c0, 0xb, 0x64, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/controller/models/ps/ps.go:15 +0x1a7
github.com/deis/workflow/client/cmd.PsList(0xc8201562c0, 0xb, 0x64, 0x0, 0x0)
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/cmd/ps.go:26 +0xd0
github.com/deis/workflow/client/cmd.AppInfo(0x7fff5fbff9ba, 0xb, 0x0, 0x0)
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/cmd/apps.go:116 +0xa4f
github.com/deis/workflow/client/parser.appInfo(0xc82000a290, 0x3, 0x3, 0x0, 0x0)
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/parser/apps.go:138 +0x1d7
github.com/deis/workflow/client/parser.Apps(0xc82000a290, 0x3, 0x3, 0x0, 0x0)
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/parser/apps.go:34 +0x1ce
main.Command(0xc82000a290, 0x3, 0x3, 0x188850)
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/deis.go:87 +0xdc6
main.main()
    /Users/aaronschlesinger/gocode/src/github.com/deis/workflow/client/deis.go:18 +0x60

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1

Log source color assignments

At least twice now I have observed log messages from the first (or only) pod / container of a given app to be colorized in same way as log messages written by the controller on that application's behalf.

I realize we have a finite number of colors and we can't possibly avoid reusing them, but since web apps are initially scaled to 1, I do think we should be able to offer some assurance that the logs from the controller and the first / only pod are not colorized in the same way.

Weird UX on deis create --no-remote

This issue might be with the controller and not the CLI (I have not dug far enough to know yet), but CLI is my best guess.

[kent@mbp ~]$ deis create --no-remote
Creating Application... done, created queens-gemstone
remote available at ssh://[email protected]:2222/queens-gemstone.git

"remote available at ...?" I asked for no remote. Indeed, no deis remote gets created locally and I'll admit it's useful info insofar as I can infer the app name from it, but even so... it looks pretty weird.

It would probably be better to just respond saying the app named had been created.

Allow commenting out .env vars

When doing a config:push, the regex doesn't match and fails pushing variables, while it would be nice to temporarily turn certain .env vars off.

determine if domain is valid in 'certs:attach <cert> <domain>'

Currently, although certs:attach <cert> <domain> will properly error out if <cert> is bogus/non-existent, it doesn't if <domain> is similarly non-existent. Consider the following unit test, which is currently failing (err is nil):

if err := Attach(&client, "test-example-com", "non-existent.domain.com"); err == nil {
   t.Fatal("An Error should have resulted from the attempt to attach a valid cert to a non-existent domain")
 }

This issue tracks work on the client side, and deis/workflow#475 tracks server-side work

Remove the client from deis/workflow

When this repository is successfully publishing to bintray, remove the client code and related build/CI/publish functionality from deis/workflow

Notes:

  • Remove Bintray publishing templates, scripts and logic in the .travis.yml
  • Remove Go report card badge on the README.md

Update installation section in README

Installation

Currently the only way to use the go version of the deis client is to build it yourself. To build the deis client, you need to have go, glide, and make installed. Then run make build.

The installation section of the README is way out of date and hasn't been updated since I wrote this over the summer. It's now the official client and we should add instructions for how to install it from deis.io and bintray.

Write an intergration test suite

This or a related repository should have integration tests, which exercise the deis CLI against a real Deis cluster. The tests should run the CLI through the entire suite of normal operations. This issue is highly related to deis/workflow-e2e#132, which is in-progress and prescribes such tests.

v2.1 client not granting signature against workflow v2.0.0

Using the newest version of the CLI (2.1) I am unable to login to older versions of the workflow platform (tested on v2.0.0). Specifically, no signature is being retained by the client. E.g.:

$ deis login <a v2.0.0 workflow endpoint>
!    WARNING: Client and server API versions do not match. Please consider upgrading.
!    Client version: 2.1
!    Server version: 2.0
username: admin
password: 
!    WARNING: Client and server API versions do not match. Please consider upgrading.
!    Client version: 2.1
!    Server version: 2.0
Logged in as admin
$ cat ~/.deis/client.json 
{"username":"xxxx","ssl_verify":false,"controller":"<a v2.0.0 workflow endpoint>","token":"","response_limit":0}

I am not having this problem authenticating against v2.1.0 workflow clusters when using v2.1 of the client.

'-a' flag produces different output than '-a='

for example, when listing configs:

ENG000656:workflow aaronschlesinger$ deis config:list -a test1
=== test1 Config
A        B
FOO      1
ONE      1
ENG000656:workflow aaronschlesinger$ deis config:list -a=test1
=== =test1 Config

The former and the latter should produce the same output, or one should error.

Replaces deis/workflow#127

Alternative to 'glide up' when modifying 'glide.yaml'

In #128 we added logic around modifying a local glide.yaml with particular pkg/version values sent from the upstream controller-sdk-go PR job before building.

However, as noted in #128 (comment), this may update other dependencies when we strictly only want the sdk dependency updated. Therefore, this ticket represents researching a better way to bring in a particular PR change in controller-sdk-go...

deis keys:add should not throw a hard error

╰─± deis keys:add
Found the following SSH public keys:
1) deis.pub deis
2) id_boot2docker.pub [email protected]
3) id_rsa.pub [email protected]
0) Enter path to pubfile (or use keys:add <key_path>)
Which would you like to use with Deis? 4
panic: runtime error: index out of range

goroutine 1 [running]:
github.com/deis/workflow-cli/cmd.chooseKey(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /Users/jonathanchauncey/go/src/github.com/deis/workflow-cli/cmd/keys.go:130 +0xc43
github.com/deis/workflow-cli/cmd.KeyAdd(0x0, 0x0, 0x0, 0x0)
    /Users/jonathanchauncey/go/src/github.com/deis/workflow-cli/cmd/keys.go:71 +0xc6
github.com/deis/workflow-cli/parser.keyAdd(0xc820088010, 0x1, 0x1, 0x0, 0x0)
    /Users/jonathanchauncey/go/src/github.com/deis/workflow-cli/parser/keys.go:87 +0x1d7
github.com/deis/workflow-cli/parser.Keys(0xc820088010, 0x1, 0x1, 0x0, 0x0)
    /Users/jonathanchauncey/go/src/github.com/deis/workflow-cli/parser/keys.go:24 +0xbc
main.Command(0xc820088010, 0x1, 0x1, 0x18e0a5)
    /Users/jonathanchauncey/go/src/github.com/deis/workflow-cli/deis.go:105 +0x108a
main.main()
    /Users/jonathanchauncey/go/src/github.com/deis/workflow-cli/deis.go:17 +0x60

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1

Command requiring app name should inform when not provided

When an app name is not provided for deis commands technically requiring one the current default is to return the raw 404 Not Found response from the k8s api:

$ deis config:list
Error:
404 Not Found
detail: Not found.

It would be nice if the command could inform the user of the need/requirement to pass the app name (in the form of -a app_name) to properly proceed. (Basically, if the command hasn't been invoked with this parameter, send some default message to that effect)

Fix the README install language

Currently it says:

Currently the only way to use the go version of the deis client is to build it yourself. To build the deis client, you need to have go, glide, and make installed. Then run make build.

This isn't true. After #7 is done, this repo will be publishing it to bintray (although deis/workflow was already publishing it), so the README should say that

remove extra newline from `deis logs`

deis logs always prints an extra newline character. We should strip it out.

><> deis logs
INFO [go]: domain go removed
INFO [go]: bacongobbler created initial release
INFO [go]: domain go added

rename binary as workflow

Right now the Makefile dumps out a binary called deis. Since the project is being renamed to workflow, we should also update this and any other relevant documentation/build scripts etc.

refs deis/deis#4952

'deis logs' still references the 'workflow pod'

The language should say 'controller pod' instead. Example output (see the 2nd item in the list):

ENG000656:example-go aaronschlesinger$ deis logs
Error: There are currently no log messages. Please check the following things:
1) Logger and fluentd pods are running.
2) If you just installed the logger components via the chart, please make sure you restarted the workflow pod.
3) The application is writing logs to the logger component.
You can verify that logs are appearing in the logger component by issuing the following command:
curl http://<log service ip>:80/logs/gotest on a kubernetes host.

upload builds to S3

bintray's terms of use does not allow development builds to be uploaded. Because of this, we hit deis/workflow#282. Moving us back to S3 and updating install-v2.sh would help us in this regard.

Not labelling as a showstopper for v2 but certainly something we need to do ASAP.

workflow-cli failing to send a complete request

While testing deis/charts#310, I'm seeing this error crop up quite often in e2e:

$ deis auth:register http://deis.k8s.local --username=test-35207 --password=asdf1234 [email protected]
Registered test-35207
Logged in as test-35207
$ deis apps:create test-695112108 --no-remote
Creating Application... done, created test-695112108
If you want to add a git remote for this app later, use `deis git:remote -a test-695112108`
$ deis builds:create --app=test-695112108 deis/example-dockerfile-http
Creating build... ..oError: Unknown Error (400): map[detail:Error parsing HTTP response: invalid character '<' looking for beginning of value: "<html><body><h1>408 Request Time-out</h1>\nYour browser didn't send a complete request in time.\n</body></html>\n"]
$ deis apps:destroy --app=test-695112108 --confirm=test-695112108
Destroying test-695112108...
done in 1s
$ deis auth:cancel --username=test-35207 --password=asdf1234 --yes
Please log in again in order to cancel this account
Logged in as test-35207
Account cancelled


• Failure in Spec Setup (BeforeEach) [16.970 seconds]
deis config
/go/src/github.com/deis/workflow-e2e/tests/config_test.go:282
  with an existing user
  /go/src/github.com/deis/workflow-e2e/tests/config_test.go:235
    who owns an existing app that has already been deployed
    /go/src/github.com/deis/workflow-e2e/tests/config_test.go:233
      that user can set environment variables on that app [BeforeEach]
      /go/src/github.com/deis/workflow-e2e/vendor/github.com/onsi/ginkgo/ginkgo_dsl.go:354

      No future change is possible.  Bailing out early after 12.729s.
      Expected
          <int>: 1
      to match exit code:
          <int>: 0

      /go/src/github.com/deis/workflow-e2e/tests/cmd/builds/commands.go:34

Provide server version info in 'deis version'

From @jchauncey's comment in deis/deis#4674:

It would be nice if the deis cli had a version command that returned the version of the server running and the version of the cli (like the docker version command)

We could add a flag to deis version (#328) to provide more verbose information similar to docker version, like so:

><> deis version -a
Client version: 2.0.0-dev
Client API version: 2.0
Go version (client): go1.5.2
Git commit (client): foobar
OS/Arch (client): linux/amd64
Server version: 2.0.0-dev
Server API version: 2.0
Go version (server): go1.5.2
Git commit (server): foobar
OS/Arch (server): linux/amd64

Alternatively, We could turn it into a JSON object for formatting:

><> deis version -a
{
  "Client" {
    "Version": "2.0.0-dev",
    "APIVersion": "2.0",
    "GoVersion": "go1.5.2".
    "Commit": "foobar",
    "Arch": "amd64",
    "OS": "linux"
  },
  "Server": {
    "Version": "2.0.0-dev",
    "APIVersion": "2.0",
    "GoVersion": "go1.5.2".
    "Commit": "foobar",
    "Arch": "amd64",
    "OS": "linux"
  }

Which could be handy in the future for features like deis version -f '{{.Client.Version}}', which formats the version output through the given Go template (similar to docker inspect -f):

><> deis version -a -f '{{ .Client.Version }}'
2.0.0-dev

Note that deis/workflow#329 tracks server side work, and this issue tracks client side work.

Fix bintray deployment

From https://travis-ci.org/deis/workflow-cli/builds/114358111:

Installing deploy dependencies
[Bintray Upload] Reading descriptor file: _scripts/ci/bintray-ci.json
[Bintray Upload] Creating version '3d5345b'...
[Bintray Upload] Bintray response: 401 Unauthorized. This resource requires authentication
[Bintray Upload] Warning: Path: client/_dist/ does not exist.
[Bintray Upload] Publishing version '3d5345b' of package 'deis'...
[Bintray Upload] Bintray response: 401 Unauthorized. This resource requires authentication

Also, the entire build should fail if the binary wasn't uploaded to Bintray

send Slack notification if e2e fails/on proceed or abort prompt

The e2e stage in the workflow-cli pipeline currently awaits (indefinitely) for input if the first e2e run failed, asking the user whether to proceed (with another e2e run) or abort. It would be helpful if a Slack message was broadcast, perhaps to #testing, ideally pinging the owner of the PR, on this event.

Do not print out client warning so many times

╰─± deis register deis.foo.io
!    WARNING: Client and server API versions do not match. Please consider upgrading.
!    Client version: 2.0
!    Server version: 2.1
username: admin
password:
password (confirm):
email:
!    WARNING: Client and server API versions do not match. Please consider upgrading.
!    Client version: 2.0
!    Server version: 2.1
Registered admin
!    WARNING: Client and server API versions do not match. Please consider upgrading.
!    Client version: 2.0
!    Server version: 2.1
Logged in as admin

We should only warn the first time the command is executed.

Test CLI on Windows

We should use appveyor or something similar to run the unit test suite on windows to ensure that the cli is functional on windows and possibly upload builds to bintray.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.