docker/install: Support `version: master`

[vvoland]

• related to: https://github.com/crazy-max/ghaction-setup-docker/issues/81

Add support for installing Docker master packages from moby/moby-bin and dockereng/cli-bin images.

This could also allow to install arbitrary version from these images but for now it's only used for master.

Test run: https://github.com/docker/moby-private/actions/runs/10773693004/job/29874033854?pr=9#step:2:336

[vvoland]

Also opened a PR on the ghaction to make use of the new options: https://github.com/crazy-max/ghaction-setup-docker/pull/106

[crazy-max]

https://github.com/docker/actions-toolkit/actions/runs/11353388604/job/31578295350?pr=438#step:11:583

Downloading from moby/moby-bin and dockereng/cli-bin tag: 27.3.1
FAIL __tests__/docker/install.test.itg.ts (355.416 s)
  ● install › install docker { type: 'image', tag: '27.3.1' }

    expect(received).resolves.not.toThrow()

    Received promise rejected instead of resolved
    Rejected to value: [Error: Cannot find manifest for darwin/amd64/]

Hum right, on macos runners it will use darwin looking at https://github.com/docker/actions-toolkit/pull/438/files#diff-0f2ffb1716f62956ee604fae748f3369d867fa5c39a60388479728f013479b46R120. Might need to enforce linux in this case but not for cli.

[vvoland]

Or just skip the daemon on darwin and only download the CLI?

OTOH, this could be confusing behavior as it will not error out and won't be able to connect to the daemon..

[crazy-max]

Or just skip the daemon on darwin and only download the CLI?

OTOH, this could be confusing behavior as it will not error out and won't be able to connect to the daemon..

Yeah provisioning for macos is a bit different. It downloads static bins from download.docker.com: https://github.com/docker/actions-toolkit/actions/runs/11289888751/job/31400662984#step:11:17 which only contains cli as expected.

But then during lima provisioning it installs the engine using get.docker.com script: https://github.com/docker/actions-toolkit/blob/a59a5f8e3f66b622b14bd8393b05de8cb00f68d9/src/docker/assets.ts#L224 so platform normalization would match the VM.

[vvoland]

Right, so we'd need to also handle the image download inside the lima provisioning script. I think it's easiest to just use undock there? The lima provisioning is already doing a lot of stuff, so the extra binary won't hurt there 😅

EDIT: Actually it might be easier to just mount the binaries to lima vm, let me try that.

[crazy-max]

Can you rebase to fix the QEMU issue related to https://github.com/docker/actions-toolkit/pull/459

[crazy-max]

Ah that's not the issue looking at https://github.com/docker/actions-toolkit/actions/runs/11363873402/job/31608766636?pr=438

I think we need to teardown after each test similar to https://github.com/crazy-max/ghaction-setup-docker/blob/e98084b722ce510905e904b5df3cc901ff654400/src/main.ts#L64

Edit: hum that's the case https://github.com/docker/actions-toolkit/blob/a59a5f8e3f66b622b14bd8393b05de8cb00f68d9/tests/docker/install.test.itg.ts#L67

[vvoland]

The PR is already rebased on the latest main. The docker service fails to start, so probably I borked something in the provision script. Looking into it.

[vvoland]

Weird qemu failure:

[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
[    0.000000] APIC: Switch to symmetric I/O mode setup
[    0.000000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.000000] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[    0.000000] ...trying to set up timer (IRQ0) through the 8259A ...
[    0.000000] ..... (found apic 0 pin 2) ...
[    0.016000] ....... failed.
[    0.016000] ...trying to set up timer as Virtual Wire IRQ...
[    0.032000] ..... failed.
[    0.032000] ...trying to set up timer as ExtINT IRQ...
[    0.044000] ..... failed :(.
[    0.044000] Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with apic=debug and send a report.  Then try booting with the 'noapic' option.

Is this known to happen sometimes? 🤔

[vvoland]

The previous failure on macos-12 was related to the long /var/tmp path - it didn't mount correctly into lima vm. Fixed by copying to a shorter path in .lima directory.

EDIT: Looks like it's still the case 🫠

[vvoland]

Ok, looks like lima mounts are not always mounted before the provisioning script is run. I changed the darwin lima install to pull the binaries with undock instead. Should be good to go!