Skip to content
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

chore: remove unneccessary WithFailFast option #4484

Merged
merged 1 commit into from
Dec 14, 2023

Conversation

jedevc
Copy link
Member

@jedevc jedevc commented Dec 13, 2023

WithFailFast was not actually causing any change in behavior, so we can remove the option completely.

The option set FailOnNonTempDialError(true) on the gRPC connection. However, the help text for this method option declares that it "does not do anything useful unless you are also using WithBlock()" - which we do not do. I've verified that the only client-side code path that actually handles this option is under a check for if WithBlock() was also used.

We can remove this option instead of fixing it, since the need for this functionality has been replaced by the more buildkit-native client.Wait function - this function also correctly waits for the buildkit server to begin running, and to start serving requests (which is generally the desired behaviour).

If users actually desire this option (which was not fully working previously), they can use the WithGRPCDialOption, and pass FailOnNonTempDialError(true) directly, alongside WithBlock.

WithFailFast was not actually causing any change in behavior, so we can
remove the option completely.

The option set FailOnNonTempDialError(true) on the gRPC connection.
However, the help text for this method option declares that it "does not
do anything useful unless you are also using WithBlock()" - which we do
not do. I've verified that the only client-side code path that actually
handles this option is under a check for if WithBlock() was also used.

We can remove this option instead of fixing it, since the need for this
functionality has been replaced by the more buildkit-native client.Wait
function - this function also correctly waits for the buildkit server to
begin running, and to start serving requests (which is generally the
desired behaviour).

If users actually desire this option (which was not fully working
previously), they can use the WithGRPCDialOption, and pass
FailOnNonTempDialError(true) directly, alongside WithBlock.

Signed-off-by: Justin Chadwell <me@jedevc.com>
@jedevc
Copy link
Member Author

jedevc commented Dec 13, 2023

Note: this will cause a little bit of breakage for anyone who was a custom buildkit client, but given that this option doesn't seem to have done anything for a while, I'm happy with the idea of removing it.

@AkihiroSuda AkihiroSuda merged commit a960fe5 into moby:master Dec 14, 2023
60 checks passed
kzys added a commit to superfly/flyctl that referenced this pull request Mar 29, 2024
It is no-op and has been removed from Buildkit.

moby/buildkit#4484
kzys added a commit to superfly/flyctl that referenced this pull request Mar 29, 2024
It is no-op and has been removed from Buildkit.

moby/buildkit#4484
@alexellis
Copy link

Hey @jedevc - @AkihiroSuda sent me here.

Note: this will cause a little bit of breakage for anyone..

Just using a normal BuildKit client, not a custom one as far as I'm aware.

A deprecation would have been much appreciated here. I did a code search but didn't find this PR until I had to ask a maintainer or otherwise bother you guys with an issue asking about it 🙏

Thanks for all your work on BuildKit

Alex

@jedevc jedevc deleted the remove-with-fail-fast branch April 2, 2024 11:07
kzys added a commit to superfly/flyctl that referenced this pull request Apr 5, 2024
* refactor: don't use WithFailFast

It is no-op and has been removed from Buildkit.

moby/buildkit#4484

* chore: upgrade moby/buildkit

DisplaySolveStatus has been removed by
moby/buildkit#4113.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants