code-server-golang

[n-i-x]

I've created a golang mod for code-server that I'd like to send a PR for.

Please create a new branch for me to send you a PR.

My repo is located at https://github.com/n-i-x/codeserver-golang-mod and currently published to nixapps/codeserver-golang:latest

There seems to be a code-server bug where the initial terminal doesn't have its PATH set properly, but opening a new one does so I'm not sure what to do about that aside from opening up an issue with code-server.

[n-i-x]

Created coder/code-server#1585 for the code-server PATH issue.

[aptalca]

Thanks, for the work. It looks good. However, since it's just a binary, wouldn't it be better to grab the binary in the docker file and inject it rather downloading it during container start? That way, we could push versioned mod images onto docker hub and users can define the version as a tag.

See how we did it for powershell here: https://github.com/linuxserver/docker-mods/blob/code-server-powershell/Dockerfile

And travis pushes versioned images here: https://github.com/linuxserver/docker-mods/blob/code-server-powershell/.travis.yml#L29-L37

We use a jenkins trigger that monitors the upstream releases and can trigger a travis build with the upstream version

Also with regards to the PATH issue, I can't reproduce it here. I open a new browser window, open code server and in the terminal that is open I do echo $PATH and get /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
I do have my default shell set to bash if that matters

[jrebey]

It's a tarball with an entire golang install... but I see what you're saying and I think it could still work.

