AWS MicroVM build fails because pinned gh-2.96.0-1 RPM is unavailable

[gregario]

QM CLI 0.1.4's AWS MicroVM build currently pins the GitHub CLI RPM to gh-2.96.0-1 in templates/aws/microvm-agent/Dockerfile.

That RPM is no longer available from https://cli.github.com/packages/rpm/gh-cli.repo, so the image build fails at:

dnf install -y gh-2.96.0-1

with:

error: No package matches 'gh-2.96.0-1'

On AWS Lambda MicroVM image builds this is surfaced only as The container image build failed., with no useful build logs.

I reproduced the failure locally using the exact public.ecr.aws/lambda/microvms:al2023-minimal base image. gh-2.97.0-1 is available for the same ARM64 image and a full local build succeeds after changing only that pin.

Could QM update the pinned RPM (or otherwise make this dependency version reproducible and maintainable)?

[time-attack]

The reported pin is gone. Main installs gh-2.97.0-1 in cli/templates/aws/microvm-agent/Dockerfile (via #163). Please close this issue. The longer-term “don’t pin a rotting RPM” discussion can stay on #123.

[edbror]

Recurrence on CLI 0.1.5: the bumped pin has now rotated out as well.

cli/templates/aws/microvm-agent/Dockerfile currently installs gh-2.97.0-1 (the bump from #163). That RPM is no longer served by https://cli.github.com/packages/rpm/gh-cli.repo, so a fresh qm infra build-image fails exactly as originally reported:

error: No package matches 'gh-2.97.0-1'

As before, AWS surfaces this only as The container image build failed. with no CloudWatch log streams created at all, so it is undiagnosable from the AWS side. I reproduced it locally against the pinned base image (public.ecr.aws/lambda/microvms:al2023-minimal, arm64) to get the real error.

The repo currently carries exactly one version:

$ dnf repoquery gh
gh-2.98.0-1.aarch64
gh-2.98.0-1.armv6hl
gh-2.98.0-1.i386
gh-2.98.0-1.x86_64

That is the crux: cli.github.com's RPM repo retains only the newest build, so any pinned version becomes invalid on the next gh release. This is now the second occurrence (2.96.0 → 2.97.0 → 2.98.0), which suggests bumping the pin resets the clock rather than fixing the failure — the next release breaks it again.

This seems like direct evidence for the approach proposed in #123 (immutable versioned release artifacts with per-arch SHA-256), which would also match how awscli and litestream are already installed a few lines below in the same Dockerfile.

Local workaround, for anyone else hitting a stalled deploy: drop the version qualifier (dnf install -y gh), matching every other dnf package in that file. A full local build then succeeds.