Rename init script to 10_postgis.sh, update make -j

postgis / docker-postgis

Docker image for PostGIS

https://hub.docker.com/r/postgis/postgis/

MIT License

1.37k stars 462 forks source link

Rename init script to 10_postgis.sh, update make -j #182

Closed nyurik closed 4 years ago

nyurik commented 4 years ago

In order to make derived docker images more predictable, rename all /docker-entrypoint-initdb.d/postgis.sh to 10_postgis.sh. This way if the derived image needs to run something after (or before) 10_postig.sh, it can do so by naming new script with correct number.
Running make update also updated alpine/Dockerfiles with make -j$(nproc) Probably because previous commits didn't run update?

phillipross commented 4 years ago

@nyurik Your 2nd bulletpoint is correct. I have work-in-progress changes to the Makefile in a workspace for CI tasks at the moment. I pulled out the changes to the the alpine template into a separate PR and merged that without actually committing any of the updated Dockerfiles.

We're really behind on documentation at the moment, but the current idea is that the first step to building is running the update script which generates the content for the Dockerfiles in the subdirectories. Making changes directly to those Dockerfiles isn't something anybody should be doing since they'll be overwritten, so it's not entirely necessary that they're in-sync with the templates. Their existence IS necessary, however, as there are some rules in the Makefile that use the existence of the files as checks to see whether alpine variants should be included when processing some of the rules. It's a little messy and under documented at the moment, but not broken 😉

nyurik commented 4 years ago

@phillipross thx, I think the best way to handle that is for the CI to reject the PR if running make update would create a dirty state. So just add a simple travisci to the docker with if [ ! -z "$(git status --porcelain)" ]; then echo "not updated"; exit 1; fi docs

This will ensure that master is always in a "good" state.

phillipross commented 4 years ago

@nyurik I like this idea, but I wonder if there would eventually be times when a non-clean workspace would be legitimate 🤔

This PR looks good to me so far. Is there more work to be done or is it ready to be merged?

nyurik commented 4 years ago

yep, ready to merge.

Non clean workplace is evil -- it should use dedicated build dirs instead (that are .gitignore-ed) :)