Include section to show expectations of a successful build of the project via docker

[lyqht]

Explain the changes

Before the forem_rails container finishes its job, I keep seeing the following console logs

forem_sidekiq | 2021/10/04 11:45:43 Problem with dial: dial tcp 172.20.0.6:3000: connect: connection refused. Sleeping 20s
forem_seed | 2021/10/04 11:45:43 Problem with dial: dial tcp 172.20.0.6:3000: connect: connection refused. Sleeping 20s

These logs confused me a lot and made me think that I did something wrong. I saw this happening for a whole 15mins while the other containers such as forem_rails and forem_webpack are doing their job. These logs only stopped after forem_rails was done.

Later on, I also keep seeing repetitive logs of

forem_sidekiq | 2021-10-04T11:58:53.179Z pid=17 tid=5sbd class=PodcastEpisodes::CreateWorker jid=a62b46c37f05a191b0378648 INFO: start
forem_sidekiq | 2021-10-04T11:58:53.989Z pid=17 tid=1qq9 class=PodcastEpisodes::CreateWorker jid=83c1b062229b7a3c8e3beb95 elapsed=2.291 INFO: done

which had no indications of when or where the process will end. (Up till here, it already took 30-40mins)

Suggested changes

1. Include some successful console logs for different containers will help demystify the build process through Docker.
2. A notice to tell them there will be certain logs that would be repetitive and not a cause of concern, to help ease minds that are waiting

Additional context

I'm not familiar to Docker, but perhaps a better way to resolve this problem is to set the logs on the 2 docker containers forem_sidekiq & forem_seed to be quiet until the other containers are done with their scripts.

[djuber]

I can completely relate - the process here is a little unclear and exposes a lot of internals. This should be better documented. I think the documentation used to include a vague "may take a long time to complete" or similar language, I see now we only have "run container setup, you're done, view site", which is unhelpful to explain what you're being shown in the console.

In the second example (the long stream of podcast episode creation jobs processing), this is caused by the database seed script (which creates articles, users, posts, and podcasts) having enqueued to sidekiq (the background job processing service) a large number of post-creation jobs (from an after_save callback I think). This part happens in any context (local, docker, etc) after seeding the db, which includes the initial setup of the app.

For the first case, there are a few setup steps (installing js libraries with yarn, and ruby libraries with bundle) that run before the webserver container "rails" can be started, and several jobs (sidekiq, db seed) that wait for rails (port 3000) to be ready.

All of this is understandable with enough background information, but I agree this information belongs in the containers setup instructions since it's unclear what's happening, how long it might take to finish, and whether it's going to be successful when it finishes.