I am trying to use Google Cloud Container Builder to automate the building of my containers using GCP Build Triggers
My code is in Go, and I have a vendor folder in my project root which contains all of my Go dependencies (I use govendor). However, this vendor folder is NOT checked in to source control.
I have a cloudbuild.yaml file where I first build my Go source into a main executable, and then build a Docker image using this executable. Container Builder ensures these build steps have access to my master branch.
The problem is that the Go compilation step fails, because the vendor folder is not checked in to source control, so none of my dependencies are available for any build step.
Is there a way to create a build step that uses govendor to install all dependencies in the vendor folder? If so, how? Or is the only option to check in my vendor directory into source control (which seems unnecessary to me)?
As per #JimB and #Peter's comments to my question, an easy solution is to add my vendor directory to Git so I don't have to download all my dependencies during the build steps.
Related
Asking to see what the appropriate workaround is for building individual go packages from the go/std library when working on a github repo fork. The issue encountered is summarized by the following error when building for example the src/go/parser package.
parser.go 21:2 use of internal package go/internal/typeparams is not allowed
Of course the project import paths all reference GOROOT library paths
usr/local/go
And I am typically working on projects from my own directory where my go path is set.
/Users/andewx/github/go/src/github.com/andewx/my_go_extension_project
The crux of the issue is that the clone/fork project uses standard library import paths and I would like to be able to work on my repo from my own GOPATH. But internal packages can't be imported in this case because the import directives will always point to my GOROOT.
The only two options I can think of is:
Extending my personal go project by initiating the repo inside of my /usr/local/go and working on the packages from there.
Changing my GOROOT to point to my current project and including current go binary go fmt and toolchains in my project
Ideally I can just leave everything as far as directory structure is concerned as is and I can redirect the standard import path for go standard library to my current project for this project only...
Any ideas from the community for solution #3 is what I'm looking for.
Extending my personal go project by initiating the repo inside of my /usr/local/go and working on the packages from there.
Changing my GOROOT to point to my current project and including current go binary go fmt and toolchains in my project
If you are trying to work on the go compiler and extend it I actually found that changing your GOROOT to point to your workspace and then copying over the binaries and tools you need as a suitable fix and it doesn't create any additional issues.
Export your environment variable export GOROOT="/my/go/project"
Find out where your go tools are located with go env GOTOOLDIR copy this directory structure into your project folder.
Copy go bin cp /usr/local/bin/* ${GOROOT}"/bin" copy in your go binary
Copy toolscp /usr/local/go/pkg/tool/linux_amd64/* ${GOROOT}/pkg/tool/linux_amd64
Now your project should be able to run the copied binaries with your project directories temporarily set as the GOROOT.
I have a go.mod file in a golang project, and I also have another go project which is embedded in this project, but vscode does not seem to recognize this embedded project. Is there a way to work with multiple golang project with vscode?
You have to add the modules directory to your workspace using the "file / add folder to work space" menu.
What you have is a multi-module workspace and this is supported by Go and VSCode. If you are using Go 1.17 and earlier then fix is a configuration option on VSCode (experimentalWorkspaceModule setting). If you have Go 1.18+ then fix is using the new go.work file.
Check this article for more details https://github.com/golang/tools/blob/master/gopls/doc/workspace.md
The way I have my projects structured is similar to the following
/workspace
/src
/package1
/vendor
/src
/somepackage
/anotherpackage
/package1
My GOPATH is set to /workspace;/workspace/vendor
Note this is not using the go 1.5 vendor option.
So far everything has been compiling and working fine within out build / development workflow.
I'm in a situation now where I would like to import a library into the vendor directory workspace/vendor/src/package1 but write some unit tests in the workspace/src/package1 directory..
When the tests run it cannot find methods from the package1 in the vendor dir.
Is there a way to get the vendor package code recognised into the same namespace like this?
Are you asking to essentially "split" the code for a package between two folders in two different gopaths? The go tool cannot do this, as it takes the first folder it finds on any folder in your gopath. If you are actively working on a project, why would it go in the vendor gopath and not in the src one?
It is because of distinctions like this that I generally recommend one gopath for everything. If you want to vendor dependencies I recommend doing that for each individual main package you have.
As captncraig said: The go tool cannot do this.
But you are free to call the go compiler itself on any set of files you want: go tool compile <file.go>...
Of course this would reintroduce some kind of Makefile style build system. It is doable but all the heavy lifting done by go build or go install is lost and will have to live in your Makefiles.
Coming from a JVM background I would like to know how to deploy a golang project to production. Is there an equivalent of a JAR file?
Is there a standalone package manager that can be installed on server and a dependency manifest file which can be run to bring down all dependencies on the server. I specifically do not want to have to build the project on the server as we can't have any compilers etc on production boxes.
thanks.
I you run go install <pkg>, the binary will be placed in $GOPATH/bin. You can copy that binary to another machine that has the same OS and architecture.
You can also change into the directory that includes the main package and just run go build. The binary will be placed in the current directory.
There are no dependencies in a Go binary for you to track. It is statically linked. (Some system libraries may be dynamically linked, but if you are running on the same OS, this shouldn't be a problem.)
I'm giving a Clojure workshop and I want people to be able to modify and recompile the Clojure project. The challenge is that they won't have internet connections - so I need to give them the project and the libraries all at once.
How can I package up a leiningen project for recompilation with all the libraries included?
Assumptions
They have leiningen installed on their machine prior to the workshop.
EDIT
This is almost the same question as How to package up a maven project for recompilation with all the libraries included? [without an internet connection]
Move your ~/.m2 directory aside. Run all the lein x leiningen commands you expect your users to have run, also build and test your project (test, install, jar, uberjar, etc.). This will have downloaded (a lot) of dependencies for Leiningen itself as well as for your project. $HOME/.m2 is where you'll find all the jar files that were pulled down by the Maven dependency resolver.
Once you've done this, add :offline? true to the project.clj, According to the documentation, this will Prevent Leiningen from checking the network for dependencies.
See Maven - alternative .m2 directory for an alternative to having to move your .m2 directory aside.
To make using it easy for your students, it may be best to create a self-contained zip archive with the entire .m2 directory, your project and Leiningen itself, along with a basic installer (bash script, or batch file) that moves or symlinks the .m2 directory into the proper place and adds the lein script to the path. This approach should satisfy the off-line needs - I think it covers all of the dependencies you would need.
I have assumed that your students will have java installed and have it on their PATH. Pre-running all of the lein commands you expect to use is important, as some of them have their own dependencies that are only resolved when they are first run.