ci: Setup otel tracing for windows integration tests

[akerouanton]

Related to:

• Add otel tracing #45652

- What I did

• Set up Jaeger before running integration tests on Windows builds
• Download traces and put them in build artifacts

Note that for both Linux and Windows builds, the trace file can't be fully imported in Jaeger due to its size. In addition, big trace files also tend to create many many DOM nodes, leading to unresponsive browser tab. One have to tweak the CI config on a given PR to limit how much integration tests are run to get a usable trace file.

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

[crazy-max]

Could be moved to https://github.com/moby/moby/blob/master/.github/actions/setup-tracing/action.yml

Using bash shell with a cond if [ "${{ runner.os }}" = "Windows" ].

You should still be able to run jaeger-all-in-one.exe

[akerouanton]

Oh that's good to know. Unfortunately GH was unhappy with this file and I'm not sure it will work better if I move this step into the setup-tracing action. See this run: https://github.com/moby/moby/actions/runs/6545687164/job/17775109401#step:3:1. Any ideas?

[crazy-max]

Unfortunately GH was unhappy with this file and I'm not sure it will work better if I move this step into the setup-tracing action. See this run: https://github.com/moby/moby/actions/runs/6545687164/job/17775109401#step:3:1. Any ideas?

Hum maybe the name should be unique? Can you try with name: 'Setup Tracing Windows'

[crazy-max]

Hum still this issue:

Error: Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under 'D:\a\moby\moby\.github\actions\setup-tracing'. Did you forget to run actions/checkout before running your local action?

I wonder if this is because we change the working dir in

moby/.github/workflows/.windows.yml

Lines 40 to 42 in 70589b8

	defaults:
	run:
	working-directory: ${{ env.GOPATH }}/src/github.com/docker/docker

[crazy-max]

related to my previous comment, can you try:

Suggested change

	uses: ./.github/actions/setup-tracing
	uses: ./.github/actions/setup-tracing
	working-directory: ${{ github.workspace }}

Or maybe absolute:

Suggested change

	uses: ./.github/actions/setup-tracing
	uses: ${{ github.workspace }}/.github/actions/setup-tracing

[akerouanton]

I tried both suggestions but that doesn't work; see here and here.

I'll try with the absolute path hardcoded to see what happens.

[thaJeztah]

Some questions;

It looks like we're using a custom action for Linux; is that something that's possible for Windows as well?

If that's indeed for the same; I see the action uses a different version of Jaeger (1.46 versus 1.50.0)

moby/.github/actions/setup-tracing/action.yml

Lines 9 to 11 in 7cabe08

	docker run -d --net=host --name jaeger -e COLLECTOR_OTLP_ENABLED=true jaegertracing/all-in-one:1.46
	docker0_ip="$(ip -f inet addr show docker0 | grep -Po 'inet \K[\d.]+')"
	echo "OTEL_EXPORTER_OTLP_ENDPOINT=http://${docker0_ip}:4318" >> "${GITHUB_ENV}"

It would be good to user the same version, even if it's not "super" important, so that it's less likely for those versions to be missed if we update. I guess ideally both would be set up using the same action (or something in the same file / dir), but if that's not possible, we should consider adding a comment (when updating thise one, don't forget the other one), or maybe a parameter / env-var for the version.

[akerouanton]

It looks like we're using a custom action for Linux; is that something that's possible for Windows as well?

That's what we try to do initially with @crazy-max. We tried both to add a Windows-specific run step to the existing action, and to create a dedicated action. In both cases, this didn't work (see this failure: https://github.com/moby/moby/actions/runs/6545687164/job/17775109401#step:3:1), but we're unable to find the root cause. Hence, we decided to inline the run step in .windows.yml (as it's the only place where this needs to be set up for Windows).

It would be good to user the same version, even if it's not "super" important, so that it's less likely for those versions to be missed if we update. I guess ideally both would be set up using the same action (or something in the same file / dir), but if that's not possible, we should consider adding a comment (when updating thise one, don't forget the other one), or maybe a parameter / env-var for the version.

I'm not a big fan of the env-var as it'd have to be defined either at the repo level (so it'd require admin rights to update it), or in workflows files (so we're back to the duplication problem it tries to avoid). Instead I added a comment in both .windows.yml and the Linux action file as you suggested.

[thaJeztah]

but we're unable to find the root cause. Hence, we decided to inline the run step in .windows.yml (as it's the only place where this needs to be set up for Windows).

Hm.. right. Yeah, not ideal, but I guess "it is what it is". Perhaps we can try again in future

I'm not a big fan of the env-var as it'd have to be defined either at the repo level (so it'd require admin rights to update it)

Yeah, I was considering that we could have an easy-to-grep JAEGER_VERSION (e.g.), and if it would be possible to have that in a central place at the start of the workflow, but haven't looked closely.

A comment is fine for now.

[thaJeztah]

LGTM