Use docker entrypoint.sh as a mean to run CI with variables to activate tests

[gustavovalverde]

To reduce the dependency on the tools being used to deploy, their parsing issues or availability to run commands to start the container, a good approach could be to use an entrypoint that captures different possible scenarios to run tests or any other commands expected by zebra.

An example is shown here: 6ae180b

This was a needed change as the GCP parser was not allowing -- as a single argument for docker to run the container, which required the container to reach the deployment server with this command already built-in, but not as the "standard" or only way to run it.

My proposal would be to include different variables that would run specific prebuilt cargo commands, as the one shown in the previous example.

Other projects commonly use this kind of approach.

This is one I created a few years ago, which was very practical to dynamically change the application configuration file on the fly, while starting the container, just by providing the required Environment Variables: https://github.com/iterativo-git/dockerdoo/blob/14.0/resources/entrypoint.sh

[teor2345]

Will this also make it easier for developers to run tests locally?

I really like this idea, seems like it's worth doing gradually as we change the tests.
(Maybe we could try it as part of the lightwalletd integration tests?)

[gustavovalverde]

For example:

To run full sync

RUN_TESTS=1 TEST_FULL_SYNC=1 docker run <test-image>

To run all tests

RUN_TESTS=1 TEST_ALL=1 docker run <test-image>

To run, both, sync_large_checkpoints_ and with_fake_activation_heights (one after the other)

RUN_TESTS=1 TEST_EMPTY_SYNC=1 TEST_FAKE_ACT_HEIGHTS=1 docker run <test-image>

[teor2345]

We should be careful we don't duplicate the functionality of the existing Rust test harnesses.

There are already runtime environmental variables for a lot of the tests. If we re-use them, the entrypoint won't have to do much at all.

[gustavovalverde]

This is already being used and was included at db966f2

[gustavovalverde]

This is already being used and was included at db966f2