search

pgRouting / docker-pgrouting

Docker for pgRouting
https://hub.docker.com/repository/docker/pgrouting/pgrouting
GNU General Public License v2.0
66 stars 34 forks source link

Automatic builds for 3.0.0-dev #4

Open cvvergara opened 5 years ago

cvvergara commented 5 years ago

How are changes to 3.0.0-dev being handled? Because almost everyday there is a PR

@dkastl says

There should be a way to automate this, but I had to study a bit how to set this up. Anyone knows how to do? https://docs.docker.com/docker-hub/github/#github-organizations

cayetanobv commented 5 years ago

@dkastl @cvvergara Yes, there is a way. We can do this using build triggers so we can run our automated builds by sending a POST request to DockerHub API. I have already activated "Build Triggers" in our pgrouting Docker repository and we have a Token to use for this purpose. We can call Docker API from TravisCI.

I explain you how it works this API with several examples:

# Trigger all tags/branchs for this automated build.
$ curl -H "Content-Type: application/json" --data '{"build": true}' -X POST https://registry.hub.docker.com/u/pgrouting/pgrouting/trigger/{here-we-include-our-token}/

# Trigger by docker tag name
$ curl -H "Content-Type: application/json" --data '{"docker_tag": "master"}' -X POST https://registry.hub.docker.com/u/pgrouting/pgrouting/trigger/{here-we-include-our-token}/

# Trigger by Source branch named staging
$ curl -H "Content-Type: application/json" --data '{"source_type": "Branch", "source_name": "staging"}' -X POST https://registry.hub.docker.com/u/pgrouting/pgrouting/trigger/{here-we-include-our-token}/

# Trigger by Source tag named v1.1
$ curl -H "Content-Type: application/json" --data '{"source_type": "Tag", "source_name": "v1.1"}' -X POST https://registry.hub.docker.com/u/pgrouting/pgrouting/trigger/{here-we-include-our-token}/
dkastl commented 5 years ago

Now the remaining question is: do we want to build a new docker image version (and tag?) with every commit to the develop branch?

What's the benefit? Who would benefit? Is there demand for this? Would someone use it actually, or do we just do it, because we can do it ;-)

I think CI could be a reason, but we are already using Travis for that. If there is no reason to do automated builds that frequently, then we could still try to automate the whole process, but maybe we should only do this then for tagged releases.

cayetanobv commented 5 years ago

This is a very good question :-) We can do that but I don't know what people wants. People always can build locally images clonning Github repository instead of download prebuilded images from Docker hub. Anyway, the main goal of docker-pgrouting "subproject" is to mantain images for each release. Maybe we can announce in dev or users email list this new initiative and ask to community about possibilities for "develop" branch and automated builds.

dkastl commented 5 years ago

15 seems to be related.

dkastl commented 4 years ago

@cayetanobv , has this issue been eventually resolved already?

cayetanobv commented 4 years ago

When we merge master branch of this repository (docker-pgrouting) all builds are launched. If we want in the future to automate builds with each merge of master (or develop) branch at pgrouting main repository we probably need to move this repository as a folder inside pgrouting repository.