Auto sync with docker-library/php

[Slamdunk]

It seems to me that this repo isn't automatically triggered/synced with https://github.com/docker-library/php the source docker repo that this library relies on.

For example 15 days ago (20 ago 2018) PHP 7.1.21 was tagged in that repo:
docker-library/php@74b59e1

Bug as of yet chialab/php:7.1 still exposes PHP 7.1.19

[fquffio]

Ciao @Slamdunk !
Yes, you are right. 😞 However I have actually problems figuring out which is the right way to solve this problem. I'm providing a little background to explain my confusion, with the hope that somebody might help me.

TL;DR As of now images are built on Docker's infrastructure every time a push happens on master using Docker's automated builds. Maybe the best option is to build the images on Travis and push them to Docker Registry, and to enable daily builds on master.

---

When this project started, automated builds happened on hub.docker.com, and there we had the option to "link" this repository to php images, so that every time an image was pushed to that repository a rebuild was being triggered on ours. This did the job, but since often N images (N > 1) were being pushed at once on the php base images, this triggered N identical rebuilds. If we have M active tags on chialab/php, this means that N * M build tasks were executed.

Also, since chialab/php-dev was linked to chialab/php in the same way chialab/php was linked to php, every time N images were being pushed to php this caused N * M build tasks on chialab/php that consequently caused N * M^2 build tasks on chialab/php-dev. Despite this happened on Docker's infrastructure, not mine, it seemed a bit a waste of resources and it would have been a little irresponsible of me to ignore it.

Recently (although not that recently) cloud.docker.com was released. It's not very clear to me the relationship between cloud.docker.com and hub.docker.com, whether the first is meant to eventually supersede the latter or not, but I decided to move all the build process to cloud.docker.com, so now builds happen there. Since the registry is the same, built images and tags are still visible from both places, so this is mostly an "implementation detail". However, cloud.docker.com doesn't have the option to link repositories in the way I described above. So right now builds happen only when commits are pushed to master branch of this repo, which is clearly insufficient as you pointed out.

Possible solutions that pop into my mind:

• I'd like to use an event-based approach, but as far as I investigated there's no way to do this without admin rights to php image on Docker Registry or to docker-library/php repository on GitHub. So this is not an option.
• Use Travis to send a POST request to cloud.docker.com webhooks to rebuild the images on a daily/weekly basis. This is a suboptimal time-based approach that would still trigger more build tasks than actually needed, so some extra care should be taken: if layers of php:TAG are a subset of the layers of current chialab/php:TAG, there's no need to rebuild that tag.
• Forget about hub.docker.com and cloud.docker.com and simply build images on Travis on a daily/weekly basis. This would likely speed up build times, reduce the overall amount of OSS-dedicated resources (Travis usage would remain the same, Docker's infrastructure usage would decrease) and give us more flexibility. On the other hand the "automated build" badge would be lost (but does anybody actually care? 🤔 ) and still it would be a time-based approach instead of an event-based approach.
• Use another third-party service (AWS Lambda?) to query GitHub's or Docker's APIs maybe once per hour to selectively trigger rebuilds.

Sorry if my comment is a bit long to read, but I can't make up a decision on this. Please feel free to give me an opinion on this subject! 😉

[fquffio]

Also, building images on Travis would make easier to achieve the solution described in #33, as well as make refactoring described in #23 possible.

[Slamdunk]

Despite this happened on Docker's infrastructure, not mine, it seemed a bit a waste of resources and it would have been a little irresponsible of me to ignore it.

Of course 👍 energy for Docker infrastructure comes from the Earth that we all needs, better lower as much as possible our impact

I have no experience in building docker images on Travis, so I would not switch away from hub.docker.com on-site building; but it's up to you.

A non-perfect and non-clearest but effective solution would be to add a Travis weekly cron that:

1. Gets the latest commit from https://github.com/docker-library/php/commits/master (further reading: https://developer.github.com/v3/repos/commits/#get-the-sha-1-of-a-commit-reference)
2. If it is the same that the one saved in (a new file called) .latest-php-build do nothing
3. Otherwise save the new commit hash in that file
4. Commit it (with dedicated API credential stored in Travis as secure variable) and push it to master from Travis

Some notes:

1. The travis builds can be identified by the env TRAVIS_EVENT_TYPE (see here)
2. The eventual push would trigger all the chialab images, but that's a compromise
3. This solution would ignore Tag Versioning #33

[Slamdunk]

I solved this issue by adding a build trigger url in cloud.docker.com and calling it in a weekly build:

https://github.com/Slamdunk/docker-php/blob/510b5c97d27606fc90ff1d3297121f1f1a1a6c2b/.travis.yml#L1-L3

https://cloud.docker.com/repository/docker/zoeslam/php-mysql/builds/edit

https://travis-ci.org/Slamdunk/docker-php/settings

Remember to turn OFF auto build for the brand having the point .travis.yml, otherwise docker would receive too many useless triggers

[le0m]

In the end Docker went full circle: Hub --> Cloud --> Hub.

I found this and other issues relating to this one. It turns out that "Repository Link" is now disabled for base images because that would trigger a huge amount of automatic builds (think about how many images are based on official ones).
Right now we're relying on Travis to deploy images to Docker Hub and we also have a weekly cron-build there. I think it's the best approach we can have, so I'm closing this.