IssueTracker

This issue is assigned to an engineer for further evaluation

The same bug with Eclipse 3.6 on Linux.

Same bug with Eclipse 3.7 on Linux (Arch 64bits)

Is it me or this post is more than 2 years old and have not been resolved yet ?

No! It's the way it is. Looks like it hasn't been solved up to now. I just needed to "fix" it with this workaround. And it caused other troubles like no completions available and stuff...

I could not reproduce this. In any case, ADT 14 logcat view is also a complete rewrite. Are any of you seeing this with ADT 14?

DDMS is blank for me with ADT 14, eclipse 3.7.1 and Ubuntu

The same for me...ADT 14 eclipse 3.7.1 and ubuntu
In fact I'm suffering strange issues since I have updated.

Anyone else?

Just updated my ADT to 15.  NOW I have this problem (was working fine before).  Running Eclipse 3.5.2 on Mac OSX 10.6.7 (Snow Leopard).

[Comment deleted]

Please file a new bug with reproducible steps if you still see this issue.

i Hand This Problem ,
Please Fix.

> Is this a serious bug requiring a bunch of architecture change or just something resulting out of old tools not having gotten vendor support (properly). Does this bug mean vendoring of packages with their own internal packages will not work at all? Is there a short term work around you can suggest?

The good news is that the issue that resulted in that advice from support was rolled back, and we aren't going to roll forward until I've fixed the underlying performance issues in the go compiler service. That work has been progressing nicely in the past week.

As for the gcloud vendoring issue: yes, this is still a known issue, and we've been talking about possible fixes with a few customers. The issue is that go-app-stager combined with the custom app engine standard go-app-builder is resulting in double-imports and mishandled internal and vendored packages. I don't have a good workaround for you at the moment.

I have just tried this on v178.0.0 and still get the same issue for my vendor folder items.

PS F:\Gowork\src\go-grid> gcloud app deploy --version=07nov2017
Services to deploy:

