I'm working with operator-sdk and am seeing inconsistent behavior between VSCode and the CLI.
When I run with operator-sdk run --local I see the below. But VSCode shows no errors. I'm not really sure why that might be or where the problem is.
pkg/controller/mypackage/mycontroller_controller.go:207:4: cannot use testRef (type *"github.com/tektoncd/pipeline/pkg/apis/pipeline/v1alpha1".PipelineRef) as type "github.com/tektoncd/pipeline/pkg/apis/pipeline/v1alpha1".PipelineRef in field value
The code in question looks like this.
//...declaration
testRef := &tekton.PipelineRef{
Name: "mypipeline",
}
//..usage later...
Spec: tekton.PipelineRunSpec{
PipelineRef: testRef,
Params: []tekton.Param{{
I'm using gomodules, and the relevant module is -> github.com/tektoncd/pipeline v0.10.0
I understand that this is something to do with pointer referencing, and when I change my code to
testRef := tekton.PipelineRef{
Name: "mypipeline",
}
Then VSCode shows an error like below, but the CLI doesn't report any errors.
cannot use testRef (variable of type v1alpha1.PipelineRef) as *v1alpha1.PipelineRef value in struct literal
Is this just a module dependency problem and my upstream API changed somewhere? Maybe my cli and VSCode are reading different dependencies? I don't even know where to start... Any pointers (pun intended) are appreciated.
Related
I'm having an issue with using custom substitutions in my cloudbuild.yaml.
substitutions:
_CUSTOM_SUBSTITUTION: this-is-a-path
availableSecrets:
secretManager:
- versionName: projects/$_CUSTOM_SUBSTITUTION/secrets/client_id/versions/1
env: CLIENT_ID
- versionName: projects/$_CUSTOM_SUBSTITUTION/secrets/client_secret/versions/1
env: CLIENT_SECRET
From what I can tell from trial and error, using something like $PROJECT_ID in the place of $_CUSTOM_SUBSTITUTION will run the build, but if I use a custom substitution like above, the trigger does not run a build at all when a commit is pushed.
I've also tested with various other base substitutions, like $BRANCH_NAME to the same effect. I'm getting the feeling that it's just not possible to do this in cloudbuild at the moment?
It ended up being a combination of need curly braces ${_CUSTOM_SUBSTITUTION} and some syntax fixing in the cloudbuild.yaml. I didn't have enough experience with cloudbuild to find that.
The offending part was something this:
AUTH_TOKEN=$$(cat /workspace/token.txt). Originally I had just 1 $ there, which was also working code pulled from another project.
For anyone running into this in the future, using gloud builds submit can let you run it directly for troubleshooting.
I am a newbie in go and go-swagger. I am following steps in Simple Server tutorial in goswagger.io.
I am using Ubuntu 18.04, swagger v0.25.0 and go 1.15.6.
Following the same steps, there are a few differences of the files generated. For instance, goswagger.io's has find_todos_okbody.go and get_okbody.go in models but mine does not. Why is that so?
Link to screenshot of my generated files vs
Link to screenshot of generated files by swagger.io
Starting the server as written in the tutorial go install ./cmd/todo-list-server/ gives me the following error. Can anyone please help with this?
# my_folder/swagger-todo-list/restapi
restapi/configure_todo_list.go:41:8: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
restapi/configure_todo_list.go:42:6: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
The first step in goswagger.io todo-list is swagger init spec .... Which directory should I run this command in? I ran it in a newly created folder in my home directory. However, from the page, it shows the path to be ~/go/src/github.com/go-swagger/go-swagger/examples/tutorials/todo-list. I am not sure whether I should use go get ..., git clone ... or create those folders. Can someone advise me?
Thanks.
This is likely the documentation lagging behind the version of the code that you are running. As long as it compiles, the specific files the tool generates isn't so crucial.
This is a compilation error. When you do go install foo it will try to build the foo package as an executable and then move that to your GOPATH/bin directory. It seems that the generated code in restapi/configure_todo_list.go isn't correct for the operations code generated.
All you need to run this tutorial yourself is an empty directory and the swagger tool (not its source code). You run the commands from the root of this empty project. In order not to run into GOPATH problems I would initialise a module with go mod init todo-list-example before doing anything else.
Note that while the todo-list example code exists inside the go-swagger source, it's there just for documenting example usage and output.
What I would advice for #2 is to make sure you're using a properly released version of go-swagger, rather than installing from the latest commit (which happens when you just do a go get), as I have found that to be occasionally unstable.
Next, re-generate the entire server, but make sure you also regenerate restapi/configure_todo_list.go by passing --regenerate-configureapi to your swagger generate call. This file isn't always refreshed because you're meant to modify it to configure your app, and if you changed versions of the tool it may be different and incompatible.
If after that you still get the compilation error, it may be worth submitting a bug report at https://github.com/go-swagger/go-swagger/issues.
Thanks #EzequielMuns. The errors in #2 went away after I ran go get - u -f ./... as stated in
...
For this generation to compile you need to have some packages in your GOPATH:
* github.com/go-openapi/runtime
* github.com/jessevdk/go-flags
You can get these now with: go get -u -f ./...
I think it's an error of swagger code generation. You can do as folloing to fix this:
delete file configure_todo_list.go;
regenerate code.
# swagger generate server -A todo-list -f ./swagger.yml
Then, you can run command go install ./cmd/todo-list-server/, it will succeed.
Iam trying to build apprtc signaling server(collider). Based on tutorial, we only need to enter
go get collidermain
after setting $GOPATH. But I got error like this
> go get collider/collidermain
src/collider/collidermain/main.go:9:2: no buildable Go source files in /home/abdulmanaf/poc/apprtcNewVersion/apprtc/src/collider
Then I had tried to build collider folder. But I got error like this
> go get collider/collider
# golang.org/x/net/websocket
src/golang.org/x/net/websocket/dial.go:18:19: error: reference to undefined identifier ‘tls.DialWithDialer’
conn, err = tls.DialWithDialer(dialer, "tcp", parseAuthority(config.Location), config.TlsConfig)
What is the actual issue related to this? I need to build and deploy collider application
Sounds like you're using a really old version of go. Could you run go version?
tls.DialWithDialer was added in go 1.3 in 2014.
I have created a go script that compiles, starts, checks the status, and ends a web service I created (that is also in go). However, I have come to a road block.
With the compile feature I run the following command:
go install .
Which gives the following error:
./script.go:55: main redeclared in this block
previous declaration at ./hello.go:8
Which makes sense as I have two different files, both with the main func and main package. I also tried moving the script to another folder and then changing the command ran to:
go install {path}
Where {path} is equal to the path I want installed/compiled. Which I then got the following error:
exit status 1: can't load package: package /var/www/test.com/go: import "/var/www/test.com/go": cannot import absolute path
So in conclusion I have thought of only one solution (and I am up to hear others if mine isn't the best approach). My idea is to exclude the script file from compiling with the rest of the files, but I am unsure how to.
I did some research and couldn't find an easy way to do it (such as an --exclude flag with the go install command). Does anybody know how to accomplish what I am trying to achieve?
Thank you.
you could give the hello.go a different package name, that should work. Or i am missing something?
Regards
Tim
I'm trying to make a program dependent upon gcimporter15 for Go, and so I'm using the command "go get golang.org/x/tools/go/gcimporter15", but it fails with the error:
# golang.org/x/tools/go/gcimporter15
../../go/src/golang.org/x/tools/go/gcimporter15/bexport.go:557: undefined: constant.ToFloat
../../go/src/golang.org/x/tools/go/gcimporter15/gcimporter.go:396: pkg.SetName undefined (type *types.Package has no field or method SetName)
That appears to me that there is an error within gcimporter itself, but that doesn't make sense that I would get this when it doesn't appear that others are. Why isn't it working?
I'm using Go 1.5.3.
The godoc.org/golang.org/x/tools/go/gcimporter15 tells that the package gcimporter is deprecated and this package will be deleted in October 2017. And this new code should be used: golang.org/x/tools/go/gcexportdata instead of gcimporter .
So, what you have to do is:
$ go get godoc.org/golang.org/x/tools/go/gcexportdata
PS: Tested within Ubuntu 16.04 64bit and go version go1.6.2 linux/amd64 without any issues.
Test:
package main
import (
"fmt"
gcexportdata "golang.org/x/tools/go/gcexportdata"
)
func main() {
filename, path := gcexportdata.Find("fmt", "")
fmt.Println(filename, path)
}
Output:
/usr/lib/go-1.6/pkg/linux_amd64/fmt.a fmt
Its bad but seems there is a mismatch between the gcimporter15 and go-1.5. I faced the same problem and looked at go-1.5 code in file src/go/constant/value.go and there is no ToFloat() function in the constant package.
As #nexus66 says, the gcimporter is deprecated. So, I don't expect them to fix this. If you are using this package directly, its better to move on to the recommended gcexportdata package. If you are using a third party library which is in turn using gcimporter, may be you should upgrade to go-1.7. That's what I did and things worked fine.