a normal sourced status output would be like:

Name                   Command                    State         Ports
-------------------------------------------------------------------------------
srcd-x_bblfsh-web_1    /bin/bblfsh-web -addr ...  Up            9999->8080/tcp
srcd-x_bblfsh_1        /tini -- bblfshd           Up            9432->9432/tcp
srcd-x_ghsync_1        /bin/sh -c sleep 10s  ...  Exit 0
srcd-x_gitbase_1       ./init.sh                  Up            3306->3306/tcp
srcd-x_gitcollector_1  /bin/dumb-init -- /bi ...  Exit 0
srcd-x_metadatadb_1    docker-entrypoint.sh  ...  Up            5433->5432/tcp
srcd-x_postgres_1      docker-entrypoint.sh  ...  Up            5432->5432/tcp
srcd-x_redis_1         docker-entrypoint.sh  ...  Up            6379->6379/tcp
srcd-x_sourced-ui_1    /entrypoint.sh             Up (healthy)  8088->8088/tcp

If any component (not being ghsync nor gitcollector) appears as Exit, it will be a reason to fail fast.
But what about if a component takes too much time as Restarting (what could mean the component is in a restart boot loop)? Or what about if when checking the status of the components, it is detected an Exit 1 in one component? Should it fail fast? or should it wait till docker tries to restart the component?
Should we implement a grace period, and fail not fast, but when the grace period ends?

I'm not sure if there is a clean way to proceed in the examples above.
I'd vote to just show the sourced status till the UI is available, and let the user decide how to proceed in any of the situations proposed above.

Fail fast during sourced initialization if a component breaks #147

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions