Move how-to to the example repository

[kjappelbaum]

I think that for the future it will be easier if the end user only pulls tools-barebone from Dockerhub and does not need to visit this repo (which should also have some CI that the build works). This will make it a bit easier to debug the app before deployment. I would also highlight the python==3.5 'limitation' a bit more prominently (an issue e.g. with f-strings).

I suggest to move the How-to to the example repository and explain there also how to setup some github actions to check that the build of the container works.
Probably, it would be also good to have some cookiecutter (as suggested in #3) that helps in setting everything up (steps 2 and 3 of the current How-To) - at least i found it relatively useful for the discover section.

Referencing @ltalirz for notice, as we discussed this briefly.

[ltalirz]

the python==3.5 'limitation'

I think the latest versions of phusion passenger-customizable support python 3.6.
I guess we should simply upgrade?

I suggest to move the How-to to the example repository

It would definitely make sense to move it to the reamde of a "cookiecutter" recipe.
Moving it to the readme of an example is perhaps not ideal, since the readme of the example (=the output of the cookiecutter) should ideally be a description of the example application.

and explain there also how to setup some github actions to check that the build of the container works.

The nice thing about github actions is that it is enabled automatically.
I.e., while it is always good to explain how things work, one can actually ship the example with a github action that simply does a "curl" to the proper port and prints the docker logs in case it receives an http error, and it can simply "work out of the box".

[ltalirz]

build now available on dockerhub:
https://hub.docker.com/repository/docker/materialscloud/tools-barebone/general

I'd say one can now proceed with this, letting the example repo pull directly from dockerhub

[kjappelbaum]

nice! do you want to also have an action for publishing it on dockerhub (https://github.com/marketplace/actions/publish-docker)?

[ltalirz]

For the moment it's done the other way around - dockerhub is building on the master.
I have to say, though, that the dockerhub web site is extremely unreliable in terms of configuring builds - I've had lots of issues being unable to find repos / unable to modify build rules / ...

Eventually I'd prefer to do things the other way around - I guess this means we would need to create a "bot" account on dockerhub (they don't have an API token mechanism, do they?)

[kjappelbaum]

Eventually I'd prefer to do things the other way around - I guess this means we would need to create a "bot" account on dockerhub (they don't have an API token mechanism, do they?)

I think they have
https://www.docker.com/blog/docker-hub-new-personal-access-tokens/

[ltalirz]

Ok, cool - I just looked at the action you posted and it didn't seem to support this. Is there one that does?

I also notice that these seem to be unscoped tokens, i.e. a leak of a token is as bad as a leak of your username and password. Anyhow, you can have multiple of them and revoke them more easily.

[kjappelbaum]

works with the token as far as I know. The documentation also says password the authentication token [preferred] or login password for the registry.

[ltalirz]

Thanks, I should have looked more closely.

I've added the needed secrets to the repo - great if you can add the action.

I guess it should only trigger on the merge of the PR - then we'll see whether it works (I'll disable the automatic trigger from dockerhub before)

[giovannipizzi]

According to the discussions above, for now we will keep the docs here, and not in the example repo or in the cookiecutter (to be yet done, see #15).

DockerHub automation was already added in #8, now in v1.0 it is not pushed anymore from GitHub actions but it is build by DockerHub itself.
So I'm closing this for now.