How would the Jenkins trigger work? You'd trigger off the github source release and have it download the prebuilt binary from dl.google.com? Google doesn't publish the binaries to github but if Travis/Jenkins are passing in the github release version as like ARG PS_VERSION then I can just download it from the right place and extract it on container start (if it hasn't been extracted yet).

As far as the PATH issue, yes that the right path by default. But I'm adding /usr/local/go/bin to the path in the install script of the golang mod but it's not available in the first terminal. If you open up another terminal it'll be there. I'm not sure why that happens and I'm still looking into it. I'm not sure if it's a docker image issue or a code-server issue yet. Maybe you can help me understand what #!/usr/bin/with-contenv bash does.. I'm assuming it's some sort of wrapper to pass the docker envs to bash? Is there a way to publish an env back to that script to make sure exported variables stick?

[jrebey]

I should have just looked at the travis yaml... okay yea.. I can make this work just in the Dockerfile and a simple extract script.

[jrebey]

One question though, how would we handle the different version tracks?

Golang still maintains the 1.12 1.13 and 1.14 versions and we wouldn't really want a :latest tag in the mod to flip users who have been working in golang 1.14 down to 1.12 if they release a new 1.12 update after 1.14 simply because it's the last release in github.

Ideally we'd have tags like so:
v1.14.2: [1.14.2] [1.14] [latest]
v1.14.1: [1.14.1]
v1.13.10: [1.13.10] [1.13]
v1.13.0: [1.13.9]
...

The major.minor tag will track the latest release of that major.minor version. latest will always track the newest version of golang. I'm not sure how that would work in your setup, I've seen it done for other images though so I'm certain it's possible.

[aptalca]

Yes, the #!/usr/bin/with-contenv bash does exactly that, allow the service access to system env vars, it's an s6 supervisor wrapper.

For PATH, try placing your new PATH export into the service run file and see if that fixes it (make sure to use export PATH=blahblah). If so, in your mod, you can do an init file with a sed for the service file to inject your PATH export blurb in.

With regards to versioning, yes, we can do tags for major.minor with a simple edit to travis yml. Not sure if we can do latest automatically, though, unless golang somehow labels latest a certain way so the code can ascertain. Let me look into it and I'll let you know.

Jenkins trigger will do hourly checks for new versions and if there is one, it will fire off a new build with the build arg for version.

[n-i-x]

So I've been looking at trying to get the latest release from the github API and it appears that the golang/go repo is not behaving like a regular repo.

For example, in Powershell this works:
https://api.github.com/repos/PowerShell/PowerShell/releases/latest

This doesn't work for the golang repo:
https://api.github.com/repos/golang/go/releases/latest

Looking at all the releases:
https://api.github.com/repos/golang/go/releases

The API returns an empty list. I'm not sure how Jenkins triggers work. If you can use regular shell scripts to output a version then that would work... but if it relies on the github API and those API endpoints I'm not sure it'll work.

I've updated my repo to use Docker build args for the version as suggested. I'm still playing with the PATH issue. I got it working by adding the PATH to the code-server/run file and am just verifying it all with fresh clean images before I commit that.

[n-i-x]

PATH issue has been fixed and I've updated my repo https://github.com/n-i-x/codeserver-golang-mod and published my mod to nixapps/codeserver-golang:latest

Give it a try and let me know how I should proceed.

[aptalca]

Apologies for the radio silence. I got sidetracked with other projects.

I'll look into this later today and figure it out

EDIT: Took a quick glance at the downloads website and the git tags and here's a draft proposal:
Have a jenkins trigger check the latest git tag and if there is no current image with that tag, trigger a new build on travis with the version number.
Travis can build that version and tag it with the full version (1.14.2), as well as the major/minor versions (1 & 1.14).
Travis can also have a mechanism in which it compares that version to the latest version advertised on the website and if it's a match, it will tag as latest as well.

The only part I'm concerned with (long term concern) is I don't know the order in which the devs update the website and the git tags. If they're about the same time, it should work fine. But if there is a long delay between git tag and the website update, a new latest build may be missing the latest tag. Perhaps we do the comparison with the minor release number as opposed to the full tag. Then the issue would only crop up when 1.15 is released, which we can fix manually then by pushing another build after the website is updated.

Thoughts? @n-i-x

[aptalca]

Played around a little more and unfortunately, the tags on github are not returned through any api commands I tried. Only the weekly tags from back in 2012 are returned. The original git repo on google's website also doesn't seem to have any sort of api (I couldn't find one). So I looked into grabbing all releases from the website instead. Here are some curl/grep commands I put together to retrieve them:

latest stable amd64 version (featured):
curl -sX GET https://golang.org/dl/ | grep -o 'downloadBox" href=".*linux-amd64.tar.gz">' | grep -oP '(?<=go/go).*(?=.linux)'

latest 1.14 version:
curl -sX GET https://golang.org/dl/ | grep -o 'download" href=".*linux-amd64.tar.gz">' | grep -oP '(?<=go/go).*(?=.linux)' | grep -m 1 ^1.14

latest 1.13 version:
curl -sX GET https://golang.org/dl/ | grep -o 'download" href=".*linux-amd64.tar.gz">' | grep -oP '(?<=go/go).*(?=.linux)' | grep -m 1 ^1.13

and this will retrieve the latest release (stable or not):
curl -sX GET https://golang.org/dl/ | grep -o 'download" href=".*linux-amd64.tar.gz">' | grep -oP -m 1 '(?<=go/go).*(?=.linux)'

I'll put them into a version check and trigger script

[n-i-x]

Yep, that's what I found out as well. I wanted to use the git tags/releases in my download script and ended up resorting to parsing the latest amd64 download if the GO_VERSION build arg isn't specified. I went a little more specific in my regex to only match digits.. but this stuff is usually templated from Google so I doubt the regexes will stop working unless there is a complete refresh of the site.

I'm glad travis/jenkins is able to trigger off a regular script to make this possible. Tracking the supported versions will be useful to people as not everyone works on projects using the latest go versions.

[aptalca]

got the travis.yml working to push major/minor/patch tags: https://hub.docker.com/r/aptalca/mods/tags

I'll get the jenkins trigger sorted shortly

[jrebey]

Looks good.. were you able to figure out how to target a specific version or the latest for that track?

Latest 1.13: 1.13 1.13.10
Previous 1.13: 1.13.9

So the "1.13" tag moves to the latest 1.13 release. So if you want to track Go 1.13 you just use :1.13 and you'll always have the latest release but if you need to do a test or your project is tied to a very specific go version you can still use the 1.13.9 tag? I'm pretty sure if you apply an existing tag to a newer release docker hub does the right thing so you'd just need to apply the major.minor.patch tag and the major.minor version tag to each release.

[aptalca]

yes, you can use the tags 1, 1.13 or 1.13.9
1 will get you the latest 1.X.X currently 1.14.2
1.13 will get you the latest 1.13.X currently 1.13.10
etc.

EDIT: Well, since all mods are published at the same repo, the tags are technically prefixed with code-server-golang- so once published, you'll be able to pull in linuxserver/mods:code-server-golang-1.X.X, linuxserver/mods:code-server-golang-1.X, linuxserver/mods:code-server-golang-1 or linuxserver/mods:code-server-golang for the latest stable

[jrebey]

That's perfect!

[aptalca]

Ugh, great. Right after I pushed my final draft, I realized they don't exactly follow major minor patch format for their releases as they released 1.14 and 1.13 in the past so there will most likely be a 1.15 and my current algorithm won't be able to figure it out.

Anyways, it's here for now: https://github.com/linuxserver/docker-mods/tree/code-server-golang-dev

[aptalca]

Alright, fixed it. It will push 1.14 tagged as 1.14.0 as seen here: https://hub.docker.com/r/aptalca/mods/tags

[aptalca]

@n-i-x thanks for your work. It is merged and the mod is pushed to the hub. I manually triggered builds for the latest of 1.14, 1.13, 1.12 and 1.11. From now on, it will build all new releases automatically. The jenkins trigger will check daily: https://ci.linuxserver.io/job/External-Triggers/job/code-server-golang-external-trigger/

Don't forget, you're the maintainer for this mod 😁

[n-i-x]

Awesome! Thanks for your help! I use code-server with go daily so no problems :)

At least now I can just send PRs.

[aptalca]

@n-i-x discovered another issue. When go publishes releases, it does them all at once. But our trigger only checks the latest one. So 3 days ago, it picked up 1.14.3, but not 1.13.11 because they were releases at the same time. I'll have to adjust the trigger to check the last 3 releases or something like that.

[aptalca]

Alright, I updated the daily trigger so it checks the latest 3 versions released against the built images. As long as go releases no more than 3 versions in a 24 hour period, we're good. If they do, I'll increase it. Let's keep an eye on it.

[aptalca]

just add a new environment variable