Add "Run tools" workflow to prevent tools breakage from version bumps

[jingyuanliang]

go-licenses is already practiced by regular builds, but manifest-tool can't build without directories created, and during regular execution they're created when building binaries, while we're skipping it here.

Let's explicitly run go-licenses to get them created here, and this could also provide a clearer signal on go-licenses itself.

The purpose of this is to prevent https://github.com/thockin/go-build-template/issues/102. The failed check execution is due to https://github.com/thockin/go-build-template/issues/102.

[thockin]

I'm not clear how this aims to fix the manifest-tool being broken?

[jingyuanliang]

I'm not clear how this aims to fix the manifest-tool being broken?

It's not to fix it right now. It's to prevent it being broken (so the previous dependabot bump would fail checks).

As for fix, I'd recommend reverting that dependabot PR, and wait for a new manifest-tool version with the fix. I feel it's not worth for a revert to be a PR. You can just do it yourself, then this PR can validate the fix.

[thockin]

Weirdly:

$ go install github.com/estesp/manifest-tool/v2/cmd/manifest-tool@v2.0.8

$ go install github.com/estesp/manifest-tool/v2/cmd/manifest-tool
../../../go/pkg/mod/github.com/estesp/manifest-tool/v2@v2.0.8/cmd/manifest-tool/main.go:8:2: no required module provides package github.com/docker/docker/cli/config; to add it:
    go get github.com/docker/docker/cli/config

$ grep manifest-tool go.mod 
    github.com/estesp/manifest-tool/v2 v2.0.8

Soit works if I ask for v2.0.8 but not if I don't specify, even though the module uses v2.0.8

[jingyuanliang]

I think I don't have sufficient go knowledge to figure this out without experiments, while I'm currently on my phone.