Add test case to document env header contains whitespace error as expected behavior.

[MicahKimel]

- What I did

• Test case to show this is expected behavior for the cli
• Documenting using a bad header in .env such as [config 1] will throw an error is expected behavior.
• closes docker run throws error if an env var contains whitespace #5057

- How to verify it

• Running test cases docker buildx bake test looked good to me

- Description for the changelog

Test case documenting using a bad header in .env will throw a error is expected behavior.

- A picture of a cute animal (not mandatory but encouraged)

[Benehiko]

Thank you for the PR :)
This already looks quite good. Just a few comments from my side.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 61.33%. Comparing base (28c5652) to head (5fab514).
Report is 120 commits behind head on master.

❗ Current head 5fab514 differs from pull request most recent head e5cbcd9

Please upload reports for the commit e5cbcd9 to get more accurate results.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #5081   +/-   ##
=======================================
  Coverage   61.33%   61.33%           
=======================================
  Files         298      298           
  Lines       20692    20691    -1     
=======================================
  Hits        12691    12691           
+ Misses       7100     7099    -1     
  Partials      901      901           

[MicahKimel]

Thanks @Benehiko, I merged back up with master, it seems my editor was trying to change formatting on container_run.md, but I think I got it fixed. Let me know any feedback! Thank you!

[MicahKimel]

My bad, when I followed the DCO after the merge by running git rebase HEAD~13 --signoff and git push --force-with-lease origin master, it didn't quite do exactly what I thought it would, since the files changes jumped from 2 to 405, it is clearly wrong. Clear to say I don't know what I'm doing rebasing signoffs, I'll try to read up on it and get it fixed tomorrow.

[Benehiko]

My bad, when I followed the DCO after the merge by running git rebase HEAD~13 --signoff and git push --force-with-lease origin master, it didn't quite do exactly what I thought it would, since the files changes jumped from 2 to 405, it is clearly wrong. Clear to say I don't know what I'm doing rebasing signoffs, I'll try to read up on it and get it fixed tomorrow.

Woops, don't stress! Everyone has had something like this happen to them :)

I think it might be best to reset your master branch on your fork with the upstream (docker/cli) and then cherry pick a283791 and 6b9a70b and push the cherry pick. You should be able to do this by adding the docker/cli repo as an upstream remote repository then fetch all commits from the upstream. Reset your fork's master to the upstream master and force push. Then cherry pick your original commit a283791 and 6b9a70b on your fork's master and push.

https://stackoverflow.com/questions/9646167/clean-up-a-fork-and-restart-it-from-the-upstream

As the SO post mentions, you should also probably backup your work on a separate branch before doing the reset. create a new branch that's clean and cherry pick your work a283791 and 6b9a70b. Commit that to this branch - then once you have it you can do the reset.