gimme tip giving me auto (1.4.1)

[broady]

See travis log here:
https://travis-ci.org/GoogleCloudPlatform/golang-samples/jobs/110253789

$ eval "$(gimme tip)"
I don't have any idea what to do with 'tip'.
  (using type 'auto')
$ export GOPATH=$HOME/gopath
$ export PATH=$HOME/gopath/bin:$PATH
$ mkdir -p $HOME/gopath/src/github.com/GoogleCloudPlatform/golang-samples
$ rsync -az ${TRAVIS_BUILD_DIR}/ $HOME/gopath/src/github.com/GoogleCloudPlatform/golang-samples/
$ export TRAVIS_BUILD_DIR=$HOME/gopath/src/github.com/GoogleCloudPlatform/golang-samples
$ cd $HOME/gopath/src/github.com/GoogleCloudPlatform/golang-samples
$ gimme version
v0.2.2
$ go version
go version go1.4.1 linux/amd64

[tianon]

@meatballhat is Travis using -o pipefail on builds? This looks to me like gimme tip just outright failed for some reason, but we kept plowing through further commands regardless.

I've just tested locally, and after getting a suitable GOROOT_BOOTSTRAP this did work for me:

root@702ccc3cd64e:/go# eval "$(gimme tip | tee /proc/self/fd/2)"
error: Missing bootstrap installation
error: Unable to compile go from git clone
I don't have any idea what to do with 'tip'.
  (using type 'auto')
root@702ccc3cd64e:/go# eval "$(gimme 1.6 | tee /proc/self/fd/2)"

unset GOOS
unset GOARCH
export GOROOT="/root/.gimme/versions/go1.6.linux.amd64"
export PATH="/root/.gimme/versions/go1.6.linux.amd64/bin:${PATH}"
go version >&2

export GIMME_ENV="/root/.gimme/envs/go1.6.env"
go version go1.6 linux/amd64
root@702ccc3cd64e:/go# eval "$(gimme tip | tee /proc/self/fd/2)"

unset GOOS
unset GOARCH
unset GOROOT
export PATH="/root/.gimme/versions/go/bin:${PATH}"
go version >&2

export GIMME_ENV="/root/.gimme/envs/gotip.env"
go version devel +98cc8b4 Thu Feb 18 22:34:29 2016 +0000 linux/amd64

(using tee /proc/self/fd/2 so that we can do both eval and see what's getting executed in stdout)

On the flip side, we've had a few changes since v0.2.2, but nothing really jumps out at me as something that would cause this error-less failure: v0.2.2...master#diff-5ee4f58e325e1214290061f6948fdd60

(A new release being cut and pushed into Travis is likely warranted regardless.)

[broady]

Strange, though. It appeared to work a couple days ago:

https://travis-ci.org/GoogleCloudPlatform/golang-samples/jobs/110069647

6b9a0fa is this commit:
golang/go@6b9a0fa

[jgsqware]

what about this? I got exactly the same quite randomly

[broady]

ping?

[Thomasdezeeuw]

It's failing for me to, with the following log from Travis:

$ GIMME_OUTPUT=$(gimme tip) && eval "$GIMME_OUTPUT"
I don't have any idea what to do with 'tip'.
  (using type 'auto')
The command "GIMME_OUTPUT=$(gimme tip) && eval "$GIMME_OUTPUT"" failed and exited with 1 during .

Weird thing is that it worked 2 days ago. Was the version of Gimme updated on travis-ci.com, where this broke?

[broady]

I think it's working now. Ping?

[Thomasdezeeuw]

It's fixed for me.

[barsanuphe]

I'm still getting this exact error.

[ramya-rao-a]

This was working just fine all these days, and suddenly this error re-appeared today, anyone else seeing the same?

[erocheleau]

I also seem to have the same issue or a similar issue :(

My Travis build just timeout after 10 minutes while waiting on this line:

$ GIMME_OUTPUT="$(gimme tip | tee -a $HOME/.bashrc)" && eval "$GIMME_OUTPUT"

[philpennock]

The gimme tip command will always be prone to spurious failures, because it has to talk to a git repo, clone content and do a full make from source of code which has not been vetted for production release. There have been breakages of code I've seen caused by temporary problems with tip.

Something like this might be a good choice; it's what I have in one project but with versions bumped to be current:

matrix:
  allow_failures:
    - go: tip
  fast_finish: true
  include:
    - go: 1.10.x
      env: UPLOAD_COVERAGE=true
    - go: 1.9.x
    - go: tip

I don't want to immediately close an issue if people are still seeing it, but I don't think that there's too much I can do to this, unless we want to have gimme have a "verbose" mode between silent and debug, which can be auto-enabled based on some common CI variables, and which mentions to stderr where it is with the process of making a version available.

Would an issue tracking that as a feature request and marking this issue as dependent upon it, so that we close this issue once that feature lands, be acceptable to folks?