Auto sync with docker-library/php
Closed this issue ยท 5 comments
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
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 todocker-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 currentchialab/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! ๐
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:
- 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)
- If it is the same that the one saved in (a new file called)
.latest-php-build
do nothing - Otherwise save the new commit hash in that file
- Commit it (with dedicated API credential stored in Travis as secure variable) and push it to master from Travis
Some notes:
I solved this issue by adding a build trigger url in cloud.docker.com and calling it in a weekly build:
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
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.