descriptor:      [F:\Gowork\src\my-app\app.yaml]
source:          [F:\Gowork\src\my-app]
target project:  [my-project]
target service:  [test]
target version:  [07nov2017]
target url:      [https://my-project-dot-myproject.appspot.com]


Do you want to continue (Y/n)?  y

Beginning deployment of service [test]...
Some files were skipped. Pass `--verbosity=info` to see which ones.
You may also view the gcloud log file, found at
[C:\Users\--snip--\AppData\Roaming\gcloud\logs\2017.11.07\10.41.33.897000.log].
#============================================================#
#= Uploading 0 files to Google Cloud Storage                =#
#============================================================#
File upload done.
Updating service [test]...failed.
ERROR: (gcloud.app.deploy) Error Response: [9] Deployment contains files that cannot be compiled: Compile failed:
2017/11/07 02:42:00 go-app-builder: build timing: 79\xd7compile (22.691s total), 0\xd7link (0s total)
2017/11/07 02:42:00 go-app-builder: failed running compile: exit status 2

my-app/config.go:8: can't find import: "github.com/gorilla/mux"
config.go:8: can't find import: "github.com/gorilla/mux"

the 'old' goapp deploy works fine for the same code
   ... but continuing to use that is uncomfortable since gcloud doc / update says that tooling is considered old and should be removed!

To clarify comment#9 -- this bug has been present for a while; it's not new. It is still in the pipeline to get fixed but we haven't addressed it yet.

Any updates on this? I'm having the same issue when using the aws sdk:
ERROR: (gcloud.app.deploy) Error Response: [9] Deployment contains files that cannot be compiled: Compile failed:
/work_dir/github.com/aws/aws-sdk-go/aws/awsutil/path_value.go:9: can't find import: "github.com/jmespath/go-jmespath"

Any updates on this?

As a workaround, I added steps to our build to remove the vendor directory and install the same dependencies at the GOPATH root. That resolved the issues we were having with gcloud app deploy.

comment#18 is the currently recommended workaround, but a real fix for vendoring support will ship before we launch go1.10 on app engine. Expect this to be fixed within a few months.

I am also hitting this and hoping for a fix soon

Copying the vendor files into the root of the app isn't really working for me.  It works for some packages (github.com/gorilla/mux), but for the appengine files I eventually get a cyclic dependency on appengine/aetest.

Initial error:
Compile failed:
/work_dir/google.golang.org/appengine/aetest/instance_classic.go:5: can't find import: "appengine/aetest"

and I then copy that folder into $APPROOT/appengine/aetest I get the following error

ERROR: (gcloud.app.deploy) Error Response: [9] Deployment contains files that cannot be compiled: Compile failed:
2018/04/04 16:10:34 go-app-builder: Failed parsing input: parser: cyclic dependency graph: appengine/aetest -> appengine/aetest

However using the legacy `goapp deploy` command does work for me

I also got gcloud working, but had to do a few extra things:

- moved all the contents of my vendor folder to the root of my $GOPATH
- deleted the vendor folder (may not be necessary)
- deleted all `vendor` folders under the just moved vendored folders (things like https://github.com/aws/aws-sdk-go/tree/master/vendor for example). My vendoring tool had already flattened the tree as much as possible

These steps allowed us to use `gcloud app deploy`.

Hope Steven gets the 1.10 update and the updated/fixed toolchain to us soon.

Any updates on when the issue is going to be fixed?

We're still targeting to have this fixed with Go 1.10, which means no earlier than two months from now

What's the status on this? go versions <= 1.8 are being deprecated on GAE, with no new deployments allowed after Nov. 1, but the `goapp` workaround doesn't work with version 1.9.

EDIT: nevermind, the goapp package has been updated to support 1.9.

I have no idea if this is helpful or not but I tested this small patch over go-app-stager, used by gcloud app deploy, and managed to get it working:

diff --git a/google-cloud-sdk/platform/google_appengine/goroot-1.9/src/cmd/go-app-stager/gas.go b/gas.go
index 0fa4f59..35b66f5 100644
--- a/google-cloud-sdk/platform/google_appengine/goroot-1.9/src/cmd/go-app-stager/gas.go
+++ b/gas.go
@@ -473,6 +473,11 @@ func bundle(dst, dstDepsDir string, deps []*build.Package) error {
        for _, pkg := range deps {
                dstDir := filepath.Join(dstDepsDir, pkg.ImportPath)
                srcDir := filepath.Join(pkg.SrcRoot, pkg.ImportPath)
+               if strings.Contains(dstDir, "/vendor/") {
+                       dstDir = strings.Split(dstDir, "/vendor/")[1]
+                       log.Printf("> Vendored package detected. Flattening to %v", dstDir)
+               }
+               log.Printf("> Staging package %v (srcDir=%v; dstDir=%v)", pkg.Name, srcDir, dstDir)
                if err := copyTree(dst, dstDir, srcDir, false); err != nil {
                        return fmt.Errorf("unable to copy directory %v to %v: %v", srcDir, dstDir, err)
                }

I know this is not the best solution but it works by "flattening" the vendored import into the destination folder (a/vendor/b -> b). This can be improved by a for loop to flatten deeper vendor trees (a/vendor/b/vendor/c -> c) but it was not my case.

How to test if this works for you (AT YOUR OWN RISK!):
1. Update your gcloud sdk to the newer version and install App Engine SDK (goapp) as well
2. Build the attached gas.go file with `goapp build -o go-app-stager gas.go`
3. Place the binary in the Google Cloud SDK folder $CLOUD_SDK_ROOT/platform/google_appengine/
4. Deploy from your app.yaml directory folder as usual with gcloud app deploy

You can revert the previous changes with gcloud components reinstall to get back to the previous SDK state.

Hope that helps, and sorry if this is a dummy broken solution.

Now that Go 1.11 on App Engine Standard has been released, we have native support for vendoring! That should fix this issue. I'm going to mark this as fixed. Please check out our Go 1.9->1.11 migration guide and try again: https://cloud.google.com/appengine/docs/standard/go111/go-differences

If you have any issues, please feel free to reopen this, or make a new bug.

Cheers!

Go 1.11, There are changes and deprecation of API, it takes time to migrate.

If Google continues to support 1.9, Google should fix this problem.

Is this so difficult?

na...@gmail.com, if it helps, the release documentation for Go 1.11 is misleading.

Regardless of deprecation, Go, unlike some other other 2nd gen runtimes, has the honor of keeping all of the old APIs.

We did some testing and apart from needing a re-write of app.yaml, you can pretty much deploy everything else as-is with no in-app changes, apart from pulling a new version of the supporting libraries.

> Go 1.11, There are changes and deprecation of API, it takes time to migrate.

As Sam says, the migration should be quite easy. Though we are advising customers move to the go cloud APIs, we still support the old App Engine APIs. Updating your dependencies and redeploying with `runtime: go111` will get you 95% of the way there.

> If Google continues to support 1.9, Google should fix this problem.
> Is this so difficult?

Due to some internal architectural differences between 1.9 and the new 1.11 runtime, this is actually rather difficult. All work improving the runtime will be focused on the new generation which starts with Go 1.11.

Thank you for replying.

> Go, unlike some other other 2nd gen runtimes, has the honor of keeping all of the old APIs.

Is it means that Go 1.11 has Search API and Images API?

If that, I will try to migrate to 1.11.

> Is it means that Go 1.11 has Search API and Images API?

Yes, Go 1.11 still has access to these APIs. You just need to import `google.golang.org/appengine` and call `appengine.Main()` in your main package.