Push to Docker Hub on merges to master?

[blueyed]

I think we should make Travis push image updates automatically on merges, and not do it manually.

[blueyed]

If we also host e.g. ubuntu-vims on the Docker Hub repo, we could have automated builds for Vim master then (https://hub.docker.com/add/automated-build/testbed/).
In this case there should be probably a separate image for the moving target(s), to keep the image with the tagged/stable versions unchanged?!

[tweekmonster]

Hmm, it seems that I can't setup automated builds for the DH org. I can't figure out how to link a GH account to the DH org, and even if I did, it would have to be linked to my GH account which isn't ideal. A GH org might be needed as well.

Am I missing something?

[blueyed]

A GH org might be needed as well.

Probably that would be the best.

OTOH we basically only need a user and could do it from Travis then - without linking the services explicitly. Not sure if that's the best way though.

Not really a pressing issue also, just something for the future.

[tweekmonster]

OTOH we basically only need a user and could do it from Travis then

Ah, I get it now. Have Travis push to the DH repo after a successful run using encrypted env vars. I was getting mixed up between DH vs GH vs Travis service responsibilities.

So, we would really just need a bot account on DH that would login from Travis. This is what I'm reading to draw this conclusion: https://sebest.github.io/post/using-travis-ci-to-build-docker-images/

[tweekmonster]

Also, I don't know what org to use on GH that would sound canonical since testbed is already taken. Neomake sounds better than my org esdf-io, but isn't exactly testing-related. Maybe @mhinz would be alright with this being under vimmer-net since he seems to have an interest in building a community (and building Vim/Neovim in containers 😉 ).

[blueyed]

FWIW, https://hub.docker.com/r/testbed/vim is used by now, but still only manually.

What would be required is setting up pushing from GitHub Actions, after #78.

It could get triggered when a tag (or release) is created, and then either map / use the Git tag to / as $(TAG) in the Makefile, potentially removing it there.
I think not every merge to master should (re)build the image (which would be for the same tag, and overwrite it then).