-
Notifications
You must be signed in to change notification settings - Fork 154
feat: added CommandStrategy with SuccessfulCommand enum #782
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 5 commits
edf5f14
7d449aa
7475502
86fa407
8a34464
cee5d7e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,110 @@ | ||
use std::time::Duration; | ||
|
||
use crate::{ | ||
core::{client::Client, error::WaitContainerError, wait::WaitStrategy, ExecCommand}, | ||
ContainerAsync, Image, | ||
}; | ||
|
||
#[derive(Debug, Clone)] | ||
pub struct CommandStrategy { | ||
expected_code: i64, | ||
poll_interval: Duration, | ||
command: ExecCommand, | ||
fail_fast: bool, | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems unchanged - we still have The idea was to change how it's organized and implemented There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Apologies for this overlook -- updated! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @DDtKey Is there anything else you'd like fixed on this PR? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @DDtKey Wanting to follow up here, is there anything else you'd like to see addressed on this PR that I may have missed? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hi @sutt0n, sorry for the delay I'll take a fresh look soon and drop a message if I have any more questions. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @DDtKey no worries and sounds great! let me know if there are more changes required, please and ty. |
||
|
||
impl CommandStrategy { | ||
/// Create a new `CommandStrategy` with default settings. | ||
pub fn new() -> Self { | ||
Self { | ||
command: ExecCommand::default(), | ||
expected_code: 0, | ||
poll_interval: Duration::from_millis(100), | ||
fail_fast: false, | ||
} | ||
} | ||
|
||
/// Creates a new `CommandStrategy` with default settings and a preset command to execute. | ||
pub fn command(command: ExecCommand) -> Self { | ||
CommandStrategy::default().with_exec_command(command) | ||
} | ||
|
||
/// Set the fail fast flag for the strategy, meaning that if the command's first run does not | ||
/// have the expected exit code, the strategy will exit with failure. If the flag is not set, | ||
/// the strategy will continue to poll the container until the expected exit code is reached. | ||
pub fn with_fail_fast(mut self, fail_fast: bool) -> Self { | ||
self.fail_fast = fail_fast; | ||
self | ||
} | ||
|
||
/// Set the command for executing the command on the container. | ||
pub fn with_exec_command(mut self, command: ExecCommand) -> Self { | ||
self.command = command; | ||
self | ||
} | ||
|
||
/// Set the poll interval for checking the container's status. | ||
pub fn with_poll_interval(mut self, poll_interval: Duration) -> Self { | ||
self.poll_interval = poll_interval; | ||
self | ||
} | ||
} | ||
|
||
impl WaitStrategy for CommandStrategy { | ||
async fn wait_until_ready<I: Image>( | ||
self, | ||
client: &Client, | ||
container: &ContainerAsync<I>, | ||
) -> crate::core::error::Result<()> { | ||
loop { | ||
let container_state = client | ||
.inspect(container.id()) | ||
.await? | ||
.state | ||
.ok_or(WaitContainerError::StateUnavailable)?; | ||
|
||
let is_running = container_state.running.unwrap_or_default(); | ||
|
||
if is_running { | ||
let exec_result = client | ||
.exec(container.id(), self.command.clone().cmd) | ||
.await?; | ||
|
||
let inspect_result = client.inspect_exec(&exec_result.id).await?; | ||
let mut running = inspect_result.running.unwrap_or(false); | ||
|
||
loop { | ||
if !running { | ||
break; | ||
} | ||
|
||
let inspect_result = client.inspect_exec(&exec_result.id).await?; | ||
let exit_code = inspect_result.exit_code; | ||
running = inspect_result.running.unwrap_or(false); | ||
|
||
if self.fail_fast && exit_code != Some(self.expected_code) { | ||
return Err(WaitContainerError::UnexpectedExitCode { | ||
expected: self.expected_code, | ||
actual: exit_code, | ||
} | ||
.into()); | ||
} | ||
|
||
if exit_code == Some(self.expected_code) { | ||
return Ok(()); | ||
} | ||
|
||
tokio::time::sleep(self.poll_interval).await; | ||
} | ||
|
||
continue; | ||
} | ||
} | ||
} | ||
} | ||
|
||
impl Default for CommandStrategy { | ||
fn default() -> Self { | ||
Self::new() | ||
} | ||
} |
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't this be achieved with
exec_after_start
withExitCode
wait condition (it waits for exit)? Additionally, this way allows to rely on a container's stateOr we could consider extending existing wait conditions if it's not enough
But generally speaking, at first glance it looks like duplicate functionality
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that you mention it and after a second glance, it feels like duplicate functionality. This was probably an oversight on my end by lack of context.
I can test what you've provided and report back findings - that may aid in either resolving or progressing a solution for this issue.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After investigating, the difference here is that this adds a "command strategy" similar to "shell strategy" (with an emphasis on
SuccessfulCommand
) here:https://node.testcontainers.org/features/wait-strategies/#shell-command
To be more orthogonal / consistent with the Node test container, what do you think about this just being
ShellStrategy
instead? It has the same functionality, if I'm not mistaken:https://github.com/testcontainers/testcontainers-node/blob/main/packages/testcontainers/src/wait-strategies/shell-wait-strategy.ts#L6
Whereas
WaitFor
is similar to: https://github.com/testcontainers/testcontainers-node/blob/b92f6695de10863c6ea90d169f999b79406d162e/packages/testcontainers/src/wait-strategies/wait.ts#L40Thoughts?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have to be fully consistent with other languages. You can find a lot of differences between Go, Java and Node, for example (but we try to be aligned when possible)
Also, we should compare
exec_after_start
with strategies here, not theWaitFor
itself.However we can consider such strategy for sure, more like "alias" or "short/easier way".
But we need to avoid maintaining of duplicative logic/code. Let me explain:
What are we introducing here that is missing in
exec_after_start
?If it's about "easier way" - we need to find a way to compose it more correctly
But if there is a difference in functionality - then it should be very clear to users why to use one over the other
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's consider the current implementation to understand if it's clear enough
What confuses me a little bit here:
with_cmd_ready_condition(CmdWaitFor::exit_code(0)
- expects exit-code = 0SuccessfulCommand
- also expects exit-code = 0 (implicitly)with_cmd_ready_condition
to expect non-zero code or something else?Perhaps, instead I'd suggest to support something like
fail_fast
/retry
forExecCommand
And add very simple strategy, like
Command(ExecCommand)
So it will look like:
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies for the delay, been a busy week here with the weather we've been getting in Arkansas. 😅
I've pushed an update that I believe is something that aligns... I was hesitant on theCmdWaitFor::exit_code(0)
inWaitFor::command()
, but added it anyway....however, now that I think about it, we may want to not force that specific exit code, but allow users to specify one on their own. Thoughts?Nevermind. I've allowed this to be more general than specific.