Enhancement: When no context argument is specified, infer the current working directory as the context to use.

My apologies if this has already been opened; I did a search of "build context," and didn't see any related issues.

Description

This feature makes it so that if the user types docker build, an incantation which does not specify a context for the build, the docker client tool treats the command as if the user had typed docker build ..

Reasoning

This particular enhancement has been something I've meant to suggest and implement for a few years now, but because I'm a terrible person I had procrastinated. Earlier this week I waited ten minutes for a CI/CD pipeline I was working on late at night and thought I'd just finished, only to get the ever-dreaded "docker build" requires exactly 1 argument. and, knowing I had to make a one-character change and put off sleep for another ten minutes, after some very cathartic verbalizations, I decided this was the week I'd do the job.

As far as I've experienced, inferring the current working directory as the context for the command matches how other regularly used cli commands behave, making it the 'unsurprising' behavior. make is the most similar example, I think; while I can specify a different path for make to use when running the command (at least ingnu make), by default it assumes we're talking about the current directory. ls is a more trivial but still notable command; while I can say ls some/other/folder/, if I just say ls, then it assumes I'd like the directory listing for the directory I'm in. Docker's client not doing the same is surprising to my 'muscle memory' when using the cli, which is likely why I frequently make the mistake.

Requiring the user to always specify a build context seems less consistent with both the command line tools I use daily and also the use of docker I see, as opposed to having the user specify a context only in the case they don't mean the current working directory.

Steps to reproduce the issue:

1. Run docker build without a context specified
2. Observe the response "docker build" requires exactly 1 argument., followed by the client exiting
3. Drink.

Describe the results you received:

The docker client crows "docker build" requires exactly 1 argument. smugly at my incompetence, informing me that I'm so simple I failed to type a single character

Describe the results you expected:

The docker client makes the assumption that I meant to use the current directory as my context, with the further assumption that if I had wanted to specify some build context other than the current working directory, I would have done so explicitly.

Additional information you deem important (e.g. issue happens only occasionally):

This change does not impact the behavior of any currently-working workflows. The build context can still be passed in the way it already is, and so anyone explicitly specifying a build context will receive the results they expect.

As I have not used the other features for build contexts personally - e.g., using URLs or stdin - I could absolutely be missing some context* as to why this could actually negatively impact some users' workflows. There are a lot of people using the client, and while everyone I've used as an emotional outlet for this subject has agreed that inferring the cwd makes sense, we're a microscopic subset of the whole population. Because of this, I'm more than open to being shown workflows or places where this is clearly a disadvantageous or outright harmful default, in which case I'll probably set up some bashrc voodoo or the like to include . when I don't remember to include it.

Please let me know if I've missed anything needed for the enhancement issue. Thanks for your time (and docker)!

Marshall

* 👉 👉 haha!

Start at the docker build command's argument handling and run the reproduction command to observe the current validation. Trace how explicit contexts, including URLs or stdin, are handled before deciding how the no-argument case should behave. Done means docker build uses the current working directory while existing explicit-context workflows remain unchanged.