ci: github actions test workflow

[crazy-max]

Follow-up #3320

Switch To GitHub Actions for tests:

• add test stage and update bake definition
• create test workflow
  • run tests with bake
  • run tests on macos and windows host runners
• appveyor and make.ps1 not needed anymore (cc @StefanScherer)

Signed-off-by: CrazyMax crazy-max@users.noreply.github.com

[codecov-commenter]

Codecov Report

Merging #3365 (4d93717) into master (ba0ace0) will decrease coverage by 1.66%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3365      +/-   ##
==========================================
- Coverage   58.02%   56.35%   -1.67%     
==========================================
  Files         302      304       +2     
  Lines       21761    26833    +5072     
==========================================
+ Hits        12626    15121    +2495     
- Misses       8214    10792    +2578     
+ Partials      921      920       -1     

[thaJeztah]

I'm a bit confused though; why do they differ?

context_test.go:84: assertion failed:
/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/builder-context-test348532470 (contextDir string) !=
/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/builder-context-test348532470 (absContextDir string)

Is it because we create it as /var/folders, but /var is a symlink, so when reading it back, it returns the actual path?

$ ls -la /var
lrwxr-xr-x@ 1 root  wheel  11 Jul  1  2019 /var -> private/var

[thaJeztah]

So, I guess os.TempDir() returns /tmp, but that's a symlink;

bash-5.0$ ls -la /tmp
lrwxr-xr-x@ 1 root  wheel  11 Jul  1  2019 /tmp -> private/tmp

(also wondering if os.MkdirTemp() returns the wrong path, I'm wondering if that should be considered a bug in Golang, but not sure what would be the least surprising behavior 🤔)

I guess as part of the test, we'd have to resolve the path to the actual location, but it's still odd that one part gives the path of the symbolic linked location, and the other the actual location.

[crazy-max]

Thanks for your review @thaJeztah, I fixed this issue by evaluating symlinks and now tests are ok on MacOS runners.

[crazy-max]

To fix the EOL issues on Windows runners, we need to disable autocrlf. See actions/checkout#135 for more info.

[crazy-max]

There are still tests failing on the Windows runner and from what I see, it was already failing before this PR, so I guess we should fix that in a follow-up and mark the Windows GHA job as "allow-failure" or disable it in the meantime. WDYT @thaJeztah?

[crazy-max]

I have disabled tests on Windows runner in the meantime. FWIW the last time the tests were ok on AppVeyor was June 24, 2018.

[thaJeztah]

I see this was changed, but looks like the options are left the same; do we actually use the ./coverage directory now when using this target? Or only if we use the buildx bake approach?

[crazy-max]

As discussed moved coverage output to ./build folder.

[thaJeztah]

LGTM

@tonistiigi @silvin-lubecki PTAL

[silvin-lubecki]

LGTM 🚀

[thaJeztah]

rebase was just s/1.16.10/1.16.11/ I'll merge this once CI completes (thanks!)