feat: arm compatible build

[dnplkndll]

registry.gitlab.com/kencove/docker-whitelist/add-gitlab-ci:latest

here is an image for review.

[pedrobaeza]

All that poetry changes are needed for ARM compatibility? If not, please limit the PR to the minimum ones. If yes, please explain each of them.

[dnplkndll]

All that poetry changes are needed for ARM compatibility? If not, please limit the PR to the minimum ones. If yes, please explain each of them.

honestly just ran poetry update assuming you would want to use the newest allowed versions, safer? Are you suggesting to find the specific dependency dropping out any optional updates to just to know or as a best practice to not update them if possible?

I do not have a problem testing it and figuring out. If the time is useful. At the end of the day the multi build would still need run as well. looks like dropping changes to dev deps will reduce a lot of the lock diff.

https://gitlab.com/kencove/docker-whitelist/-/merge_requests/1/diffs#84d2fa6faad27f1828234360583f5ba9de3d2f15_0_10

[pedrobaeza]

My fear on this is that updating all the stack, any incompatibility arises, so I was betting for a controlled change. In general, it's good to update everything to the latest possible versions, but not assuring that this doesn't provoke any problem is risky.

For example, one question I have seeing the other files is why adding a new dependency (dnspython) and why the removal of one decorator (without replacement), or the change on one methods. Having located where these changes take place, with a commit message indicating that, it's useful and trustable.

[dnplkndll]

hoping:

Kencove@5a923d0

this is ok or should pre-commit packages be left in place if not causing a specific error?

[dnplkndll]

I think you are right and https://docs.python.org/3.10/library/asyncio-task.html#generator-based-coroutines
only that needs changed or as an alternative

FROM python:3-alpine

would need pinned to an old version it must be pulling ^3.11 if removed

[dnplkndll]

My fear on this is that updating all the stack, any incompatibility arises, so I was betting for a controlled change. In general, it's good to update everything to the latest possible versions, but not assuring that this doesn't provoke any problem is risky.

For example, one question I have seeing the other files is why adding a new dependency (dnspython) and why the removal of one decorator (without replacement), or the change on one methods. Having located where these changes take place, with a commit message indicating that, it's useful and trustable.

understood. #16 minimal change and running on a current build.

my motivation, to allow what looks like the only complex part on running https://github.com/Tecnativa/doodba on the M series arm chips for loco dev work, is this image in the copier template: https://github.com/Tecnativa/doodba-copier-template/blob/main/devel.yaml.jinja#L14C38-L14C38 ( fork, update, build, publish, update references in compose files ...)

I have not run into any other issues and might be nice to have that support out of the box? I mean more useful that RISC-V for now

Kencove#1 this is about as far as I could get with the test, on my account to run without approval. I would probably invest a little to get an arm arch to your specs here. But may have to hand off to @JordiBForgeFlow as I am not custom to using tests on GitHub.

well the gnu date to timestamp syntax if needed in scripts.

COMP=${COMP:-company}
if [[ "$OSTYPE" == "darwin"* ]]; then
    restore_date=${1:-$(date +%F)}
    restore_timestamp=$(date -j -f "%Y-%m-%d" "$restore_date" "+%s") || usage
    restore_db_name="$COMP_$restore_date"
else
    restore_date=${1:-now}
    restore_timestamp=$(date --date "$restore_date" +%s) || usage
    restore_db_name="$COMP_$(date --date @$restore_timestamp +%Y%m%d)"
fi

[pedrobaeza]

ARM support added in #17