Yangster image should be up-to-date on docker hub about yangster HOT 16 CLOSED

The auto-build on docker-hub still points to the old repository location.
This is why it is so out-of-date.

from yangster.

From what I understand, we can configure the hub to automatically build on code changes, https://docs.docker.com/docker-hub/builds/, and from what I've seen in other docker projects, they usually have a tagged "released" image and a "next" or "latest" image which is based on the current master. I think it would be a good idea to have this.

from yangster.

Just to clarify:

latest = latest released version
next = latest commit

from yangster.

I think we could have a travis ci job that on (commit-to-master) would push to the "next" tag. However for the "latest" tag I'm not sure how to do it automatically, I was thinking maybe we could have a job that we trigger manually that would push a docker image for a certain commit id.

from yangster.

Yes actually I think we should have the following procedure:

• Changes all the extensions version to version x
• Commits that change to master
• tags master with version x
• Runs that through CI
• Builds docker image with CI
• Test docker image on CI

If CI is OK:

Have a script that:

• Publishes to npm (by doing a git clone of the git tag and publishing
• the result)
• Publishes docker image based on git the new git-tag

This should be the same for theia.

from yangster.

As of right now is yangster on npm?

from yangster.

npm ERR! 404 Registry returned 404 for GET on https://registry.npmjs.org/yangster
npm ERR! 404
npm ERR! 404 'yangster' is not in the npm registry.
nope

from yangster.

theia-yang-extension is not either

from yangster.

neither is yang-sprotty, theia-sprotty.

from yangster.

I have published the npm packages.

from yangster.

As of right now does the auto-build push a new dockerfile on new commits to master?

from yangster.

Yes, it does, but it listens to the old repo. I have just created a new build with the new repo. It's building now, should take a while...

We could also make it rebuild when tag names match a given regexp.

from yangster.

@JanKoehnlein thanks for fixing the automated build.

Yes according to the dockerhub documentation it looks pretty flexible with regexp. The thing is there's no release cycle yet afaik, i.e which numbers should we give to releases, when to release etc.

from yangster.

The main problem is that yangster and yang-eclipse depend on yang-lsp, i.e. the respective builds consume its built artifacts. All of them can have different version numbers.

So this is what I got working and what I feel is good enough for now:
On Jenkins:

• a successful build of yang-lsp triggers the rebuild of yangster and yang-eclipse

On Dockerhub:

• a commit to yangster/master triggers the build of a Docker image yangster/latest
• adding a version tag on yangster triggers the build of a Docker image yangster/release-{tag}

Dockerhub's automatic builds directly listen to Github, so this was the easiest way. The backside is that we don't get a new Docker image when we just change the language server. If we want to build the Docker image based on the Jenkins job, we'd have to do that ourselves and upload it to dockerhub afterwards.

For publishing to npm and jcenter, I still prefer a manual process.

from yangster.

Just a comment about naming.

Could we align this with npm naming scheme for theia and have:

Master creating a docker image with yangster/next
Latest release to yangster/release-{tatest tag}
Release to yangster/release-{tag} ?

from yangster.

I doubt we are going to maintain multiple versions of yangster at the same time (at least not in the near future), so I switched the naming from latest to next and added an extra build for release-latest.

from yangster.