Hello i am currently running into a problem with using Heroku! It finds all my dependency's until
build project: cannot load io/fs: cannot find module providing package io/fs
I have the vendor directory on my github repo but it just wont build?
On heroku -> your project -> Settings -> Buildpacks, and add 'heroku/go'.
Then execute in any terminal:
heroku config:set GOVERSION=1.16
Per #jimb, you're likely using an earlier than Go 1.16 version.
fs became available with Go 1.16:
https://pkg.go.dev/io/fs?tab=versions
Check
go version
And you go.mod Go version.
Related
Hi we are seeing wrong go version is downloaded when i push my binary file to cf
Steps followed to push code
run go build command
GOOS="linux" GOARCH=amd64 go build ${LDFLAGS} -o localdeploy/some-app main.go
cd localdeploy
cf push -f manifest.yml
Note: localdeploy folder contains manifest.yml and some-app binary file
Go.mod file
go 1.16
require (
github.com/cloudfoundry-community/go-cfenv v1.18.0
github.com/gin-gonic/gin v1.8.1
github.com/google/uuid v1.3.0
github.com/rs/zerolog v1.28.0
github.com/stretchr/testify v1.8.0
)
manifest file.yml
applications:
- name: some-app-1000-snapshot
command: ./some-app
stack: cflinuxfs3
buildpacks:
- https://github.com/cloudfoundry/binary-buildpack.git
Then i see following logs downloading go 1.15.5 instead of go 1.16
Below are the logs getting when pushed to cf --- application is working but why it is downloading 1.15 instead of 1.16 which is present in my mod file
Staging app and tracing logs...
-----> Download go 1.15.5
-----> Running go build supply
/tmp/buildpackdownloads/d612ac0e3047b21e80ecfeae72c39f81 ~
~
-----> Binary Buildpack version 1.0.46
-----> Download go 1.15.5
-----> Running go build finalize
/tmp/buildpackdownloads/d612ac0e3047b21e80ecfeae72c39f81 ~```
The binary buildpack doesn't install anything for your application. It is effectively a no-op buildpack.
Since you have compiled your application locally, the version of Go that is used for your binary is the version installed locally on your computer. You control that version based on what you have installed locally.
The output of the binary buildpack is confusing here, because you do see it downloading an older Go version. The reason this happens is because the buildpack itself is written in Go and you have the buildpack definition in your manifest.yml pointing to the source code of the buildpack. Thus to run the buildpack, it has to compile itself first. It needs Go to do that, so it downloads Go, builds itself, then runs itself. That's what you're seeing where it says Download go 1.15.5.
Most (all?) CloudFoundry installations are going to have the binary buildpack by default, so you don't need to reference the source. Run cf buildpacks and get the name of the binary buildpack from the list. It'll be something like binary-buildpack or binary_buildpack. Edit your manifest.yml and replace https://github.com/cloudfoundry/binary-buildpack.git with that value.
Now when you push, it'll use the existing buildpack which is already compiled and you shouldn't see those messages about Go being downloaded.
Im trying to rebuild a golang github repository to apply some minor changes.
The go application Im trying to modify is the following https://github.com/lian/msfs2020-go
Please use the provided github link to inspect the file tree.
I used the master branch and extracted it to /user/Documents/msfs2020-go-master
If I call go build from /user/Documents/msfs2020-go-master the output equals: no Go files in /user/Documents/msfs2020-go-master
I tried deleting the go.mod and recreating it with go mod init github.com/lian/msfs2020-go followed with a go mod tidy
but still no Go files in /user/Documents/msfs2020-go-master
Here the current go.mod
module github.com/lian/msfs2020-go
go 1.16
require github.com/gorilla/websocket v1.4.2
And here the go.sum
github.com/gorilla/websocket v1.4.2 h1:+/TMaTYc4QFitKJxsQ7Yye35DkWvkdLcvGKqM+x0Ufc=
github.com/gorilla/websocket v1.4.2/go.mod h1:YR8l580nyteQvAITg2hZ9XVh4b55+EU/adAjf1fMHhE=
The master was build with 1.14 and Im using 1.16 golang.
All my test go applications/modules run/build/install fine at a "Hello World" developing level.
What did I do wrong? I gladly accept any input and will provide additional information's if requested.
The command go build builds the package in the current working directory. The command reports an error because there is not a package at the root of the repository.
Fix by building the package containing the command. Any of the following will work from the root of the repository:
go build ./vfrmap
or
cd vrfrmap
go build
or
go build github.com/lian/msfs2020-go/vfrmap
See also the file build-vfrmap.sh.
When I open my Goland project, the following command is run:
/usr/local/Cellar/go/1.14/libexec/bin/go list -m -json all #gosetup
Its output is the following error:
go list -m: can't compute 'all' using the vendor directory
(Use -mod=mod or -mod=readonly to bypass.)
Goland cannot resolve the packages I'm importing.
When I build and run the project from the command line, it works fine.
My project is structured as follows:
app/
bin/
pkg/
src/
app/
cmd/
vendor/
go.mod
My GOROOT is /usr/local/Cellar/go/1.14/libexec and my GOPATH is app/.
In Goland settings, under Go/GOPATH have checked the boxes for "Use GOPATH that's defined in system environment" and "Index entire GOPATH".
Under Go/Go Modules (vgo), I have checked "Enable Go Modules (vgo) integration" and "Vendoring mode"
I have just noticed when I change the GOPATH to /Users/myname/sdk/go1.13.4, the problem is solved. Could this be an issue with Homebrew or a change introduced with go 1.14 that I am not aware of?
I'm being exhaustive when describing the issue because I'm unfamiliar with Go and might be missing something obvious.
Thanks!
This is a known problem with Go Modules and vendoring support due to tooling change in Go 1.14.
As such, please try the EAP version of the IDE, https://jetbrains.com/go/nextversion, which contains a fix for this.
We are tracking this under https://youtrack.jetbrains.com/issue/GO-8855 and thinking about backporting this to the 2019.3 release cycle.
Disabling Go modules integration in Goland works for me
File->Preferences->Go->Go Modules->Enable Go modules integration
I'm writing a webapp in Go which uses Postgres for data storage and deploy in on Heroku. How can I run migrations automatically?
I use Go 1.13, for dependency management I want to use Go Modules.
As a migration tool I tried this https://github.com/golang-migrate/migrate.
Locally I just downloaded latest binary from github releases and run CLI utility ./migrate -database $DATABASE_URL -path migrations up.
Heroku Procfile content
release: migrate -database $DATABASE_URL -path migrations up
web: bin/myawesomegoapp
Of course, when I launch git push heroku master I get an error, that "migrate" no such file or directory, release command failed and push rejected.
So, how can I set up project to install migrate command to be able to run it on heroku on every release?
You have to tell Heroku to build it, and it's a bit of a pain. Here's how you make it happen using go modules.
First you have to tell go modules to include it even though it's not referenced in the source. This is discussed here. This is my tools package which lives in tools.go in the root of my project:
// +build tools
package tools
// See this https://github.com/go-modules-by-example/index/blob/master/010_tools/README.md
import (
_ "github.com/golang-migrate/migrate/v4"
_ "github.com/golang-migrate/migrate/v4/cmd/migrate"
)
I then vendored my dependencies.
go mod tidy
go mod vendor
Finally, you have to tell Heroku to build the binary for migrate which is not documented very thoroughly. For this you not only need to specify the path where migrate lives, you need to include a "." which tells heroku you also want to look for main packages in the working directory. This is because (I'm guessing) using that directive overrides their default package search behavior. This is what my modules file looks like:
module ...
// +heroku goVersion 1.14
// +heroku install -tags 'postgres' ./vendor/github.com/golang-migrate/migrate/v4/cmd/migrate .
go 1.14
require (
...
I have an application that loads plugins on startup (daemon). In a subpackage (daemon/interfaces), I have a few interfaces that plugins for this program should use.
This means that the main program also gets imported by the plugin.
I am using Go modules (for both the main program and the plugin) to fix the versions, and I can see in go.mod that it is using the latest version of the main program for the plugin.
I can build them both fine, but when I load the plugin it gives me an error saying
panic: plugin.Open("plugins/my-plugin"): plugin was built with a different version of package daemon/interfaces
I am using Go 1.12.7 to build both of the packages.
I fixed this by adding a replace statement to my plugin go.mod file
module github.com/user/plugin
go 1.12
require (
github.com/user/daemon v1.1.1
)
replace github.com/user/daemon v1.1.1 => ../local/path/to/daemon/
It also helps when you are building the project from outside of the directory where the source code is in by using the full name of the project (go build github.com/user/project/)
There is a related Github issue on the Golang repository that you can find here
Apparently, the issue is still open. The issue opener presented the workaround, which I was able to use. Please look at the history lines below for details.
git clone https://github.com/zimnx/central.git
git clone https://github.com/zimnx/plugins.git
cd central/
go clean -modcache
git checkout v1.0.0
go install -a
cd ../plugins/
rm go.mod
go mod init github.com/zimnx/plugins
echo '' >> go.mod
echo 'replace github.com/zimnx/central => ../central' >> go.mod
go build -buildmode=plugin -o plugin.so
central plugin.so
Works for me. Mistery still... :) The output has been saved for the most curious.