[GeoNode-devel] Practices on maintaining a geonode project, PR: "Align to GeoNode master 4.2.0"

[Toni Schönbuchner]

Dear Giovanni,

this sounds like a great idea.
As you saying this will not solve all problems on updating like in case one needs to change or extend settings.py
However. The .env file might be a good starting point.

There is something similar for docker:
https://github.com/Rillke/Docker-env-file-update/tree/master <https://github.com/Rillke/Docker-env-file-update/tree/master>

Some time ago I’ve translated the provided bash script to python that I can share:
https://gist.github.com/t-book/bfeaaa3b550558797b3c16567f8a5c88 <https://gist.github.com/t-book/bfeaaa3b550558797b3c16567f8a5c88>


Given a fresh .env_template like

# This is a comment that should be copied as is
# This is a comment that should be copied as is
# This is a comment that should be copied as is


COMPOSE_PROJECT_NAME=geonode
DOCKERHOST=123.123.124
DOCKER_HOST_IP=
# See https://github.com/containers/podman/issues/13889
# DOCKER_BUILDKIT=0
DOCKER_ENV=production
ALLOWED_HOSTS=["*“]

A custom_local_env like:

COMPOSE_PROJECT_NAME=geonode
DOCKERHOST=
# See https://github.com/containers/podman/issues/13889
ALLOWED_HOSTS=["localhost", "127.0.0.1“]
NOT_IN_TEMPLATE=ABC


The generated output would be

# This is a comment that should be copied as is
# This is a comment that should be copied as is
# This is a comment that should be copied as is


COMPOSE_PROJECT_NAME=geonode

# Updated by tonischonbuchner on 2023-08-08 09:36:41
DOCKERHOST=123.123.124

# Added by tonischonbuchner on 2023-08-08 09:36:42
DOCKER_HOST_IP=
# See https://github.com/containers/podman/issues/13889

# Added by tonischonbuchner on 2023-08-08 09:36:42
# DOCKER_BUILDKIT=0

# Added by tonischonbuchner on 2023-08-08 09:36:44
DOCKER_ENV=production

# Updated by tonischonbuchner on 2023-08-08 09:36:45
ALLOWED_HOSTS=["localhost", "127.0.0.1"]


Where the script 
Creates a new env file based on both files
Copies lines that do not exist in local file but in the template file as is
If the var exists in both, it asks to update the value from template to local
Leaves a comment on changed or added lines 
What is missing is handling vars that exist in the local file but not in the template.
Currently the script informs but does not copy them (should be easy to change).

This is far from perfect, not once battled tested and more of a POC.
But maybe can help others to build upon.

Best regards

Toni


>   1. Re: Practices on maintaining a geonode project, PR: "Align to
>      GeoNode master 4.2.0" (Giovanni Allegri)
> 
> Von: Giovanni Allegri <giovanni.allegri at geosolutionsgroup.com>
> Betreff: Aw: [GeoNode-devel] Practices on maintaining a geonode project, PR: "Align to GeoNode master 4.2.0"
> Datum: 7. August 2023 um 14:31:46 MESZ
> An: Florian Hoedt <florian.hoedt at thuenen.de>
> Kopie: Toni Schönbuchner <toni.schoenbuchner at csgis.de>, geonode-devel <geonode-devel at lists.osgeo.org>
> 
> 
> Thanks for raising this point, and for sharing your solutions.
> 
> Keeping a project aligned to GeoNode (and the GeoNode-project itself) can be really troublesome. We also don't have a one-fits-all solution.
> 
> The idea of the create_env.py command was to start creating a set of utilities to help with the creation and the upgrade of downstream projects. It was only the first step, and the PR from Alessio improves it.
> The next step wanted to be a utility that could track changes and guide the user in the procedure of updating an existing project, starting from the .env file which is the principal target of most of the changes.
> A very rough idea would be:
> 
> when a new project is created the commit for the geonode-project template is written to the .env file by the create_env.py utility
> the upgrade utility retrieves the commit 
> it compares the .env.sample commit with the target branch to which you want to upgrade the project
> it tries to extend the current .env file with any new env var, and marks them with a specific comment (similar to the fuzzy translation strings)
> any var in the existing .env file that doesn't match the new .env.sample will be marked with a specific comment
> The same utility could generate the list of changed files between the original commit and the target branch.
> 
> I'm aware that this doesn't solve all the issues, but it would help a lot. What do you think?
> Hey, I'm not saying that we will do it! :) That would be a nice feature, but at the moment we don't have plans for it.
> 
> Giovanni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geonode-devel/attachments/20230808/11aa0f6f/attachment.htm>