Upgrade Go version to support realworld sample

[sparkoo]

Description

According to #13529, we would like to have https://github.com/xesina/golang-echo-realworld-example-app as a Go sample project. There is an issue with Go versions as the project uses modules, thus needs Go v1.11+. However, our Che Go plugin uses v1.10.7.

Currently I can think of several options for us:

• use different project as a sample
• use some older version of the project
• update our Go version
• don't have big Go sample like this and be happy with simple sample (https://github.com/eclipse/che-devfile-registry/tree/master/devfiles/go)

We should decide what way to go and whether we want this in 7.0.0 GA

[tsmaeder]

So what is the issue that is happening? What does not work?

[benoitf]

@tsmaeder I think it's pretty well explained. it's using go modules that are not available in go 1.10 but 1.11 and afterwards
https://blog.golang.org/using-go-modules

[tsmaeder]

Yes, but what are the consequences? Does code assist not work? Do we have unexpected errors in the editor?

[sparkoo]

I'm not sure exactly. I guess project won't compile at all (https://travis-ci.org/xesina/golang-echo-realworld-example-app/builds/531131833?utm_source=github_status&utm_medium=notification).
AFAIK no work-in-progress devfile exists and I haven't tried it yet. I'm taking this over @metlos so this is just what I've already found out as a current state.

[l0rd]

Assuming that the project is not building at all.

For GA: we are happy with the simple sample that we already have
For 7.1.0: upgrading to latest go version

[sparkoo]

I was looking at this and I'm able to build and run the project with Go 1.10.7 with tasks. However, editor is not working correctly. No code assist, no 'go to definition', ... I guess that's because go plugin can't find the dependencies for the project as they are inside go-cli container:

When I set GOPATH to just CHE_PROJECTS_ROOT, the build task downloads dependencies there and theia will find it, but then it's failing when it tries to create /go folder when compiling. I believe this is because of plugin's GOPATH has /go first https://github.com/eclipse/che-plugin-registry/blob/master/v3/plugins/ms-vscode/go/0.11.0/meta.yaml#L20
Here's my current devfile:

---
apiVersion: 1.0.0
metadata:
  name: golang-realworld
projects:
-
  name: golang-realworld
  source: 
    type: git
    location: https://github.com/xesina/golang-echo-realworld-example-app
  clonePath: src/github.com/xesina/
components:
-
  type: chePlugin
  id: ms-vscode/go/latest
  alias: go-plugin
  memoryLimit: 512Mi
-
  type: dockerimage
  # this version is used in the plugin
  image: golang:1.10.7-stretch
  alias: go-cli
  command: ['sleep']
  args: ['infinity']
  env:
    - name: GOPATH
      # replicate the GOPATH from the plugin
      value: /go:$(CHE_PROJECTS_ROOT)
    - name: GOCACHE
      # replicate the GOCACHE from the plugin, even though the cache is not shared
      # between the two
      value: /tmp/.cache
    - name: PS1
      value: $(echo ${0})\\$
  memoryLimit: 512Mi
  mountSources: true
commands:
- name: build
  actions:
  - type: exec
    component: go-cli
    command: go get -d -v && go build -x -v
    workdir: ${CHE_PROJECTS_ROOT}/src/github.com/xesina/golang-echo-realworld-example-app
- name: run
  actions:
  - type: exec
    component: go-cli
    command: go get -d -v && go run main.go
    workdir: ${CHE_PROJECTS_ROOT}/src/github.com/xesina/golang-echo-realworld-example-app
- name: test
  actions:
  - type: exec
    component: go-cli
    command: go test
    workdir: ${CHE_PROJECTS_ROOT}/src/github.com/xesina/golang-echo-realworld-example-app

• so issue seems to be that I don't know how to set GOPATH properly so go-cli container can see it, as well as theia plugin. It might be fixable by swapping GOPATH value in plugin to value: $(CHE_PROJECTS_ROOT):/go, but I'm not sure and I don't know how to try that.
• at this point, should I create PR with current devfile and discuss these technical issues there?
• the second Go sample (https://github.com/eclipse/che-devfile-registry/blob/master/devfiles/go/devfile.yaml) behaves the same. It's using this project https://github.com/golang/example, but only it's outyet part, which is single file example with no dependencies, thus working ok. When I try to run different file with external dependencies (e.g. https://github.com/golang/example/blob/master/gotypes/doc/main.go), I'm meeting same issues.

(hope it does make sense)

[sparkoo]

cc @l0rd @skabashnyuk @tsmaeder

[tsmaeder]

@sparkoo could you file an issue describing the issue with the sample that we will ship with 7.0.0? In my mind, we can just fix it by setting the proper gopath values in the devfile.

[sparkoo]

@tsmaeder yep, #13823

[slemeur]

Downgrading to 7.3 as #13823 has been adressed

[tsmaeder]

So let's update to the newest go versions. We need to:

1. Verify that go-modules are compatible with older code (other module systems)
2. Do a test pass ensuring language features still work
3. Ensure all go-related devfiles and examples still work.

[tolusha]

This PR [1] is closed. We have to consider using a sample which contains front-end part as well as back-end. For instance go-guestbook [2]. It requires using side-car container with installed go v1.13

Observable issues:
#13080

[1] eclipse-che/che-devfile-registry#96
[2] https://github.com/GoogleCloudPlatform/cloud-code-samples/tree/master/golang/go-guestbook

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[ericwill]

This one is still relevant but low priority.

[benoitf]

using multiple workspace root I had no issue (here is experiment of last month) : https://gist.github.com/benoitf/57ffa7e39e2e16a6a2f6756a44693e43

[ericwill]

PR merged. Devfile tests will need to be updated to include the new task names cc @rhopp