Updates spf13/cobra dep to v0.0.5

[navidshaikh]

Fixes #426

• and a couple of patches on top which aren't merged yet
  • zsh: added custom completions spf13/cobra#884
  • Make sure we quote brackets when generating zsh completion spf13/cobra#899
• also updates viper to 1.4.0

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: navidshaikh

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [navidshaikh]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[navidshaikh]

➜  client git:(pr/update-cobra) source <(kn completion --zsh)     
compdef _kn kn  
➜  client git:(pr/update-cobra) kn service
create    -- Create a service.
delete    -- Delete a service.
describe  -- Show details for a given service
list      -- List available services.
update    -- Update a service.

[navidshaikh]

/hold

[maximilien]

/ok-to-test

[rhuss]

How can we track that we remove the temporary replacement when the next cobra release is out ?

otherwise I think its ok for me to include this bug-fix release here (it's about escaping [ in the help message, right ?)

But we should decide first on #439 which direction we want to go.

[navidshaikh]

We can't track that, we can open a ticket though in client to switch to spf13/cobra and we could cross check part of triaging client issues.

otherwise I think its ok for me to include this bug-fix release here (it's about escaping [ in the help message, right ?)

Yes.

About the comment on #439

if we don't use [ in our help messages)

There are some flags we inherit for machine readable output like --template whose help text we don't control. :-/

About using cobra from forked bug fix branch, I'd have deferred it if cobra PR turn around is quicker, apparently the PR from Chmouel is open since a while and this ended up even tkn using the fork of cobra.

[rhuss]

@navidshaikh oops, I tried to resolve the conflict in go.mod via the github UI, but probably did something wrong. Could you please have a quick look ? Should not be hard to fix.

[navidshaikh]

/retest

[navidshaikh]

Cross platform build failing with go: error loading module requirements, though it works locally for me. 🤔

[rhuss]

hmm, let me check that later today.

[rhuss]

@navidshaikh Looks like that the revision oc @chmouel fork is not available anymore but you had still a cache version.

For me it is

go: finding github.com/chmouel/cobra v0.0.0-20190820110723-8f09bb39b20d
go: github.com/chmouel/[email protected]: unknown revision 8f09bb39b20d
go: error loading module requirements

[chmouel]

Oops sorry about this guys, i'll make sure to update the forks in a backward compatible way and ping you all before doing it,

[chmouel]

and fyi it's a security release, viper 1.4.0 ie (spf13/cobra#978) you may want to mention it in your release changes

[navidshaikh]

Builds fine on my local machine, tried removing the cached version of vendored deps and re-populate it as well, but the build tests are failing in CI prompting

+golang.org/x/tools v0.0.0-20190311212946-11955173bddd h1:/e+gpKk9r3dJobndpTytxS2gOy6m5uvpg+ISQoEcusQ=
[..]
ERROR: /home/prow/go/src/knative.dev/client is out of date. Please run ./hack/build.sh -c and commit.

It reports that additional line in go.sum is missing from the PR change-set, running ./hack/build.sh -c locally doesn't add it locally. Could add that line in go.sum to pass the build tests.Happy to learn more about this if someone has insight on go modules.

[rhuss]

@navidshaikh I think it also depends on the go version you are using, as go mod is an intrinsic part of the go tool suite and hence the outcome also depends on whether you are using e.g. go 1.12 or go 1.13.

It's really something that we also should nail down when doing such sort of picky comparisons, like for that dep check. Not sure if go allows for fixing a 'format version' or if such thing just can slip through.

@navidshaikh could you check which go version is used on CI and which on your local machine, and if that differs, try locally with the same go version as on prow ?

[navidshaikh]

Local:

✗ go version
go version go1.12.9 linux/amd64

On the prow side, it doesn't print the Z stream version for go though

>> go version
go version go1.12 linux/amd64

[rhuss]

hmm. Then it looks like that something other is different local vs server side. Let me check that, too.

[rhuss]

I did some investigations on the go.sum issue. It turns out that hack/verify-codegen.sh calls internally (and uncoditionally) go install golang.org/x/tools/cmd/goimports. And this modifies go.sum (and is also the reason why there are so many golang.org/x/tools entries, as this list grows with new commits in the goimports repository)

Let me try to fix that in a subsequent PR. @navidshaikh for now, just run go install /Users/roland/Development/go/workspace/bin/goimports yourself and commit.

Some good go mod references I've met on the way:

• Why to commit go.sum at all ? (and wheter go.sum is a lock file) --> https://github.com/golang/go/wiki/Modules#is-gosum-a-lock-file-why-does-gosum-include-information-for-module-versions-i-am-no-longer-using
• Nice blog on go.mod in general --> https://medium.com/rungo/anatomy-of-modules-in-go-c8274d215c16

[navidshaikh]

Thanks @rhuss! I've updated the PR.

[navidshaikh]

/hold cancel

[rhuss]

/lgtm

[navidshaikh]

/retest