Enable local testability

[apparle]

This PR enables the ability to build and test images locally. It does 2 things:

1. Updates the Dockerfile for mastercontainer to separate out the cloning step into its own stage, such that it can be overridden by user input to pick changes from local path with below command. This follows the principle described in https://www.docker.com/blog/dockerfiles-now-support-multiple-build-contexts/

cd Containers/mastercontainer
docker buildx build --build-context aio_root=../../ -t ghcr.io/nextcloud-releases/all-in-one:latest --load .

2. Since the hash of a locally built image will never match the latest image, mandating "Update mastercontainer" makes local testing impossible. This PR adds ability to skip the mastercontainer update. This also addresses allow to restart containers without updating mastercontainer, if a mastercontainer update is available #5468

[szaimen]

Hi @apparle thanks a lot for so many useful contributions! 😊

I just invited you to the repo to make collaboration easier :)

[szaimen]

btw this PR has some conflicts...

[apparle]

btw this PR has some conflicts...

Merged main and resolved conflicts. Also resolved lint issues.

[docjyJ]

I think it would be better to use an environment variable like SKIP_DOMAIN_VALIDATION=true

[apparle]

I think it would be better to use an environment variable like SKIP_DOMAIN_VALIDATION=true

But then it doesn't solve #5468 easily. It would be better to be able to skip the update temporarily rather than take everything down and restart with different env variables. (And then take it down again to remove the env variables when the reason-to-skip is resolved.)

[szaimen]

Hi, I would also prefer a solution that overwrites the behaviour via env variable for example. Adding this to the aio interface means that we also need to support and maintain it... Also sorry for taking so long to answer.

[apparle]

Hi, I would also prefer a solution that overwrites the behaviour via env variable for example. Adding this to the aio interface means that we also need to support and maintain it... Also sorry for taking so long to answer.

Are you suggesting removing the UI elements altogether and only using an environment variable?
Or are you suggesting to add environment variable in addition to the UI changes?

[docjyJ]

Are you suggesting removing the UI elements altogether and only using an environment variable? Or are you suggesting to add environment variable in addition to the UI changes?

I think it's about not using the UI. It should be minimalistic.

According #5468: I think a simple way is to add a button "restart without updating".

[docjyJ]

This is what it could look like. What do you think?

[szaimen]

This is what it could look like. What do you think?

I am not sure about adding such a button
to the UI honestly. I fear people will just always use that and refrain from updating and then run into update issues later on because they never updated 🙈

[docjyJ]

I am not sure about adding such a button
to the UI honestly. I fear people will just always use that and refrain from updating and then run into update issues later on because they never updated 🙈

The problem is that the containers created by the AIO are on the lastest tag. (apache, nextcloud postgress...)

But the ideal would be that the AIO uses the same version. It is impossible to downgrade to V8 or V9 because the containers will be created in the latest version (V10).

So if the containers are not on the same version, there will be bugs...

[apparle]

Above discussion is useful but I'm confused on the next step.
@szaimen are you convinced that we'll need some UI anyway to solve #5468 . If we add any UI, an environment variable will just add to the confusion on when is it overridden vs. not; might as well do it all through UI. Thoughts?

@docjyJ yes it could be as minimalistic as your example image in #5568 (comment) but I hesitate to make it that easy. I prefer it be a louder warning to deter users from using that unless they really know what they're doing. That's why the current design.

[apparle]

@szaimen Ping. Any thoughts on the last comment?

[apparle]

So I thought over this more and realized a better way to do this:
I dramatically simplified this by removing the UI element altogether, since we don't want normal users to skip the update ever. Only in the extreme cases, like local development/testing or #5468 should someone need to bypass the container update.
And for that purpose, an unadvertised URL parameter can be specified :

https://localhost:8080/containers

should be modified to

https://localhost:8080/containers?bypass_mastercontainer_update

With this change, the mastercontainer update is bypassed temporarily.
We can document this in FAQ, which most users aren't going to try until they're completely stuck and go looking for that in FAQ.

Is that a reasonable balance of usability and safe-enough-defaults ?

[apparle]

Ping again! I've simplified the implementation significantly. It is a very small change now, and also minimizes any UI/UX concerns.

[docjyJ]

Should work

[szaimen]

Hey, I am very sorry for taking so long to review this. Unfortunately I am still undecided regarding this change. I see the need for such a change but I think I still don't like the implementation, however I also don't have a good idea how to further improve this. So this is why I am currently stuck. Hope that makes things a bit clearer why it takes so long...