Open lyricnz opened 11 months ago
We could make a weekly action that checks if an upstream Docker container exists with a newer version?
The update script already fails cleanly if we have the current version. While we could make a process to run this automatically, it has the potential of breaking things if the schemas change....
Will PR a change to actually download the dump file if it doesn't exist.
Perhaps it's better to make a GHA action that checks for an updated upstream image, and notifies (create an issue?) - rather than upgrading the image automatically. This would be safer.
~Maybe it could open a PR with the changes, but just opening the issue is probably enough~
I don't think there's actually any changes? We use :latest in all the automations, and there's already a GHA that builds and pushes the new image.
https://github.com/LukePrior/nbn-upgrade-map/blob/main/.github/workflows/publish-db-image.yml
My bad was getting confused, you're right
@LukePrior There's a new GNAF 202308 release. https://data.gov.au/dataset/ds-dga-19432f89-dc3a-4ef3-b943-5326ef1dbecc/details
It's already integrated in our upstream https://github.com/minus34/gnaf-loader/pull/81 but he hasn't created a release yet.
However the DB dump files etc that our Dockerfile uses are all there - so the build works if you explicitly set the GNAF_LOADER_TAG=202308
From the government data release: G-NAF Release Report August 2023.pdf
The release notes also mention addresses being tagged as "retired", and some "complex" addresses with duplicate address_string. Maybe we should look into that as part of our transformation/cut-down.
Rebuilding the image locally, and running a single suburb seems to work fine. A bunch of small differences in coordinates
Cool, will run GHA
And reprocess to create our cut-down version. https://github.com/LukePrior/nbn-upgrade-map/tree/main/extra/db
This doesn't happen very often - roughly quarterly https://data.gov.au/data/dataset/geocoded-national-address-file-g-naf