[core,contrib,k8s,otlp] Add Windows 2019 and 2022 container image (amd64 only)

[douglascamata]

This PR adds support for releasing amd64 Windows 2019 and 2022 container images for the distros: core, contrib, otlp and k8s.

As a reminder, windows/amd64 is already a supported platform (tier 2) in the Collector.

Another worthy note: there are no Windows containers image produced by Microsoft on the i386 architecture.

First of all, this was only possible after reading a lot of material about building Windows container images (https://lippertmarkus.com/2021/11/30/win-multiarch-img-lin/, https://tobiasfenster.io/building-docker-images-for-multiple-windows-server-versions-using-self-hosted-github-runners) and seeing some examples of other projects using GoReleaser that also build Windows container images (testcontainers/moby-ryuk#52, for example).

As byproduct of this pull request, I started a discussion in GoReleaser to talk about my wishlist to improve support for building Windows container images with the "Split and Merge" strategy. Some of the small hacks in this PR could be remove in the future as outcome of this conversation. I'll keep collaborating with the folks there to improve the support for this.

Additional changes

• Fix slow cache restore of the setup-go Github Action in Windows: pretty self explanatory. The action was taking over 10 minutes to restore the cache. There are issues and PRs upstream to the action with a fix (see Fix slow cache restore on Windows actions/setup-go#515), but they weren't merged it.
• The GoReleaser release configuration now has replace_existing_artifacts: true. This is required because the split-and-merge build will try to upload some generic artifacts (like source code tarball) more than once. Without this setting on, when it tries to upload an artifact that already exists an error is returned and the build fails.
• The ID of the executable in the MSI installer template replaces dashes with underscore (Id="{{ replace .Binary "-" "_"}}.exe"). This is required because now the MSI installer is built in a Windows node, which enforces that IDs contains only alphanumeric characters, dots, and underscores.

Testing

I produced a test release in my fork using this code: https://github.com/douglascamata/opentelemetry-collector-releases/releases/tag/v0.121.0.

It contains 458 release artifacts. The upstream v0.121.0 contains 452. The new artifacts are the files for the Windows amd64 binary that now is built in the otelcol-k8s distro:

Future work

Support for windows/arm64

In the near feature we can add support for windows/arm64. I didn't add it right now for two main reasons:

• It's not a platform that is currently supported by the OpenTelemetry Collector. In fact, I tried to compile it and it didn't work because some dependencies do not compile on Windows arm64.
• Only Windows Server 2025 has arm64 images. Which means I would need to complicate this a bit more to skip arm64 for Windows 2019 and 2022.

Windows multi-version + multi-arch images

It is possible to build a multi-version image for Windows. This means, for example, a single image manifest tagged as otel/opentelemetry-collector-otlp:{{ .Version }}-windows-amd64 can include images for Windows 2019 and 2022.

This can be further extended by also including in the manifest images for all the architectures supported by each Windows version. We would end up with a manifest tagged like otel/opentelemetry-collector-otlp:{{ .Version }}-windows and potentially including support for Windows 2019, 2022, and 2025 -- including amd64 and arm64 for Windows 2025, if they will be ready then.

I didn't do this right now for two reasons:

• This PR would get bigger and it's already big enough.
• Windows containers are, so far, supported only on amd64 anyway.

This could be done in a follow up PR.

Universal image (the dream)

It is possible to combine Windows multi-version + multi arch image with the Linux images. We would end up with a single manifest tagged as otel/opentelemetry-collector-otlp:{{ .Version }} that would work on all the supported Linux and Windows architectures and versions. 🤯

It's currently impossible to implement this though because of limitations in how GoReleaser handles image manifests. It currently has to load all the images going into a manifest and, as we know, Windows container image cannot be loaded on Linux and vice-versa.

[mowies]

Fixes #339

[mowies]

please add a changelog entry for this

[douglascamata]

Changelog entry added, @mowies. I always leave it for the end and forget it. Sorry. 😅

[douglascamata]

@mowies @pjanotti addressed the review comments and fixes are pushed. Thanks for reviewing. 🙇

[pjanotti]

LGTM

[douglascamata]

Whatever happens, let's only merge this after 0.122.0 is safely released.