feat: include PostReady hook, defining proper execution order for container lifecycle hooks

[mdelapenya]

What does this PR do?

This PR internally changes how the container lifecycle hooks are executed. Before these changes:

• default hooks (logging, config modifiers, copy files and wait strategies) were executed first
• user-defined hooks were executed after the default ones.

It could be OK, but it is not allowing users to perform tasks related to the warm-up of a container:

• create a dir so that copied files are able to live in a directory that the underlying Docker image does not have.
• execute code in a startup command, and wait for it as part of the wait strategies

With the changes in this PR, we are updating the execution order to:

1. execute default PRE hooks first
2. execute user-defined PRE hooks second
3. execute user-defined POST hooks first
4. execute default POST hooks second

With this order, we make sure that users can define their stuff at the right place in the container life cycle.

In order to achieve this order, we are combining default and user-defined hooks into one single hook, and that will be the one finally added to the container request. We have added unit tests to verify that the order is honoured.

To enrich the experience, we are defining a new container lifecycle event: Ready, which happens right after the PostStart event. This Ready event defines PostReadies hooks only. This new event will represent the execution of the wait strategies, which is the Testcontainers representation for Readiness.

Finally, given the PR touches the container lifecycles, we are refining the log messages in the default logging hooks, always using ✅ for the default post hooks.

Why is it important?

Define a consistent container life cycl, allowing users to act before the default hooks.

Related issues

• Closes [Enhancement]: Properly define the execution order for container lifecycle hooks #1919

[netlify]

✅ Deploy Preview for testcontainers-go ready!

Name	Link
🔨 Latest commit	8dd85e8
🔍 Latest deploy log	https://app.netlify.com/sites/testcontainers-go/deploys/65cd5c8cce78cc000876d938
😎 Deploy Preview	https://deploy-preview-1922--testcontainers-go.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[pablochacin]

execute default PRE hooks first
execute user-defined PRE hooks second
execute user-defined POST hooks first
execute default POST hooks second
With this order, we make sure that users can define their stuff at the right place in the container life cycle.

I think this still doesn't make clear how this hook execution order related to the container's readiness. I just found it by looking at the code and realizing the waitfor is executed as a post-start hook. This wasn't obvious to me. I suggest we make this more explicit in some way.

[mdelapenya]

I suggest we make this more explicit in some way.

You mean in the docs and in this PR description? PTAL at https://deploy-preview-1922--testcontainers-go.netlify.app/features/creating_container/#lifecycle-hooks, the Info section

[mdelapenya]

I think this still doesn't make clear how this hook execution order related to the container's readiness.

In that sense I believe we need to always run the default wait strategies before the user-defined post-start hooks. Otherwise we can see a module trying to run commands even before the readyness (defined by the wait strategies) is not complete.

I'm tempted to always prepend the wait strategies to the post-start hooks. Wdyt? @kiview we have already discussed about this today

[pablochacin]

In that sense I believe we need to always run the default wait strategies before the user-defined post-start hooks. Otherwise we can see a module trying to run commands even before the readyness (defined by the wait strategies) is not complete.

This is how this works now and precisely the problem I mentioned in the slack.

The changes introduced in this PR change that and allow running a post-strart hook before the wait condition, and then use a wait condition that verifies the effects of such hook.

maybe I'm missing something here, but what you propose seems to take us back to the current behavior

[pablochacin]

I suggest we make this more explicit in some way.

You mean in the docs and in this PR description? PTAL at https://deploy-preview-1922--testcontainers-go.netlify.app/features/creating_container/#lifecycle-hooks, the Info section

Documentation. In the proposed changes you mention this in a info note regarding the default hooks, but I think the definition of Post-start hook should be more specific, because "started" and "ready" (post wait condition meets) are in my opinion two different things and make create confusion.

[mdelapenya]

@pablochacin I've updated the PR and description to reflect the new Ready lifecycle event, with its own Pre/Post hooks. PTAL 🙏

[pablochacin]

LGTM.