vmware-archive/fly

old - now lives in https://github.com/concourse/concourse

moved to concourse/concourse

This repository has been incorporated into the concourse/concourse repo as part of The Great Project Restructuring of 2018.

fly's Issues

hijack presents one option if 2 tasks are named the same

When creating a test pipeline I added two tasks with the same name in a single job. When I hijacked in I was presented with only one of the steps and I'm not sure how fly chose which one to use. The fix is likely to, not name 2 things the same, but seems like it's worth bringing up. Example yml:

      - task: some-task
        config:
          platform: linux
          run:
            path: sh
            args:
            - -c
            - echo "things"
      - task: some-task
        config:
          platform: linux
          run:
            path: sh
            args:
            - -c
            - echo "other-things"

The fly hijack helper only outputs a single task named some-task.

fly login doesn't let you leave

When performing fly login, if there are multiple options (e.g. basic auth and github) the user is presented with a menu. This menu does not respond to ctrl+c, and invalid numbers are met with the menu again.

ctrl+d does work but it's not very elegant (just provides error" EOF). So I suppose an alternate title for this issue could be:

"Fly login should respond to ctrl+c with graceful shutdown, and should also exit on invalid option"

I haven't checked other interactive commands but they might fail in the same way

fly login is missing options for username and password

When we are automating fly commands for concourse, since version 0.66.0, we need to login via the CLI.

The fly login should include command like options for username and password for basic auth.

For example:

fly -t http://my.ci login --username=awesome --password=password

Might have to provide an option for provider, so basic auth or Github can be chosen.

Should honour .gitignores of submodules when passing -x

Looks like --exclude-ignored only excludes things .gitignore-d by the current repo, not things excluded in submodules (I think this is because it tars up the result of git ls-files which lists the non-ignored files in the current repo, but lists the base directory for submodules).

We have a bosh workspace which we run fly from with various submodules, some of which have large files in them that we'd rather not push up when running fly. Adding them to the .gitignore of the parent repository doesn't help because git ls-files still includes the submodule path, which gets tarred up as a whole.

fly execute -x ignores .git directory

This presents problems when external dependencies rely on git to compile (coughetcdcough).

It'd be great if we could ignore .gitignored files without ignoring .git configuration.

fly should not panic

When the user does not specify a job while hijacking fly panics:

fly -t target -j pipeline results in:

fly chokes on superfluous trailing slashes in the ATC URL

This:

fly --atcURL http://ci:8080

Works great. This:

fly --atcURL http://ci:8080/

Fails with a cryptic error. Like:

2015/02/05 15:57:25 bad response when creating pipe: &{301 Moved Permanently 301 HTTP/1.1 1 1 map[Location:[/api/v1/pipes] Date:[Thu, 05 Feb 2015 15:46:16 GMT] Content-Length:[0] Content-Type:[text/plain; charset=utf-8]] 0xc20803eb80 0 [] false map[] 0xc20803d110 <nil>}
HTTP/1.1 301 Moved Permanently
Content-Length: 0
Content-Type: text/plain; charset=utf-8
Date: Thu, 05 Feb 2015 15:46:16 GMT
Location: /api/v1/pipes

It would be great if fly tolerated the superfluous slash.

fly hijack --check doesn't work?

$ fly -t diego hijack --check main/diego-release
proc_starter: ExecAsUser: system: program 'bash' was not found in $PATH: exec: "bash": executable file not found in $PATH

not sure if i am doing something wrong here, but from my understanding of this feature i should be able to ssh into resource containers.

version fly the same as concourse bosh-release

it would be nice for the version of fly to be consistent with the version of the the bosh-release. It would also help in debugging any issues, as there is a meaningful version to which submitter can refer.

I don't know how e.g. the CF CLI manages this, but it shouldn't be too hard?

add `--handle` to `fly intercept` command

If you know the handle, e.g. from /api/v1/containers then this is helpful to clearly identify which container we want to intercept.

I would expect it would call directly to /api/v1/container/:handle and get a 404 if the container was not found for that handle

fly set-pipeline asks for yN, refuses to accept N.

set-pipeline asks for confirmation, but doesn't accept N as an answer.

apply configuration? [yN]: N
invalid input (not y, n, yes, or no)

Fly execute fails in an ungraceful way when inputs name is wrong

Using 0.63.0 we get a useless error when trying to execute a one-off build with the wrong input name:

 2015-09-25 11:41:26 ☆ ruby 2.2.2p95 (system) clementina in ~/workspace/concourse
± |develop ✓| → fly e -c ./ci/baggageclaim.yml -i baggageclaim=./src/github.com/concourse/baggageclaim/
executing build 6
failed

The input should have been concourse and not baggageclaim.

I would have expected to see a more helpful error message e.g. missing input: concourse

Hijack after execute

Add option to execute to automatically hijack a container after its build has failed. To jump in quickly for debugging.

fly API command to perform authenticated API calls to the currently targetted ATC

e.g.

fly api workers returns the same info as curling the api/v1/workers/ endpoint

I would expect to return the same json as the API

How to pass params into task without configuring pipeline

I'm filing this under fly, because the CLI doesn't expose the behavior I'm looking for. However I accept it may not (exclusively) be a CLI issue. Feel free to point me to a more appropriate repo and I'll re-open the issue there.

I can configure params in a pipeline with --var or --vars-from flags but I can't do the same for a one-off task.

I can think of a couple of situations where this would be useful:

1. Using one-off tasks to accomplish something that needs params (e.g. credentials) without having to make a pipeline. For example one could publish concourse templates or 'recipes' for one-off tasks where the user provides the specific values. This might be a better user experience than requiring them to configure an entire pipeline that they then have to delete when done.
2. Providing params for tests in one-off task mode, e.g. to emulate travis bilding components outside of a pipeline. This is something almost every integration test with 3rd-party service requires (think external service credentials)

Make fly available for download without authentication to concourse

Enhancement: Make fly download URI available without authentication or ship as separate binary.

save-target fails - build.yml: no such file

I'm not able to save a target to ~/.flyrc:

vagrant@vagrant-ubuntu-trusty-64:~/concourse$ fly save-target --api http://192.168.100.4:8080 test
2015/05/07 14:44:23 could not open config file: open /home/vagrant/concourse/build.yml: no such file or directory

Why does it need a build.yml to save my target to .flyrc?
I've used the command just as described on https://concourse.ci/fly-cli.html, 4.2.

add `fly containers` command

Given that we have /api/v1/containers endpoint, it would be helpful if fly could get a containers command. For example this could render (at a minimum):

containers:
- handle: handle1
  workerName: worker1
  type: Check
- handle: handle2
  workerName: worker1
  type: Get
- handle: handle3
  workerName: worker1
  type: Task

Aborted builds have BIG duration

When a build is aborted, the duration comes to be a big value, this should have been n/a.

id     pipeline/job                    build  status     start                     end                       duration
122  my-example-pipeline               1      aborted    n/a                       2016-03-28@15:49:26-0700  405334h49m26s

fly --version
0.76.1

Add support for fly to trigger build from configured pipeline

I have some pipelines configured and each time I e.g. reconfigure pipeline and want to try it, I need to go to the UI and click the + button to start build. Fly should be able to do that for me, optionally also watching the logs in one step.

Doesn't build via 'go get'

Nice clean Mac running Yosemite, fresh Go install from Homebrew, nope:

$ uname -a
Darwin hostname.redacted.com 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64
$ go version
go version go1.4.1 darwin/amd64
$ go get github.com/concourse/fly
# github.com/concourse/fly/commands
../.go/src/github.com/concourse/fly/commands/execute.go:99: unknown sse.EventSource field 'Client' in struct literal
../.go/src/github.com/concourse/fly/commands/execute.go:111: unknown sse.EventSource field 'CreateRequest' in struct literal
../.go/src/github.com/concourse/fly/commands/watch.go:25: unknown sse.EventSource field 'Client' in struct literal
../.go/src/github.com/concourse/fly/commands/watch.go:37: unknown sse.EventSource field 'CreateRequest' in struct literal

Halp plox.

fly execute does not fail if inputs are not provided

If a task has more than one input, and the set of inputs is not satisfied, fly should fail. In fact it succeeds.

This is a regression from previous behavior of fly - perhaps related to the recent rewrite

Variables get interpolated as quoted strings

When interpolation variables in a string like so:

resources:
    - name: test
      type: test
      source:
          uri: http://{{user}}:{{password}}@hostname

Fly adds quotes around the values:

~/Projects/concourse❯ fly set-pipeline -p test -c test.yaml --var user=test --var password=password

resources:
  resource test has been added:
    name: test
    type: test
    source:
      uri: http://"test":"password"@hostname

While my expected output would be:

~/Projects/concourse❯ fly set-pipeline -p test -c test.yaml --var user=test --var password=password

resources:
  resource test has been added:
    name: test
    type: test
    source:
      uri: http://test:password@hostname

I don't know if this is expected behaviour. Would be nice to use the templating system this way.

fly --vars-from does not respect ~ in path

> fly configure -c pipeline.yml --vars-from=~/workspace/some-repo/my-credentials.yml
2015/05/06 08:32:35 open ~/workspace/some-repo/my-credentials.yml: no such file or directory

works fine with full path (or indeed relative path)

fly should warn/avoid different versions of CLI and Concourse

It's very common to forget fly sync after Concourse update or when working with different installations of Concourse. As result you can get strange errors by some of the fly commands. It should be possible to avoid this situation. I'm not sure what the best strategy is but fly can e.g.:

• throw an exception when CLI and Concourse versions are different
• print a warning by different versions
• do the CLI update automatically

fly execute -x prints unexpected output if file was removed

@robdimsdale and I observed that when we delete a file that was checked in, and don't tell git (i.e. don't git rm) that fly execute -x prints following output:

executing build 14
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 30720    0 30720    0     0  13.5M      0 --:--:-- --:--:-- --:--:-- 29.2M
tar: tools/config.json: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.

The one-off build still runs as expected so this is just an issue with UI output

Listing available pipelines

It would be nice to be able to list the available pipelines, not only via the UI, but using the fly CLI as well.

Having something like fly pipelines in the CLI gives the user:

• means to automate / script
• complete and consistent feature set
• less task switching

Unable to move binary to /usr/bin on El Capitan

Hello,

I recently set up a new machine running El Capitan. After downloading the binary and attempting to run mv ~/Downloads/fly /usr/bin, get the following as my default user or as root.

$ mv ~/Downloads/fly /usr/bin
mv: rename /Users/pivotal/Downloads/fly to /usr/bin/fly: Operation not permitted

sudo mv ~/Downloads/fly /usr/bin
mv: rename /Users/pivotal/Downloads/fly to /usr/bin/fly: Operation not permitted

It seems like this is a known issue in the El Capitan OS, as described here: http://apple.stackexchange.com/a/193379. I ended up moving it to /usr/local/bin as it seems we are now only able to modify /usr/local.

fly should warn/tell the user that they can use -x when it will transfer large files

large git repos take a long time (and have other issues - see #31) so it would be helpful to remind the user that they can use -x to avoid this.

This could also take the form of a tip: TIP: use fly execute -x to avoid copying large git repos

fly `--paused=false` feature not working, also inconsistent UI behavior

When I initially deploy a pipeline, it's in the paused state even with the --paused=false flag:

$ fly -t tutorial configure -c pipeline.yml job-dummy --paused=false
resources:
  resource resource-dummy has been added:
    name: resource-dummy
    type: dummy
    source: {}

jobs:
  job job-dummy has been added:
    name: job-dummy
    public: true
    serial: true
    plan:
    - put: resource-dummy

apply configuration? (y/n): y
pipeline created!
you can view your pipeline here: http://192.168.100.4:8080/pipelines/job-dummy

the pipeline is currently paused. to unpause, either:
  - run again with --paused=false
  - click play next to the pipeline in the web ui

When I re-run the command immediately, with the --paused=false flag, I see this:

$ fly -t tutorial configure -c pipeline.yml job-dummy --paused=false
apply configuration? (y/n): y
configuration updated

Which seems to indicate the pipeline is unpaused (since it doesn't give the paused notice); however, it is actually still paused, which I saw when I went to the UI and saw the blue bar at the top:

Since using the --paused=false flag fails to unpause the pipeline from the CLI, I tried to unpause the pipeline in the UI; however, there is an issue unpausing. Click on job-dummy to view the job:

I there is a pause icon next to the name of the job, but if I click it the pipeline is actually still paused, even though the icon changes to a play icon, as evidenced by the blue bar:

In fact, the only way to unpause the pipeline is by clicking the other play button, hidden in the menu in the upper left corner:

Note that the state of the play button in the menu does not match the state of the play/pause button that is next to the pipeline name (job-dummy). Only once this blue play button in the left menu has been clicked will the pipeline be unpaused:

Once the pipeline is unpaused from the menu and is run for the first time, the play/pause button next to the pipeline name permanently disappears:

Note that it remains gone, even when the pipeline is paused again:

Can the functionality of the play/pause button on the job page please either be repaired or removed to avoid confusion? Also, can the fly command be updated so that when a pipeline is deployed with --paused=false that the pipeline is not initially paused? Forcing UI interaction makes scripting difficult :-/

What I am running:

• The latest fly binary - 0.0.1 (synced)
• The latest concourse/lite box - 0.60.1

`fly set-pipeline` shows diff when integers are used in pipeline YAML

Given the following test.yml pipeline manifest

---
resources:
  - name: test
    type: git

jobs:
  - name: test
    plan:
      - put: test
        params:
          test: 1234567890

When I successfully fly set-pipeline -p test -c test.yml,
When fly set-pipeline -p test -c test.yml again,
Then I see the following output

$ fly -t buildpacks sp -p test -c test.yml
resources:
  resource test has been added:
    name: test
    type: git
    source: {}

jobs:
  job test has changed:
    name: test
    plan:
    - put: test
      params:
        test: 1234567890

apply configuration? [yN]: y
configuration updated

$ fly -t buildpacks sp -p test -c test.yml
resources:
  resource test has changed:
    name: test
    type: git
    source: {}

jobs:
  job test has changed:
    name: test
    plan:
    - put: test
      params:
        test: 1.234568e+09
        test: 1234567890
apply configuration? [yN]:

I was expecting there would be no changes to apply to the configuration.

`fly set-pipeline` should not print unchanged jobs

I'm not sure if the behavior has always been like this, but when I am updating a pipeline fly prints out all the jobs, even ones that are not changed. In the attached screenshot the changed job/resource is correct, but I don't expect to see the other two jobs.

fly verb to list current targets

It would be nice to have a verb like fly targets which would list the current known/configured targets. While I realize they are listed in ~/.flyrc, searching this file is not a particularly intuitive method, and this seems like it would be a pretty trivial feature to implement. Maybe an alternative syntax could be fly -t without specifying a target to list them?

Fly should be able to watch the latest build

When git commit triggers build in pipeline and user want to watch it in the shell, build number must be known. It would be nice if latest or something auto like that would work.

Bonus points if wait for the build to start scenario would be handled as well, e.g. I'm doing commit, invoke fly, it waits until Concourse will notice the commit and start build, then start watching that build. This one is tricky, but would be really awesome to have.

Global flags should be less restrictive in their placement

I should be able to run fly configure -c file.yml -t awesome-ci-server and have it work rather than ignoring the target flag.

fly intercept --check with only a pipeline throws a stacktrace

I know this command is invalid, but a panic isn't so friendly.

$ fly intercept --check pipeline
panic: runtime error: index out of range

goroutine 1 [running]:
github.com/concourse/fly/commands.(*ResourceFlag).UnmarshalFlag(0x71df50, 0x7fff5fbffbce, 0x8, 0x0, 0x0)
    /var/vcap/packages/fly/src/github.com/concourse/fly/commands/resource_flag.go:19 +0x3f5
github.com/jessevdk/go-flags.convertUnmarshal(0x7fff5fbffbce, 0x8, 0x431980, 0x71df50, 0x16, 0x16, 0x0, 0x0)
    /var/vcap/packages/fly/src/github.com/jessevdk/go-flags/convert.go:157 +0x176
github.com/jessevdk/go-flags.convertUnmarshal(0x7fff5fbffbce, 0x8, 0x45c520, 0x71df50, 0xd9, 0x1a, 0x0, 0x0)
    /var/vcap/packages/fly/src/github.com/jessevdk/go-flags/convert.go:162 +0x2ab
github.com/jessevdk/go-flags.convert(0x7fff5fbffbce, 0x8, 0x45c520, 0x71df50, 0xd9, 0x5abec0, 0x72, 0xc82006bc20, 0x0, 0x0)
    /var/vcap/packages/fly/src/github.com/jessevdk/go-flags/convert.go:173 +0x79
github.com/jessevdk/go-flags.(*Option).set(0xc8200ff500, 0xc8200e9a28, 0x0, 0x0)
    /var/vcap/packages/fly/src/github.com/jessevdk/go-flags/option_private.go:41 +0x5e9
github.com/jessevdk/go-flags.(*Parser).parseOption(0xc820068780, 0xc82008f560, 0x7fff5fbffbc8, 0x5, 0xc8200ff500, 0xffffffffffffff01, 0x0, 0x0, 0x0)
    /var/vcap/packages/fly/src/github.com/jessevdk/go-flags/parser_private.go:186 +0x642
github.com/jessevdk/go-flags.(*Parser).parseLong(0xc820068780, 0xc82008f560, 0x7fff5fbffbc8, 0x5, 0x0, 0x0, 0x0)
    /var/vcap/packages/fly/src/github.com/jessevdk/go-flags/parser_private.go:220 +0xe4
github.com/jessevdk/go-flags.(*Parser).ParseArgs(0xc820068780, 0xc82000a1d0, 0x3, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0)
    /var/vcap/packages/fly/src/github.com/jessevdk/go-flags/parser.go:230 +0xbaa
github.com/jessevdk/go-flags.(*Parser).Parse(0xc820068780, 0x0, 0x0, 0x0, 0x0, 0x0)
    /var/vcap/packages/fly/src/github.com/jessevdk/go-flags/parser.go:154 +0x9b
main.main()
    /var/vcap/packages/fly/src/github.com/concourse/fly/main.go:14 +0x62

goroutine 17 [syscall]:
os/signal.loop()
    /var/vcap/data/packages/golang/08f1cb1a11d32468882fc07a0d5b33fd735ddda4-879879219167b8e7b3c3232048c6e95f096aa90a/src/os/signal/signal_unix.go:22 +0x18
created by os/signal.init.1
    /var/vcap/data/packages/golang/08f1cb1a11d32468882fc07a0d5b33fd735ddda4-879879219167b8e7b3c3232048c6e95f096aa90a/src/os/signal/signal_unix.go:28 +0x37

fly status command to provide high-level info about the ATC in question

It would be nice to get some high-level info about the ATC via a command like fly status - similar to bosh status

`fly execute ...` panics when setting the output directory for a task with no outputs

We're setting up a new task in our pipeline which will have an output but currently doesn't. For one-off testing, we have been using a command like:
fly -t foo execute --config=task.yml --input=source=. --output=artifact=./tmp

This succeeds when --output is not specified (although task.yml does specify an output with the same name). But with it, most of the way through our command's output in the terminal, we get:

panic: unexpected EOF

goroutine 36 [running]:
github.com/concourse/fly/commands/internal/executehelpers.Download(0x7fff5fbffbac, 0x5, 0x820a8c240, 0x35, 0x820a747e0, 0x24, 0x820a437a0)
    /var/vcap/packages/fly/src/github.com/concourse/fly/commands/internal/executehelpers/downloads.go:45 +0x6de
...

Clearly this was user error, but a meaningful error message would be great here.

fly hijack --help doesn't tell you that you can specify the execute command

When attempting to fly hijack a container that doesn't have our shell, bash, installed we get the following error:

$ fly hijack -b 17 -s some-get-step
proc_starter: ExecAsUser: system: program 'bash' was not found in $PATH: exec: "bash": executable file not found in $PATH

This can be worked around by specifying a command to execute while hijacking, e.g.

fly hijack -b 17 -s some-get-step sh
/tmp/build/get #

However, specifying the execute command is not specified in fly hijack --help

fly hijack --help
error: Usage:
  fly [OPTIONS] hijack [hijack-OPTIONS]

Application Options:
  -t, --target=                     Concourse target name or URL (default: http://192.168.100.4:8080)

Help Options:
  -h, --help                        Show this help message

[hijack command options]
      -j, --job=PIPELINE/JOB        Name of a job to hijack
      -c, --check=PIPELINE/CHECK    Name of a resource's checking container to hijack
      -b, --build=                  Build number within the job, or global build ID
      -s, --step=                   Name of step to hijack (e.g. build, unit, resource name)

Thanks for your work on Concourse!

Tom D && Heather F

Sharing common config across multiple pipeline YAML files

We have multiple pipelines that we'd like to share config across (e.g. one for mainline build pipeline, another for feature branches, with some resources and jobs used by both). Pipeline groups aren't an option for us (we want to have different groups defined for each pipeline).

I know that YAML doesn't support this natively - is there any way to do it with the current fly set-pipeline implementation?

If not, any plans to add this? Could be a simple implementation, such as allowing multiple --config options on the set-pipeline command, with later entries being merged with and, if there are conflicts, overwriting previous ones.

Add 'rename-pipeline'

It sucks having to delete a pipeline and lose history when you want to just rename it.

fly execute has weird output when loading inputs

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 30720    0 30720    0     0  95544      0 --:--:-- --:--:-- --:--:-- 98146
100 6380k    0 6380k    0     0  1070k      0 --:--:--  0:00:05 --:--:--  706k
100 81920    0 81920    0     0  13426      0 --:--:--  0:00:06 --:--:-- 21059

Curl is really weird looking when uploading multiple inputs for fly execute

fly should support verbose mode

It would be helpful when debugging if the fly binary to support verbose mode, perhaps via -v and --verbose or via some environment variable like FLY_TRACE=true.

This mode could print out additional information, at the very least the requests it is making and the responses it received (perhaps using the httputil/DumpRequest and httputil/DumpResponse methods)

fly execute sometimes has weird curl errors

the ^C is from me in this one:

$ fly -t prod execute -c ci/tasks/test-unit.yml
executing build 26421
curl: res_query.c:252: __libc_res_nquery: Assertion `hp != hp2' failed.
gunzip: invalid magic
tar: short read
Aborted
exit status 1
failed
^C
aborting...
upload request failed: Put https://main.bosh-ci.cf-app.com/api/v1/pipes/9f6eb951-5093-4ad6-4909-92acf45283fa: EOF

i can only assume this has something to do with harry potter, but i double checked and my hp is definitely set to the sorcerer's stone

this one ran fine, i think, but still printed out this error:

$ fly -t prod execute -c ci/tasks/test-unit.yml
executing build 26419
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 3090k    0 3090k    0     0   376k      0 --:--:--  0:00:08 --:--:--  366kcurl: (23) Failed writing body (2048 != 6144)

I don't know what I've done to trigger these, other than running fly execute a couple times on possibly shitty wifi.

Saving a target does not end with a newline

my_prompt$ fly save-target cli --api a.b.com
successfully saved target climy_prompt$ _

Fly's `USAGE` is misleading

Here's an exchange between a fly newb and the tool:

 |2.2.2| conduit in ~/workspace/foo-ci
± mm+jc |master ✗||acceptance| → fly configure concourse/pipelines/test-s3-to-acceptance.yml -t foo
Incorrect Usage.

NAME:
   configure - Update configuration

USAGE:
   command configure [command options] [arguments...]

DESCRIPTION:
   Specify a pipeline name to configure via `fly configure your-pipeline-name-here`

OPTIONS:
   --config, -c                         pipeline configuration file
   --json, -j                           print config as json instead of yaml
   --var, -v [--var option --var option]            variable flag that can be used for filling in template values in configuration (i.e. -var secret=key)
   --vars-from, --vf [--vars-from option --vars-from option]    variable flag that can be used for filling in template values in configuration from a YAML file
   --paused                         should the pipeline start out as paused or unpaused (true/false)


flag provided but not defined: -t

 |2.2.2| conduit in ~/workspace/foo-ci
± mm+jc |master ✗||acceptance| → fly configure concourse/pipelines/test-s3-to-acceptance -t foo
Incorrect Usage.

NAME:
   configure - Update configuration

USAGE:
   command configure [command options] [arguments...]

DESCRIPTION:
   Specify a pipeline name to configure via `fly configure your-pipeline-name-here`

OPTIONS:
   --config, -c                         pipeline configuration file
   --json, -j                           print config as json instead of yaml
   --var, -v [--var option --var option]            variable flag that can be used for filling in template values in configuration (i.e. -var secret=key)
   --vars-from, --vf [--vars-from option --vars-from option]    variable flag that can be used for filling in template values in configuration from a YAML file
   --paused                         should the pipeline start out as paused or unpaused (true/false)


flag provided but not defined: -t

 |2.2.2| conduit in ~/workspace/foo-ci
± mm+jc |master ✗||acceptance| → fly configure -c concourse/pipelines/test-s3-to-acceptance.yml
please specify a pipeline name as an argument!

 |2.2.2| conduit in ~/workspace/foo-ci
± mm+jc |master ✗||acceptance| → fly configure -t foo -c concourse/pipelines/test-s3-to-acceptance.yml
Incorrect Usage.

NAME:
   configure - Update configuration

USAGE:
   command configure [command options] [arguments...]

DESCRIPTION:
   Specify a pipeline name to configure via `fly configure your-pipeline-name-here`

OPTIONS:
   --config, -c                         pipeline configuration file
   --json, -j                           print config as json instead of yaml
   --var, -v [--var option --var option]            variable flag that can be used for filling in template values in configuration (i.e. -var secret=key)
   --vars-from, --vf [--vars-from option --vars-from option]    variable flag that can be used for filling in template values in configuration from a YAML file
   --paused                         should the pipeline start out as paused or unpaused (true/false)


flag provided but not defined: -t

 |2.2.2| conduit in ~/workspace/foo-ci
± mm+jc |master ✗||acceptance| → fly -t foo configure -c concourse/pipelines/test-s3-to-acceptance.yml
please specify a pipeline name as an argument!

 |2.2.2| conduit in ~/workspace/foo-ci
± mm+jc |master ✗||acceptance| → fly -t foo configure test-s3-to-acceptance -c concourse/pipelines/test-s3-to-acceptance.yml

What I found particularly confusing is the guidance given by the USAGE sections. The usages given do not include compulsory arguments or global arguments.

Consider:

command configure [command options] [arguments...]

This would have been more useful as:

command [global options] configure <pipeline-name> [command options] [arguments...]

Or similar.

For reference, see this brief discussion of command line syntaxes.

fly uses bsd tar on OSX, creates stupid files

I think that's the explanation anyway. Lost my sanity when I was fly exec'ing a build using a completely clean local repo and it was still failing. Turns out it was a test that tars a directory of the project and then asserts on the contents of the tar, which then contains a bunch of weird files with underscore prefixes. Couldn't for the life of me figure out how BSD tar was ending up on the build machine, but then realized it was the process of uploading the code from my dev machine that was creating these extra files.

https://superuser.com/questions/61185/why-do-i-get-files-like-foo-in-my-tarball-on-os-x has at least one possible fix, setting COPYFILE_DISABLE=1.

If it helps, this is the failure I was getting from the bosh-utils test suite:

tarballCompressor CompressFilesInDir [It] compresses the files in the given directory 
/tmp/build/a2026ed8-7177-444a-7cbb-2defcf303c2b/gopath/src/github.com/cloudfoundry/bosh-utils/fileutil/tarball_compressor_test.go:136

  Expected
      <[]string | len:23, cap:23>: [
          "./",
          "./app.stdout.log",
          "./._some_directory",
          "./._other_logs",
          "./app.stderr.log",
          "./._app.stdout.log",
          "./other_logs/",
          "./other_logs/._other_app.stdout.log",
          "./other_logs/other_app.stderr.log",
          "./other_logs/more_logs/",
          "./other_logs/more_logs/._more.stdout.log",
          "./other_logs/more_logs/more.stdout.log",
          "./other_logs/._more_logs",
          "./other_logs/other_app.stdout.log",
          "./other_logs/._other_app.stderr.log",
          "./some_directory/",
          "./some_directory/sub_dir/",
          "./some_directory/sub_dir/._other_sub_dir",
          "./some_directory/sub_dir/other_sub_dir/",
          "./some_directory/sub_dir/other_sub_dir/.keep",
          "./some_directory/sub_dir/other_sub_dir/._.keep",
          "./some_directory/._sub_dir",
          "./._app.stderr.log",
      ]
  to consist of
      <[]interface {} | len:12, cap:12>: [
          "./",
          "./app.stderr.log",
          "./app.stdout.log",
          "./other_logs/",
          "./some_directory/",
          "./some_directory/sub_dir/",
          "./some_directory/sub_dir/other_sub_dir/",
          "./some_directory/sub_dir/other_sub_dir/.keep",
          "./other_logs/more_logs/",
          "./other_logs/other_app.stderr.log",
          "./other_logs/other_app.stdout.log",
          "./other_logs/more_logs/more.stdout.log",
      ]

  /tmp/build/a2026ed8-7177-444a-7cbb-2defcf303c2b/gopath/src/github.com/cloudfoundry/bosh-utils/fileutil/tarball_compressor_test.go:120

  Full Stack Trace
  /tmp/build/a2026ed8-7177-444a-7cbb-2defcf303c2b/gopath/src/github.com/cloudfoundry/bosh-utils/fileutil/tarball_compressor_test.go:120 (0x46d0a6)
    func.015: ))
  /tmp/build/a2026ed8-7177-444a-7cbb-2defcf303c2b/gopath/src/github.com/cloudfoundry/bosh-utils/fileutil/commands_suite_test.go:12 (0x4671c1)
    TestCommands: RunSpecs(t, "Commands Suite")
  /usr/local/go/src/testing/testing.go:447 (0x45ed5f)
    tRunner: test.F(t)
  /usr/local/go/src/runtime/asm_amd64.s:2232 (0x43ee31)
    goexit: 
------------------------------

Adding fly --version option

Hi, do you have any plan to add the feature showing version number like fly --version
It would be helpful for the users to know what version of CLI he is using.

thanks

fly execute doesn't like hard links

when forgetting to use -x fly tries to tar up the entire git repo which prints confusing output:

 2015-09-25 11:41:27 ☆ ruby 2.2.2p95 (system) clementina in ~/workspace/concourse
± |develop ✓| → fly e -c ./ci/baggageclaim.yml
executing build 7
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95.6M    0 95.6M    0     0  3963k      0 --:--:--  0:00:24 --:--:-- 4445ktar: can't create hardlink from ./.git/modules/src/github.com/concourse/gate/objects/pack/pack-5e7625078c21d7505391d37335d947c6a7b7c912.idx to ././@LongHardLink: No such file or directory
tar: can't create hardlink from ./.git/modules/src/github.com/concourse/gate/objects/pack/pack-5e7625078c21d7505391d37335d947c6a7b7c912.pack to ././@LongHardLink: No such file or directory
100 1752M    0 1752M    0     0  14.9M      0 --:--:--  0:01:57 --:--:-- 16.5M
initializing with docker:///concourse/baggageclaim-ci

Unable to use '-x' with large directories.

Attempting to use the -x option if the directory contains a large number of files results in the following:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     02015/06/01 15:49:32 could not run tar: fork/exec /usr/bin/tar: argument list too long

This is probably because the directory has 15,502 files in it. I believe the appropriate solution is to add the option -T - to the tar command, and to send the list of files to add via stdin.